Re: Generalizing ?? !!

On Fri, 22 Jun 2007 15:40:37 +0100, Aaron Crane wrote: > Peter Scott writes: >> can someone tell me why you can't just use && ... || in place of ?? >> ... !!, now that && and || propagate context to both sides? > > You get the wrong result when the antecedent is true and the consequent is > false:

Re: Generalizing ?? !!

Daniel Hulme writes: > On Fri, Jun 22, 2007 at 03:40:37PM +0100, Aaron Crane wrote: > > my $b = 1 && 0 || 42; > > # Now $b is 17 > s/17/42/ or vice-versa, I think. Uh, yes. Serves me right for trying to change metasyntactic numbers midstream. -- Aaron Crane

Re: Generalizing ?? !!

On Fri, Jun 22, 2007 at 03:40:37PM +0100, Aaron Crane wrote: > my $b = 1 && 0 || 42; > # Now $b is 17 s/17/42/ or vice-versa, I think. -- Paraphernalia/Never hides your broken bones,/ And I don't know why you'd want to try:/ It's plain to see you're on your own.-- Paul Simon http://s

Re: Generalizing ?? !!

On Tue, 12 Jun 2007 06:20:49 +1000, Damian Conway wrote: > The mandatory else-part is one of the most valuable features of > the ternary operator. It helps ensure that variables initialized with a > cascaded ternary actually do get initialized Notwithstanding the above argument, can someone tell

Re: Generalizing ?? !!

Peter Scott writes: > can someone tell me why you can't just use && ... || in place of ?? > ... !!, now that && and || propagate context to both sides? You get the wrong result when the antecedent is true and the consequent is false: my $a = 1 ?? 0 !! 42; # Now $a is 0 my $b = 1 && 0 || 42

Re: assign-if-uninitialized [Was: Generalizing ?? !!]

On 6/19/07, Larry Wall <[EMAIL PROTECTED]> wrote: On Tue, Jun 19, 2007 at 11:50:35AM -0400, Charles Bailey wrote: : Yep. For that matter, if I had to pick one change in this area that'd : have maximum impact, I'd say a good assign-if-uninitialized idiom : would be way ahead of an if-then-else id

assign-if-uninitialized [Was: Generalizing ?? !!]

On Tue, Jun 19, 2007 at 11:50:35AM -0400, Charles Bailey wrote: : Yep. For that matter, if I had to pick one change in this area that'd : have maximum impact, I'd say a good assign-if-uninitialized idiom : would be way ahead of an if-then-else idiom. Depending on how you mean "uninitialized", tha

Re: Generalizing ?? !!

[ Sorry to fall off the net for several days . . .] On 6/13/07, Larry Wall <[EMAIL PROTECTED]> wrote: On Wed, Jun 13, 2007 at 05:08:34PM -0400, Charles Bailey wrote: : I'm concerned that the relevant precedent isn't just Perl5. The ?: spelling : of the ternary is pretty deeply embedded in progr

Re: Generalizing ?? !!

On Wed, Jun 13, 2007 at 05:08:34PM -0400, Charles Bailey wrote: : I'm concerned that the relevant precedent isn't just Perl5. The ?: spelling : of the ternary is pretty deeply embedded in programming languages -- I'm : hard pressed to think of a widely used language in the past 10-15 years that :

Re: Generalizing ?? !!

Charles Bailey wrote: I'm concerned that the relevant precedent isn't just Perl5. The ?: spelling of the ternary is pretty deeply embedded in programming languages -- I'm hard pressed to think of a widely used language in the past 10-15 years that spells it differently (though that may say more

Re: Generalizing ?? !!

On 6/11/07, Luke Palmer <[EMAIL PROTECTED]> wrote: On 6/11/07, Jonathan Lang <[EMAIL PROTECTED]> wrote: > > Still, Damian has a good point - which renders the bulk of this > discussion moot. The one thing left to consider (IMHO) is whether or > not it's worthwhile (or even possible) to go back

Re: Generalizing ?? !!

