The nice thing about elm type annotations is that they aren’t embedded within the definition. Eg:
myfunction : Int -> Int myfunction n = n + 1
as opposed to
myfunction n : Int -> Int = n + 1
This syntax has benefits for documentation, clarity, gradual typing, and so forth. But I see untapped potential for Type-First Development with this system. Just as it sounds, this allows the programmer to write the type signature without having to stub the implementation.
The way things are, writing just
myfunction : Int -> Int causes a compiler error, asking for
myfunction to be implemented. But the compiler could just as easily let me leave the type signature there, but enforce that I don’t call
myfunction. Rather than wasting time stubbing, I’m free to build up my concept of a module just by how I think the types will interplay among its functions.
As a bonus, this naturally lets me build datastructures with the unimplemented function. Suppose I have the trivial data type
type MyType = AFunction (Int -> Int). Then I could call
AFunction myfunction and use this for other things, just as long as I don’t actually call
myfunction anywhere in my code. This lets me focus on implementing other functions without having to come up with some suitable stub that I just have to hope I don’t accidentally call somewhere, perhaps misleading a test.
If Elm chooses to accept this suggestion, then Elm will be a language where you can
* Write just the implementation of a function
* Write the implementation of a function and then the type signature
* (new) Write just type signature of a function
* Write the type signature of a function and then the implementation
completing the last square of the 2x2 matrix.