Re: series operator issues

On 2010-07-23, at 4:25 am, Moritz Lenz wrote: > I'm still not convinced. [that there should be a special index variable] > Yes, it would be convient, but I've yet to see a non-contrived example where > it's actually necessary, and which can't be implemented trivially with other > Perl 6 tools.

Re: Unwanted warnings (was Re: Something wrong with str.reverse)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 23:26 , David Green wrote: > On 2010-06-18, at 10:48 am, Larry Wall wrote: >>0123; # warns >>0123; # ok! # suppresses this warning here >>0123; # OK! # suppresses this warning from now on >

Unwanted warnings (was Re: Something wrong with str.reverse)

On 2010-06-18, at 10:48 am, Larry Wall wrote: > If you make it the default to not warn, then the people who really need the > warnings will almost never turn them on. If you make it default to warn, > then people will have to turn off the warnings forever. Doesn't the site-policy policy help he

Re: Smart match isn't on Bool

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

Re: Smart match isn't on Bool

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(

Re: Smart match isn't on Bool

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, ==, ===,

Re: Smart match isn't on Bool

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

Re: Smart match isn't on Bool

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

Re: Smart match isn't on Bool

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

Re: Smart match isn't on Bool

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

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

Carl (>>), sorear (>): >> * It has been decided that attribute slots of the type $!foo are only >> allowed *syntactically* within the class block that declares them. >> (The exception to this, I guess, is the 'trusts' directive.) But this >> means that something like this anonymous method >> >>    

Re: Smart match isn't on Bool

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

Re: Smart match isn't on Bool

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

Re: Smart match isn't on Bool

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

S26 broken link

Hi, The link to the S26 Synopsys on http://perlcabal.org/syn/ points to http://perlcabal.org/syn/S26.html which is a broken link - would it be possible to fix this? My apologies if this is the wrong place to ask this question. Best regards, -- Offer Kaye

Re: Smart match isn't on Bool

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

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 14:38 , Stefan O'Rear wrote: > On Sat, Jul 31, 2010 at 02:36:02PM -0400, Brandon S Allbery KF8NH wrote: >> The whole concept of detaching and attaching methods seems suspect to me; in >> particular, attaching a method from a class not declar

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

On Sat, Jul 31, 2010 at 02:36:02PM -0400, Brandon S Allbery KF8NH wrote: > On 7/31/10 14:23 , Carl Mäsak wrote: > > a. Allow this form of encapsulation breakage. > > b. Disallow detaching of certain methods. > > c. Disallow attaching of certain anonymous methods. > > > > I must confess I don't par

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

On Sat, Jul 31, 2010 at 08:23:29PM +0200, Carl Mäsak wrote: > * It has been decided that attribute slots of the type $!foo are only > allowed *syntactically* within the class block that declares them. > (The exception to this, I guess, is the 'trusts' directive.) But this > means that something lik

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 14:23 , Carl Mäsak wrote: > a. Allow this form of encapsulation breakage. > b. Disallow detaching of certain methods. > c. Disallow attaching of certain anonymous methods. > > I must confess I don't particularly like either option. I'm by n

Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

Here's a case where a bug report stumped me and made me feel I'm missing something: I'll give a somewhat summarized version of the above page, which gradually turns into a set of questions and not enough answers: * It has been decided that a

Re: Smart match isn't on Bool

-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;

Re: Smart match isn't on Bool

> 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 >>

Re: Smart match isn't on Bool

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

Re: Smart match isn't on Bool

-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

Re: Smart match isn't on Bool

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

Re: Smart match isn't on Bool

-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

r31883 -[S26] Attempts at clarifying language

Author: jani Date: 2010-07-31 11:49:53 +0200 (Sat, 31 Jul 2010) New Revision: 31883 Modified: docs/Perl6/Spec/S26-documentation.pod Log: [S26] Attempts at clarifying language Modified: docs/Perl6/Spec/S26-documentation.pod === ---

Re: Smart match isn't on Bool

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