Types but no TypeClasses in env

[kedashoe]

I apologize in advance for more of my ramblings as in sanctuary-js/sanctuary#206.

I was working on hmDef and realized TypeClass constraints would not work with string definitions even if we give hmDef the env, as there is no way to get the actual implementation. Thoughts on allowing users to add TypeClasses to the env? Obviously things are working as they currently are, but maybe it is an inconsistency of sorts?

Sanctuary internally defines several well-known TypeClasses (Apply, Semigroup, etc) which could be useful to a user when defining their own functions but there is currently no way for a user to access those definitions.

What about creating sanctuary-js/types and sanctuary-js/type-classes? sanctuary-js/sanctuary could then depend on these (incidentally could help address @gilligan 's (I believe) concern that the sanctuary file is pretty big and there is a lot going on) . The types can be exposed as they are now (that way the user wouldn't have to require all these modules themselves), and we can also expose the TypeClasses. Both can also be added to the env, if we decide to go down that route. Another potential benefit of this is that sanctuary-js/types would be very similar to ramda-fantasy which could facilitate the merging of the two projects. Also, I love https://github.com/ramda/ramda-fantasy#available-types and it would be a good place in sanctuary for that table :)

[davidchambers]

Absolutely no need for apologies, Kevin. I value your input and this is another issue full of good ideas.

Thoughts on allowing users to add TypeClasses to the env? Obviously things are working as they currently are, but maybe it is an inconsistency of sorts?

You're right. This is inconsistent. Users should have the ability to provide their own type classes.

Currently, we have:

$.create :: (Boolean, [Type]) -> Function

$.env :: [Type]

We could change the types to:

alias Env = { checkTypes :: Boolean
            , types :: [Type]
            , typeClasses :: [TypeClass]
            }

$.create :: Env -> Function

$.env :: Env

What about creating sanctuary-js/types and sanctuary-js/type-classes?

Great idea! To clarify, you're suggesting the former would contain type definitions (for both built-in types and Sanctuary types) and provide data constructors for the Sanctuary types? In other words, what we now know as $.Number, S.MaybeType, S.Nothing, and S.Just would all be defined there? Makes sense to me. :)

(Due to the way forking works on GitHub, we'd be well advised to use the sanctuary- prefix for these repositories as well.)

Another potential benefit of this is that sanctuary-js/types would be very similar to ramda-fantasy which could facilitate the merging of the two projects.

I like the way you think!

Also, I love https://github.com/ramda/ramda-fantasy#available-types and it would be a good place in sanctuary for that table :)

I've come to realize the importance of such a table. S.reduce, for example, mentions Foldable but nowhere in the document do we make it clear that Sanctuary's Maybe type satisfies Foldable. We shouldn't expect users to memorize the Fantasy Land graph in order to know that all values which satisfy Traversable also satisfy Foldable. I must have consulted that graph a hundred times at this point and still couldn't transcribe it accurately!

[davidchambers]

I remembered why it's not necessary to include type classes in the environment. We must know the types in the environment as we need to know all the possible values of a (or any other type variable) in a type signature. This does not apply to type classes, though, since type classes are always specified explicitly.

The fact remains that exposing type classes for reuse is a great idea. I'll create repositories for sanctuary-types and sanctuary-type-classes this evening. :)

Also, in light of sanctuary-js/sanctuary#206 I'm in favour of changing the input type of $.create from (Boolean, [Type]) to { checkTypes :: Boolean, types :: [Type] }. I'll work on this.

[kedashoe]

you're suggesting the former would contain type definitions (for both built-in types and Sanctuary types) and provide data constructors for the Sanctuary types? In other words, what we now know as $.Number, S.MaybeType, S.Nothing, and S.Just would all be defined there?

I was thinking just the fantasy types, but its not like I'd put a ton of thought into it :) sanctuary-algebraic-types and sanctuary-primitive-types? Or just leave $.Number, etc in sanctuary-def for now?