On Mon, Jun 11, 2007 at 01:43:40AM -, NeonGraal wrote: > Surely if you defined !! to return "undef but true" and both operators > to be left associative then it all works. > > 1==0 ?? "True" !! "False" -> (undef) !! "False" which seems right to > me. > > 1==1 !! "False" ?? "True" -> (undef

Re: Generalizing ?? !!

On 6/11/07, Jonathan Lang <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: > Besides ?? !! with out an else part is just &&. No, it isn't. While && behaves properly when the condition turns out to be true, the result of the condition turning out to be false is whatever the condition turned o

Re: Generalizing ?? !!

[EMAIL PROTECTED] wrote: Besides ?? !! with out an else part is just &&. No, it isn't. While && behaves properly when the condition turns out to be true, the result of the condition turning out to be false is whatever the condition turned out to be. Still, Damian has a good point - which rend

Re: Generalizing ?? !!

Besides ?? !! with out an else part is just &&. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: Damian Conway <[EMAIL PROTECTED]> > Mark J. Reed concluded: > > > So I prefer keeping a single construct, but perhaps

Re: Generalizing ?? !!

Mark J. Reed concluded: So I prefer keeping a single construct, but perhaps the else-part could be optional? I hope not. The mandatory else-part is one of the most valuable features of the ternary operator. It helps ensure that variables initialized with a cascaded ternary actually do get in

Re: Generalizing ?? !!

Ok, let me take a step back and see what's being suggested. it certainly seems like a case can be made for a binary operator, say ??, that returns its rhs if the lhs is true, undef otherwise, analogous to the shell's ${var+val} construct. At first glance it appears that the desired ternary behav

Re: Generalizing ?? !!

On Mon, Jun 11, 2007 at 12:16:35PM +0200, Juerd Waalboer wrote: : Zev Benjamin skribis 2007-06-11 0:57 (-0400): : > ?? and !! could always return some kind of result object that boolizes : > to true or false. : : Can we *please* keep simple things simple? Indeed, basic control flow is not a good

Re: Generalizing ?? !!

Audrey Tang wrote: Jonathan Lang wrote: > A variation of chaining associativity gets > used, with the "chaining rule" being '$v1 op1 $v2 // $v1 op2 $v3' > instead of '$v1 op1 $v2 && $v2 op2 $v3', as is the case for comparison > chaining. But wouldn't that make: True ?? undef !! Moose; evalu

Re: Generalizing ?? !!

Zev Benjamin skribis 2007-06-11 0:57 (-0400): > ?? and !! could always return some kind of result object that boolizes > to true or false. Can we *please* keep simple things simple? -- korajn salutojn, juerd waalboer: perl hacker <[EMAIL PROTECTED]> convolution:

Re: Generalizing ?? !!

?? and !! could always return some kind of result object that boolizes to true or false. Zev Audrey Tang wrote: > > 在 Jun 11, 2007 5:10 AM 時，Jonathan Lang 寫到： >> A variation of chaining associativity gets >> used, with the "chaining rule" being '$v1 op1 $v2 // $v1 op2 $v3' >> instead of '$v1 op

Re: Generalizing ?? !!

On Jun 11, 9:10 am, [EMAIL PROTECTED] (Jonathan Lang) wrote: > Rereading A03, I ran across the original reasoning behind why Perl 5's > '?:' trinary operator became '?? ::' first, and then '?? !!'. Three > reasons were given: > > * the '?' and ':' tokens are far too broadly useful to be gobbled up

Re: Generalizing ?? !!

On 11/06/07, Audrey Tang <[EMAIL PROTECTED]> wrote: 在 Jun 11, 2007 5:10 AM 時，Jonathan Lang 寫到： > A variation of chaining associativity gets > used, with the "chaining rule" being '$v1 op1 $v2 // $v1 op2 $v3' > instead of '$v1 op1 $v2 && $v2 op2 $v3', as is the case for comparison > chaining. Bu

Re: Generalizing ?? !!

在 Jun 11, 2007 5:10 AM 時，Jonathan Lang 寫到： A variation of chaining associativity gets used, with the "chaining rule" being '$v1 op1 $v2 // $v1 op2 $v3' instead of '$v1 op1 $v2 && $v2 op2 $v3', as is the case for comparison chaining. But wouldn't that make: True ?? undef !! Moose; evaluate

Generalizing ?? !!

Rereading A03, I ran across the original reasoning behind why Perl 5's '?:' trinary operator became '?? ::' first, and then '?? !!'. Three reasons were given: * the '?' and ':' tokens are far too broadly useful to be gobbled up by the trinary operator. * the doubled symbols bring to mind the sh

Re: Generalizing value property setting to become postits

> > Me: > [$foo is bar] can change the value of $foo. > > > Damian: > Yes. For example: > my $foo is persistent; > > Could you explain this further please? The programmer has specified a property named 'persistent'. The programmer has marked the

Re: Generalizing value property setting to become postits

> > What I was suggesting was to consider broadening what the > > $foo : bar style postfix sub syntax allows/assists bar to do, > > so that bars can be used to set properties OR do other stuff. > > > What's the practical utility of this? 1. Simplification for perl 6 implementation. I would expec

Re: Generalizing value property setting to become postits

> What I was suggesting was to consider broadening what the > $foo : bar style postfix sub syntax allows/assists bar to do, > so that bars can be used to set properties OR do other stuff. > What's the practical utility of this? This discussion has been pretty abstract so far... It's easy to see ho

Re: Generalizing value property setting to become postits

> Me: [$foo is bar] can change the value of $foo. > Damian: Yes. For example: my $foo is persistent; Could you explain this further please? > Me: $foo : bar baz is roughly equivalent to baz(bar($foo)) > Damian: Err. No. That would be:

Re: Generalizing value properties to become postits

On 7/3/01 8:14 PM, Damian Conway wrote: > You lost me here. Your ideas for properties are different from mine > (which may well, in turn, be different from Larry's). Anyone else get the feeling that properties are to Perl 6 what oo was to Perl 5? :) It's like we'll finally be getting the oo bit

Re: Generalizing value properties to become postits

> Simplifying somewhat (ok, a heck of a lot), an rvalued: > > $foo is bar > > or > > $foo : bar > > is syntactic sugar for: > > bar($foo) > > with some extra magic for handling a properties hash > associated with $foo's value, in particul

Generalizing value properties to become postits

Simplifying somewhat (ok, a heck of a lot), an rvalued: $foo is bar or $foo : bar is syntactic sugar for: bar($foo) with some extra magic for handling a properties hash associated with $foo's value, in particular resetting the hash when $foo's value changes. Right? Basically, p