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:
my $a
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;
#
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
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
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
[ 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
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, that
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 to '$c
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
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
:
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 but true) ?? True
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.
But
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
by
?? 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 op1 $v2
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] http://juerd.nl/sig
convolution: ict
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
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;
evaluate to
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
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
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 the
[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 renders
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 out to
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
在 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 to
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 $foo
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 expect it to
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:
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 how
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
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
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,
31 matches
Mail list logo
