Darren Duncan wrote:
TSa (Thomas Sandlaß) wrote:
... unless you want C<when True> to do a value-and-type check,
in which case it doesn't exactly follow the pattern for smartmatching
of the other builtin types (which only check value equivalence,
not type equivalence).
This is true only if you want to distinguish 1 and True which are the
same value. But 42 should be distinct from this. Same goes for
"viaduct".
So these three should be a valid disjoint set of choices that can be
made given $something.
Is that so? 1 and True *are* the same value now?
No, they aren't.
Not Bool wraps Int rather than being a subset type and it and has
wholly distinct values?
We look at Bool as an enumeration type. The base type of that
enumeration type may well represent False and True as 0 and 1, but
that's an implementation detail. They're not "eqv" or "===".
Carl Mäsak wrote:
> I don't know whence you got the impression that Bool is a subtype.
> Bool is an enumeration type, which makes True and False distinct
> objects both of which aren't (but instead wrap) their corresponding
> Int values.
>
>> Asking "False eqv 0" should be false, though either "False eqv ?0" or
>> "+False eqv 0" being true is okay.
>
> All those are as you want them.
I would like for what Carl said to be true, but TSa seems to be
contradicting it.
Carl is correct.
1 and True should *not* be the same value, and they should be
distinguishable in any generic context like eqv
Correct.
or given-when.
No, given-when is smart-matching. The RHS of a smart-match decides what
happens. If you to True ~~ 1 then that's 1.ACCEPTS(True) which is going
to do +True and thus match.
They should only compare alike when cast into the same type such as
with a ? or +.
Right, which happens in given/when.
Jonathan
