Under Sanctuary section of README BinaryType should also take url about fluture HOT 6 CLOSED

Aldwin, I believe it's worth considering once more the possibility of defining and exporting FutureType :: Type -> Type -> Type. Error messages could then reference URLs such as https://github.com/Avaq/Fluture/tree/5.0.0#FutureType.

from fluture.

I see how exporting a FutureType seems more convenient for users who wish to inter-operate with Sanctuary but consider my thoughts:

1. Adding a large library such as sanctuary-def may not be justified for such a small and likely not often used feature, but more importantly;
2. There is no way for me to know whether types created by def 0.8 are compatible with types created by def 0.9 (or whatever, it even might break with minor releases). Therefore my FutureType may work with Sanctuary 0.11, but not 0.12. If I would update my sanctuary-def, I might remove compatibility with older Sanctuary versions. This "documentation" approach assumes that the sanctuary-def public API will undergo fewer changes than the sanctuary-def internals with every new release. It enables the user to choose which sanctuary-def version to use to define their FutureType. The alternative would be FutureType :: Def -> Type -> Type -> Type but that doesn't account for stuff like the added arguments that triggered this issue.

Looking at these points, I would be inclined to think that the documentation approach I'm currently using is the best option I have. I think I should keep the documentation up-to-date with the latest version of sanctuary-def and have users figure out what to do if they need to define their type with a different version.

from fluture.

Good points, Aldwin. You've convinced me. :)

It would be really nice if the correctness of the code examples were verified as part of the test suite, but this is likely to be more trouble than it's worth.

from fluture.

After writing about it in the issue above, I realized I may add sanctuary-def under peerDependencies, and try to require it, and export the type if I was able to load sanctuary-def.

from fluture.

It does reduce flexibility a little bit though. Suddenly a user is bound to the range of versions of sanctuary-def where the API of BinaryType stayed the same, whereas with the readme on the side, they can make the appropriate adjustments to use their favorite version of sanctuary-def. Hmm..

from fluture.

I may add sanctuary-def under peerDependencies

This sounds like a good idea.

export the type if I was able to load sanctuary-def

My initial reaction is negative, as conditional exports could be surprising. I can see the convenience, though.

It does reduce flexibility a little bit though.

The right approach is not obvious.

from fluture.