On Tue, Jun 06, 2006 at 05:11:26PM +0100, Daniel Hulme wrote:
: I only vaguely recall the discussions a while back about what
: smart-matching against Booleans should do. IIRC, there are two
: positions, and a good argument for either side:
:
: C<$foo ~~ True> means C<?$foo>; C<$foo ~~ False> means C<! ?$foo>
: or
: C<$foo ~~ True> means C<True>; C<$foo ~~ False> means C<False>
:
: The first of these adds expressiveness to given/when, and behaves the
: intuitive way when both the RHS of a match is a Boolean-valued variable
: (I would intuitively expect C<$bool1 ~~ $bool2> to do Boolean equality).
: The second means that the default case of a while can be syntactic sugar
: for C<when (true)>, and I see that we went for the latter on those
: grounds.
Actually, those grounds were only part of it. It was also for the
notational convenience of treating C<when> as having C<if> semantics
in some cases, except for the breaking out of the switch at the end
of the block.
However, C<when true> in S04 is now actually illegal syntax.
It'd have to be either C<when .true> or C<when True>. (Or C<when *>
if we decide to make Whatever mean that in that context.)
: However, if we make the Whatever star on the RHS always match, we can
: make C<default> equivalent to C<when (*)>, reminiscently of a shell
: script, and we can also make C<$bool1 ~~ $bool2> do the obvious thing.
: I don't immediately see any big wins for being able to say C<$foo ~~ *>,
: nor any big loses for it no longer falling through to MMD.
:
: Any thoughts?
We could conceivably make C<when *> behave that way regardless of
how C<when True> behaves. It'd be equivalent to C<when {1}> then.
But maybe Whatever isn't symmetrical under smartmatching--I could
imagine using C<given *> to be shorthand for C<given {.true}>, that
is, forcing the C<when> expressions to behave like C<if> conditionals.
The thing I worry about is that when someone writes
given $foo {
when $a == $b {...}
}
they probably don't mean ?$foo == ($a == $b). Whereas when they write
given $foo {
when True {...}
}
they might well mean ?$foo == True.
We could say that boolean comparison happens only if both sides are
exactly equal to the Bool type. So if $foo above isn't a Bool, then
you'd have to be explicit in the given:
given ?$foo {
when True {...}
}
in which case it would compare boolean values. Likewise
given ?$foo {
when $a == $b {...}
}
would compare the boolean value of $foo with the result of the ==.
Or going the other way, we could risk confusing the writer of
when $a == $b {...}
by requiring that to be written:
when {$a == $b} {...}
to explicitly ignore $_ (unless $_ happened to be Whatever). But then
we'd probably have to make smartmatch with a boolean on only one side
completely illegal.
Whatever we do, we need to make sure
given $enum {
when Foo {...}
when Bar {...}
when Baz {...}
}
works as expected. So that tends to argue that
given $bool {
when False {...}
when True {...}
}
should work that way, on the assumption that Bool is just an enum.
But Bool is really a role, and basically any type does Bool. So that
tends to argue for either comparing $a == $b to $bool or illegalifying
it somehow when ambiguous.
Larry
