davidchambers
commented
8 years ago Thank you for opening this issue, @jackfirth, and for going into quite a bit of detail! Apologies in advance for going off on a slight tangent. :)
Let's consider a familiar function, map, whose type signature is difficult to express in many languages:
map :: Functor f => (a -> b) -> f a -> f bWith sanctuary-def, the closest we can currently get is [$.Function, a, b], which is not very useful at all. However, I've been letting this "scary" case deter me from making steps in this direction. Let's replace a, b, and f with concrete types to simplify matters:
(String -> Integer) -> Array String -> Array IntegerNow, sanctuary-def gets us closer:
[$.Function, $.Array($.String), $.Array($.Integer)]What if we could write $.Function([$.String, $.Integer]) as the first argument? We'd then need to decorate the provided function like so:
function(x) {
if (/* `x :: String` not satisfied */) {
throw new TypeError('…');
}
var result = f(x);
if (/* `result :: Integer` not satisfied */) {
throw new TypeError('…');
}
return result;
}This is achievable.
Dealing with type variables is more involved. Let's take another step:
[$.Function([a, b]), $.Array(a), $.Array(b)]We'd first determine the set of types common to the a values of the second argument. We'd then need to decorate the provided function such that it:
- asserts that each value to which it is applied is a member of at least one of the common types; and
- refines the set of common types as we encounter more
avalues.
This is achievable, though not straightforward.
The final step is to support "higher" type variables such as the f in map :: Functor f => (a -> b) -> f a -> f b (if you know the correct term for this please let me know). I imagine the logic would be similar to that which currently exists for handling type variables, but would not be recursive, and would limit the search space to (in this case) unary types.
I'll spend some time playing with sweet.js to see whether it supports bounded parametric polymorphism. If it does, I'll study the code it generates to do so. I'd love to add this functionality to sanctuary-def. Another option is to use sweet.js itself, of course, though I'm keen to avoid a build step if possible.
jackfirth
Sanctuary strives to complement Ramda with safe, total functions providing strong guarantees about their behavior. Enforcement is via first-order type checking, e.g. throwing TypeError when given a Number where a String is expected. However, higher-order properties are more difficult to enforce - how does one verify that the function given to
Maybe.filterreturns a boolean? You can check that the given value is a function but that's not enough, you'd have to check that it returns a boolean every time it's called in the implementation ofMaybe.filter.Contracts are designed to solve this problem:
And just look at the error messages!
That funny looking
@ ...line, as careful readers might note, isn't valid javascript. It's asweet.jsmacro, a rule for transforming code from arbitrary syntax into valid javascript. The Sweet JS macro and build system provides a framework for defining these macros, and tools to generate "normal" javascript from "sweet" javascript. Using these contracts in Sanctuary would therefore imply some nontrivial wrangling of its current build system and release process, but it would be invisible to clients of the library. I would argue it falls well within the philosophy of Sanctuary to provide this.