Check signature of function arguments

[jwoudenberg]

Thanks for the great work on this so far! This lib is a joy to use and the error output is beautiful.

I think it would be cool to be able to specify the signature of a function arguments recursively:

def(
  'Maybe#chain',
  {},
  [$Maybe(a), $.Function([a, $Maybe(b)]), $Maybe(b)],
  (maybe, f) => { ... }
)

Which could result in a TypeError looking like this:

Maybe#chain :: Maybe a -> ( a -> Maybe b ) -> Maybe b
                                 ^^^^^^^
                                    1

What's nice about this is that it shows the full type signature of the monadic bind.

In case of the Maybe-monad of the example above, one could argue that this is not really necessary, as the current TypeError showing the output Maybe b having the wrong type is clear enough.
However, I currently run into an issue with the chain operation of an IO monad that depends internally on f in io.chain(f) returning another instance of IO. In this scenario, when f does not return an IO, chain will throw before a return type is generated for sanctuary-def to check.

To make things work, I'm currently wrapping f itself in another def(), which does the trick. However, I find the resulting TypeErrors harder to understand from the perspective of the library user because they do not contain the context of the full chain invocation, only the context of f itself (a -> Maybe b).

Looking forward to hearing your thoughts 😄.

[davidchambers]

I appreciate the kind words, @jwoudenberg.

You're absolutely right that $.Function limits our ability to express the types of higher-order functions. This is one of two main limitations I'd like to address in the coming months (the other being the lack of parameterized type variables to allow us to express Functor f => (a -> b) -> f a -> f b). I've made a start on this in master...dc-higher-order-functions, which currently supports unary functions which take and return concrete types (e.g. String -> Integer). The thing that will be challenging, I imagine, is supporting type variables, as we'll need to maintain and refine a type-variable-to-types mapping. This will need to work recursively to support function types such as a -> b -> a. We should also support non-unary functions such as (a, b) -> a, though I believe this will be straightforward once we solve the type-variable problem.

I hope to have some time this weekend to work on this. It'll be useful in two open pull requests (sanctuary-js/sanctuary#142 and sanctuary-js/sanctuary#191) so it'll be very satisfying to eventually release a version of sanctuary-def which supports higher-order functions. My guess is it'll take me between 10 and 100 hours to complete the patch, so it's likely to take several weeks.

@jackfirth opened sanctuary-js/sanctuary#157, a related issue with lots of interesting links. :)

[jwoudenberg]

Hey @davidchambers, thanks for the extensive reply. The links contain a lot of interesting stuff, I'll read a bit and perhaps at some point I can contribute something myself.

Nice to hear higher order functions are already on the radar. I can imagine it's not trivial to implement. I'll close this issue in favour of sanctuary-js/sanctuary#157 since it seems it's pretty much a duplicatie.

[davidchambers]

I'll read a bit and perhaps at some point I can contribute something myself.

Excellent. If at some point you'd like to contribute to Sanctuary, and you'd like to collaborate with someone familiar with the code in real time, leave a comment on sanctuary-js/sanctuary#209. :)

I'll close this issue in favour of sanctuary-js/sanctuary#157

Actually, let's keep this issue open as it has a descriptive title and is in the "correct" issue tracker.

[davidchambers]

Resolved via #79