I would like to suggest adding Type Holes to Elm. They are easy to implement, feel Elm-y and are wonderful for type-driven development.
What are Type Holes?
Type Hole are a feature in the compiler to let the error messages guide you.
test : List _ test = 
_ is a type hole. The compiler will now try to fill the hole and return an error message like:
test : List _ ^ Your type hole is of type `number`.
Existing workarounds and alternatives
For simple programs we can use
() instead, resulting in something like
The body is a list of type: List number But the type annotation on `test` says it should be: List () Hint: Only Int and Float values work as numbers.
Sadly this will not work for more complicated examples:
view : () view model = div  [ button [ onClick Increment ] [ text "+1" ] , div  [ text <| String.fromInt model.count ] , button [ onClick Decrement ] [ text "-1" ] ]
The type annotation for `view` says it can accept 0 arguments, but the definition says it has 1 argument: 33| view model = ^^^^^ Is the type annotation missing something? Should some argument be deleted? Maybe some parentheses are missing?
(thank to @andys8, for pointing this out)
Missing function declarations
A better way is to not write the function declaration and then let elm-analyse tell you what is missing.
This stops working if you are only interested in a small portion of the declaration.
Personally I had problems with this method while using my own package Orasund/cell-automata. Here I have a lot of nested types. For example
automata : Symmetry state -> Order state -> List (Rule state) -> Automata state
Automata state is a very complicated record that is not in the offical documentation because it would frighten people. (you can check out the definition there.)
Automata a is wrong, it will print the entire definition. Twice! Finding out why
a is wrong is an absolute nightmare. Instead I would have LOVED to just be able to change it to
automata : Symmetry state -> Order state -> List (Rule state) -> Automata _
Now the compiler would only print the important pieces.
The Discussion started over at Slack.
A PR from 2016 was also found in elm/compiler with a statement from Evan:
This is a feature I consider from time to time. Not sure if or when it’d be added though.
Issues here are more about tracking bugs in the language as is, so discussions like this should happen in the places listed here http://elm-lang.org/community
If you have a real-world usage scenario, it’d be great to get it documented and shared with the community so folks can think about this potential workflow.
I would argue that
1.) 2016 has long past, it’s time to look at it again
2.) Type-Driven Development[Video][Article] is based around Type Holes.
3.) Even Evan himself said in a Talk[Video:Life of a File] that we should write files around a type. Thats Type-Driven Devoplement!
4.) Haskell/Agda/Idris does it too!
5.) I would make me happy.
What are your thoughts on this topic?