is can be fooled

[futpib]

S.is(function Number () {}, 4)
// -> true

While documentation says:

is :: TypeRep a -⁠> Any -⁠> Boolean

Takes a type representative and a value of any
type and returns true iff the given value is of the specified type.
Subtyping is not respected.

[davidchambers]

S.is predates $.test. Now that the latter exists I suggest using it exclusively, as it's far more expressive:

> $.test ([]) ($.Number) (4)
true

> $.test ([]) ($.Array ($.Integer)) ([1, 2, 3])
true

> $.test ([]) ($.Array ($.Integer)) ([1, 2, 3.14])
false

Can we prevent S.is from being fooled without reintroducing the problems solved in #100?

Perhaps we should remove S.is. It was a reasonable stopgap, but we now have a good solution.

[gautaz]

Not sure about this but perhaps S.is could be kept as an alias for $.test(S.env)?

This would break the backward compatibility with the current S.is but as removing it seems an option, backward compatibility will be broken anyway.

[tomkel]

Yeah, it may be cleaner API-wise to only need to interact with properties on S.

David, are there any downsides to this alias?

[futpib]

only need to interact with properties on S.

You would need to export all type identifiers from $ to S to achieve that.

[gautaz]

You would need to export all type identifiers from $ to S to achieve that.

That's true, I was just advocating for a less radical approach such as writing things like S.is($.Integer) but I also understand the point raised by @tomkel.

A simple way to interact only with S would be something like S.is(S.$.Integer) but that seems ugly at first thought...

[davidchambers]

Not sure about this but perhaps S.is could be kept as an alias for $.test(S.env)?

This is an interesting idea, @gautaz. It would make S.get, S.gets, and S.parseJson more convenient to use with Type values, diminishing the need for the variants proposed in #481.

@Avaq, what do you think of the possibility of repurposing S.is?

[Avaq]

I prefer re-purposing S.is over #481.