Add type signatures to spec

[scott-christopher]

Addresses #138

Throwing this up as a bit of a strawman, as there will no doubt be differing opinions around syntax.

I put forward the following suggestion:

sequence :: Apply f, Traversable t => t (f a) ~> (b -> f b) -> f (t a)
'------'    '--------------------'    '-----'    '-------------------'
   '- method name     '- constraints     '- method target  '- method arguments

I'm also not sure whether an explanation of the syntax should be included in the spec or not.

[SimonRichardson]

👍

[rpominov]

This looks great! Only one thing worries me, this type syntax was designed for curried functions, while our methods are not curried.

For instance:

 reduce :: Foldable f => f a ~> (b -> a -> b) -> b -> b

seems like a.reduce(fn) returns a function, and that fn should be curried.

[scott-christopher]

Only one thing worries me, this type syntax was designed for curried functions, while our methods are not curried.

Good point. We could using tuples to represent arguments instead.

Foldable f => f a ~> (((b, a) -> b), b) -> b

It seems like it's a bit of a trade off in terms of readability.

Also, is there any preference for keeping or removing the method name from the signature?

[rpominov]

+1 for tuples, this would be more correct.

[rpominov]

Ah, maybe we could also remove descriptions like the following now?

The `equals` method takes one argument:

     a.equals(b)

 1. `b` must be a value of the same Setoid

     1. If `b` is not the same Setoid, behaviour of `equals` is
        unspecified (returning `false` is recommended).

 2. `equals` must return a boolean (`true` or `false`).

Since this is basically type signatures in english, and we now have proper type signatures.

[SimonRichardson]

Can we keep both? I find that it lends to the appeal of the spec, as in, some people don't know how to read haskell and reading the description helps people understand that.

[davidchambers]

I'm very much in favour of this proposal.

In Haskell the constraints are parenthesized when there are multiple constraints. I don't know whether there's a compelling reason for this or whether the decision was made to simplify the grammar.

[SimonRichardson]

@joneshf you happy for me to merge this one?

[davidchambers]

Should this be Applicative f rather than Apply f? c -> f c is of essentially, isn't it?

[scott-christopher]

In practice yes, but I decided to just use the Apply constraint here because the of function (or any function that can lift a value into the Apply) has to be provided by the caller, so the constraint is then just that the type returned by the given function must be an Apply.

[davidchambers]

Ah, so you're drawing a distinction between a type which could provide of and a type which actually provides it. My view is that every type which can provide of should do so, but I understand your position.

[scott-christopher]

I'd be happy for it to change if it would help avoid confusion.

[davidchambers]

In Haskell b -> f b would be inferred from f rather than provided as an argument, so f would need to satisfy Applicative.

In JavaScript f doesn't need to satisfy Applicative, strictly speaking, though it must be capable of supporting Applicative.

Apply f => is technically correct; Applicative f => is more descriptive. The question is whether we should favour correctness or descriptiveness. Does anyone have a strong view on this?

[rpominov]

I can add a point that in laws we use Applicative (e.g. "for any Applicative F"), although maybe we should use Apply in laws :)