Type validation using predicates rather than TypeRep's

[Avaq]

Since most type-checking libraries provide convenient ways to get the predicate for a type, this would allow for much greater interoperability with run-time type systems.

With Sanctuary:

const isInt = allPass([is(Number), x => x % 1 === 0]);

get(isInt, 'x', {x: 0.5}); //-> Nothing

With TComb:

const Int = t.refinement(t.Number, x => x % 1 === 0, 'Int');

get(Int.is, 'x', {x: 0.5}); //-> Nothing

With Sanctuary Def:

const Int = $.NullaryType('my/Int', allPass([is(Number), x => x % 1 === 0]));

get(Int.test, 'x', {x: 0.5}); //-> Nothing

The possibilities are endless! Another option is to accept Sanctuary Def types, which would make the code a little more concise, but the possibilities slightly less endless.

[davidchambers]

Another option is to accept Sanctuary Def types, which would make the code a little more concise, but the possibilities slightly less endless.

I'd like to keep the possibilities endless. :)

I'd like it to remain possible to use Sanctuary without sanctuary-def. It's nice that one could preserve the current behaviour simply by replacing S.get(X) with S.get(S.is(X)).

This change would let us replace TypeRep b with (Any -> Boolean) in several type signatures. Sanctuary-specific things make me uneasy. Predicates are commonplace.

[svozza]

How would this feature work with sanctuary-js/sanctuary-def#28?

[Avaq]

@svozza I would imagine $.Type.test is still an operational predicate even if automatic run-time type-checking is turned off. This feature is about explicit type-checking, you wouldn't want that turned off even in production because the behaviour of your program depends on it, eg:

pipe([
  gets($.Array.test, ['response', 'body']),
  maybeToEither(new Error('Expected response body to be an array'))
])

A good way to think about it, I find, is to think of sanctuary-def as performing runtime type checking and the feature being proposed here having to do with type validation.

[svozza]

Fair enough, makes sense. I would go the other way though and not mix the concerns of validating types with those of getting a value and have this as a separate function in the pipeline.

[Avaq]

As I remarked in #150, I do think that would be more elegant. But I'm really quite fond of the way these functions force me to do type validation where appropriate. I think it's a good effect to have, and one of my main reasons for using functions that return Monads to begin with.

[davidchambers]

I'm really quite fond of the way these functions force me to do type validation

I am too. This was the motivation for adding the type arguments in #64.

[davidchambers]

Are you interested in working on these changes, @Avaq?

[Avaq]

I am, but I haven't found the time yet. If I do start work on it I'll leave a notice. Until then you're free to pick it up instead, if you have the time. Let me know if you do. :)

[davidchambers]

I'll leave this one for you. There are plenty of other issues to keep me occupied for the time being. :)

[Avaq]

ℹ️ I started working on this.

[Avaq]

Oh! Of course! I could've just assigned myself. ;)

[davidchambers]

No worries. I appreciated the :information_source: emoji. :)