type of Z.of

What’s the appropriate type of Z.of? There appear to be two options:

of :: Applicative f => (f a, b) -> f b

of :: Applicative f => ({ fantasy-land/of :: a -> f a }, b) -> f b

The advantage of the first option is that given Applicative f => f a we can find the of function in either of the valid locations:

typeof x['fantasy-land/of'] === 'function' ? x['fantasy-land/of']
                                           : x.constructor['fantasy-land/of']

With the second option the caller would need to do this work:

Z.of(typeof x['fantasy-land/of'] === 'function' ? x : x.constructor, 42)

We shouldn’t optimize for the case in which we already have a value of the type, though. After all, the purpose of of is to allow us to create values of the type so we shouldn’t need to create a value of the type in order to create a value of the type! Thus the second option seems more sensible. Do others agree?

Whatever we decide here should determine the type of Z.chainRec as well. Z.empty is a different matter because an empty method is strictly more powerful than an empty function (though this will no longer apply if and when fantasyland/fantasy-land#164 is merged).

[davidchambers]

I’ve updated #2. Please have a look at the change and let me know your thoughts. 😃

[davidchambers]

That would be very nice, @safareli, but the FL spec doesn’t require Type values such as S.Maybe to exist. Everything in the spec is written from the perspective of a member of a type. So we need to accept a type dictionary, but we don’t know where such a dictionary will come from. It could be Foo itself, or Foo.prototype, or Foo.of(42), or new Foo(42).

I think the spec should require a Type value to be defined. of, empty, and chainRec should be defined on the Type value (and nowhere else), and each member of the type should have a fantasy-land/type property which points to the Type value. Then a function such as Z.of could simply require a Type value as an argument.