On Tue, Aug 3, 2010 at 3:30 PM, David Green wrote:
> On 2010-08-02, at 2:35 pm, TSa (Thomas Sandlaß) wrote:
> > On Monday, 2. August 2010 20:02:40 Mark J. Reed wrote:
> >> [...] it's at least surprising. I'd expect (anything ~~ True) to be
> synonymous with ?(anything)
> > Note also that ($anyth
On the one hand, I've had 25 years of being annoyed about the idiom
if foo() == True ...
So I'd be delighted if P6 were to treat that case as a fatal compile-time
error.
And given that "==" are "!=" are just funny ways of writing "!xor" and
"xor", that prohibition could reasonably be ext
On 2010-08-02, at 2:35 pm, TSa (Thomas Sandlaß) wrote:
> On Monday, 2. August 2010 20:02:40 Mark J. Reed wrote:
>> [...] it's at least surprising. I'd expect (anything ~~ True) to be
>> synonymous with ?(anything)
> Note also that ($anything ~~ foo()) just throws away $anything.
No; only if foo(
HaloO,
On Monday, 2. August 2010 20:02:40 Mark J. Reed wrote:
> On Sun, Aug 1, 2010 at 6:02 PM, Jonathan Worthington
wrote:
> > No, given-when is smart-matching. The RHS of a smart-match decides what
> > happens. If you do True ~~ 1 then that's 1.ACCEPTS(True) which is going
> > to do +True and
On Mon, Aug 2, 2010 at 2:02 PM, Mark J. Reed wrote:
> On Sun, Aug 1, 2010 at 6:02 PM, Jonathan Worthington
> wrote:
>> No, given-when is smart-matching. The RHS of a smart-match decides what
>> happens. If you do True ~~ 1 then that's 1.ACCEPTS(True) which is going to
>> do +True and thus match.
On Sun, Aug 1, 2010 at 6:02 PM, Jonathan Worthington wrote:
> No, given-when is smart-matching. The RHS of a smart-match decides what
> happens. If you do True ~~ 1 then that's 1.ACCEPTS(True) which is going to
> do +True and thus match.
OK, but what about 0 ~~ True? That's what started this thr
Darren Duncan wrote:
TSa (Thomas Sandlaß) wrote:
... unless you want C 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 dis
TSa (Thomas Sandlaß) wrote:
... unless you want C 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 wh
HaloO,
On Saturday, 31. July 2010 20:47:49 Patrick R. Michaud wrote:
> On Sat, Jul 31, 2010 at 10:56:47AM -0600, David Green wrote:
> > It's not unreasonable, especially if that's what you expect.
> > But it's even more reasonable to expect this to work:
> > given $something {
> >
David Green wrote:
given $foo :using( [===] ) { ... }
given $foo :using(&binary-func) { ... }
I do like the general principle of what you're proposing, that one can customize
the semantics of how given-when picks options. But I have no further details to
suggest at this time. -- Da
On 2010-07-31, at 2:00 pm, TSa (Thomas Sandlaß) wrote:
> On Saturday, 31. July 2010 18:56:47 David Green wrote:
>> given $who-knows-what {
>> when True { say "It's a true thing!" }
# ^--oops, this still shouldn't come first!
>> when 42 { say "It's numbery!" }
>> whenever timeout(
On 2010-07-31, at 5:55 pm, Darren Duncan wrote:
> I would prefer if given/when was nothing more than an alternate syntax for
> if/then that does comparisons.
And that breaks out of its enclosing scope.
> On the other hand, Perl 6 has multiple equality comparison operators, eqv,
> eq, ==, ===,
On 2010-07-31, at 11:38 am, Brandon S Allbery KF8NH wrote:
> Thank you; *that* is the real point I was trying to make. That, and that
> special-casing one particular type is *not* actually helpful; it means I must
> remember a special case, when one of the goals of Perl 6 was supposedly to
> el
On 2010-07-31, at 12:47 pm, Patrick R. Michaud wrote:
> On Sat, Jul 31, 2010 at 10:56:47AM -0600, David Green wrote:
>> given $something {
>> when True { say "That's the truth!" }
>> when 42 { say "Good answer!" }
>> when "viaduct" { say "You guessed the secret word!" }
>> }
> I'm
Darren (>):
> All this being said, I really do *not* like the idea of saying Bool is just
> a subset of Int as it seems to be. Bool should be disjoint from every other
> common type like Int/Str/etc instead.
I don't know whence you got the impression that Bool is a subtype.
Bool is an enumeration
Brandon S Allbery KF8NH wrote:
I think there's a confusion about what given/when is doing. Naïvely(?), I
expect it to be shorthand where the value for "when" is matched against the
one for "given", thus your example would be (pseudocode) "if 0 == True" and
expecting "OH NOEZ" *would* be unreason
On Sat, Jul 31, 2010 at 04:29:00PM -0400, Aaron Sherman wrote:
> My problem with that is that it's a really odd use of given/when, and given
> the implicit smart-match, it doesn't make much sense. Now, to slightly
> backtrack, I do agree that there should be at least one way to do something,
> and
On Sat, Jul 31, 2010 at 12:56 PM, David Green wrote:
> > On 2010-07-30, at 4:57 pm, Aaron Sherman wrote:
> >> given False { when True { say "True" } when False { Say "False" }
> default { say "Dairy" } }
> >> I don't think it's unreasonable to expect the output to be "False".
> >> However, it act
HaloO,
On Saturday, 31. July 2010 18:56:47 David Green wrote:
> On 2010-07-31, at 1:33 am, Moritz Lenz wrote:
> > sub test() { True };
> > given 0 { when test() { say "OH NOEZ" } }
> > I don't think it's unreasonable to expect the output to be "OH NOEZ".
How does this relate the given to the when
On Sat, Jul 31, 2010 at 10:56:47AM -0600, David Green wrote:
> It's not unreasonable, especially if that's what you expect.
> But it's even more reasonable to expect this to work:
> given $something {
> when True { say "That's the truth!" }
> when 42 { say "Good
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/31/10 12:56 , David Green wrote:
> a boolean IS useful. The fact that this question keeps coming up,
> even on the p6l list, seems to demonstrate that the "helpful" way
> isn't completely natural or obvious (at least, not to everyone).
Thank you;
> On 2010-07-30, at 4:57 pm, Aaron Sherman wrote:
>> given False { when True { say "True" } when False { Say "False" } default {
>> say "Dairy" } }
>> I don't think it's unreasonable to expect the output to be "False".
>> However, it actually outputs "True". Why? Well, because it's in the spec
>>
On Sat, Jul 31, 2010 at 11:47:13AM -0400, Brandon S Allbery KF8NH wrote:
> [...], and
> if the point is to be a general case statement then "when "
> should smartmatch against $_ instead of evaluating it with $_
> available as a shorthand/topic.
This is exactly what "when block" does -- it sm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/31/10 11:17 , Mark J. Reed wrote:
> What if you say 'when test($_)'? Or just 'when &test'? How do you
> smart match on a function: call the func with the target as argument
> and use the return value, or call it without any argument and compare
What if you say 'when test($_)'? Or just 'when &test'? How do you
smart match on a function: call the func with the target as argument
and use the return value, or call it without any argument and compare
the return value to the target? Does arity matter? Or whether the
function is declared to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/31/10 03:33 , Moritz Lenz wrote:
> In this code:
>
> sub test() { True };
>
> given 0 {
> when test() { say "OH NOEZ" }
> }
>
> I don't think it's unreasonable to expect the output to be "OH NOEZ".
I think there's a confusion about what gi
Aaron Sherman wrote:
> In this code:
>
> given False {
> when True { say "True" }
> when False { Say "False" }
> default { say "Dairy" }
> }
>
> I don't think it's unreasonable to expect the output to be "False".
In this code:
sub test() { True };
given 0 {
when test() { say "OH NOEZ
27 matches
Mail list logo
