|
|
|
# Partial Type Signatures/Annotations?
|
|
|
|
|
|
|
|
<table><tr><th>[\#86](https://gitlab.haskell.org//haskell/prime/issues/86)</th>
|
|
|
|
<td>add PartialTypeAnnotations?</td></tr></table>
|
|
|
|
|
|
|
|
|
|
|
|
Short idea: _ in place of a type is "match anything" (by analogy to the wildcard pattern). This is /not/ the type (exists a.a), contrary to suggestions on the mailing list, as a) we wish to end up with a more specific type via inference and b) the existential type would have issues in a predicative type system (which includes the current rank-n implementations). Essentially, in checking the annotation we infer as normal for the _ and accept whatever is inferred.
|
|
|
|
|
|
|
|
|
|
|
|
Note that _ \*is not a type\*. It's part of the type annotation, but should never be propagated "upwards" by the typechecker - only the type inferred for its position.
|
|
|
|
|
|
|
|
|
|
|
|
There are some further possible extensions to this idea:
|
|
|
|
|
|
|
|
- Allow _ in class contexts to mean one or both of "and additional constraints" or "some type variable that will be inferred". Currently this isn't a well-developed idea, I haven't thought much about it - I like the idea of having a way to say "please don't fall over if I missed out a constraint" though.
|
|
|
|
- Allow "metavariables" (no longer actually meta due to being in the type system, of course) which might be written _a and appear multiple times in the same annotation always meaning the same type.
|
|
|
|
- Add some kind of binder for metavariables and give them lexical scope much as can be done with ordinary type variables. If we do this, top-level bindings would also make sense and allow us to name types we'd like inferred for us before using them as part of type declarations
|
|
|
|
- Allow some kind of constraints between metavariables (Frank Atanassow mentioned this to me on \#haskell-blah)
|
|
|
|
|
|
|
|
## Pros
|
|
|
|
|
|
|
|
- Allows type annotations to convey information they need to without forcing the programmer to infer things the compiler should for them
|
|
|
|
- Can be used to get a complete type before filling in a permanent annotation
|
|
|
|
- Helps scale type annotations to cope with increasingly large types
|
|
|
|
- Metavariables provide similar readability benefits to type annotations while being more change-resistant due to inference
|
|
|
|
|
|
|
|
## Cons
|
|
|
|
|
|
|
|
- It's a new and untested feature
|
|
|
|
- It could encourage sloppy programming style
|
|
|
|
- Readability benefits are also untested |
