~~ with *
Daniel Hulme
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.
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?
--
"Twelve? Who needs twelve? Couldn't we make do with six?" -- Lew Grade,
<keyid 885b170d> trying to cut production costs on 'Jesus of Nazareth'
<http://surreal.istic.org/> "The illegal we do immediately,
the unconstitutional takes a little longer." Henry Kissinger, June 1972
Larry Wall
: 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
Eric
>
> given $bool {
> when False {...}
> when True {...}
> }
>
Just my two cents, but whenever i see "when True {...}" I expect $_
to be true, so that i can do when True and when False. And I if see
when followed by a comparison i expect the when to be true when the
comparison is true. To me its kind of like, if you only have one
operand then use the given subject, if you have two operands then they
don't need a subject. So the given $_ topic would fill in only in the
cases where you needed a topic. Of course that might not realy make
since for given/when and its smart matching magic. But then maybe we
just don't want to be able to say "when $a == $b" and thats just
invalid since it would be clearer written as an if.
--
--
__________
Eric Hodges
Larry Wall
: Just my two cents, but whenever i see "when True {...}" I expect $_
: to be true, so that i can do when True and when False. And I if see
: when followed by a comparison i expect the when to be true when the
: comparison is true. To me its kind of like, if you only have one
: operand then use the given subject, if you have two operands then they
: don't need a subject. So the given $_ topic would fill in only in the
: cases where you needed a topic. Of course that might not realy make
: since for given/when and its smart matching magic. But then maybe we
: just don't want to be able to say "when $a == $b" and thats just
: invalid since it would be clearer written as an if.
After much mulling, I've I've left booleans in a priviledged state of
assuming {...} around themselves. (Wrapping in {...} is the generic
method of suppressing comparison to $_, though ? and true() also work
for that.) You can always write
given $boolean {
when .true {...}
when .not {...}
}
to mean the other thing. Or horrors, maybe even just use an "if"...
Larry