HaloO,
John M. Dlugosz wrote:
Any strong feeling about order-of-evaluation issues?
And short-circuiting of the implicit and. I think
f() g() h() is re-written by the compiler as
f() ($temp = g()) $temp h(). Note that C#
defines the order of evaluation as strictly left to
right. And I
On Wed, Apr 16, 2008 at 11:19:33PM -0400, Bob Rogers wrote:
Pardon a lurker, but I'm not sure I understand the point of this. In:
if $x $y $z { ... }
I would expect a sensible compiler short-circuit the $x $y part, and
indeed the Chained comparisons section of S03 (version 135
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Why the complicated sig? Note that the left sequential definition
enforces that ($a + $b) + $c dispatches to a version of + with the
return type of the lhs addition. That is you need lots of overloaded
versions of listfix +. Nonetheless I would
From: Patrick R. Michaud [EMAIL PROTECTED]
Date: Thu, 17 Apr 2008 07:22:20 -0500
On Wed, Apr 16, 2008 at 11:19:33PM -0400, Bob Rogers wrote:
. . . but IIUC and is not short-circuiting.
and is short-circuiting.
Aha. I was misled by the presence of andthen, and was too sure of
I know how comparisons are chained in Perl 6. There is a very short section on
it in S03.
So, are the operators infix:{''} etc. written in the normal way to take two
arguments? Then the language transforms A op B op C into A op B AND B op C on
an innate level. Does that apply to any
On Apr 16, 2008, at 3:49 , John M. Dlugosz wrote:
Or, are the operators written in a tricky way, to return an object
that encapsulates the original right argument and the proper
boolean result, and has forms to take this object as well? IOW, no
built-in support.
Yes, they use
On Wed, Apr 16, 2008 at 07:49:48AM -, John M. Dlugosz wrote:
I know how comparisons are chained in Perl 6. There is a very
short section on it in S03.
So, are the operators infix:{''} etc. written in the normal
way to take two arguments? Then the language transforms
A op B op C
Patrick R. Michaud pmichaud-at-pobox.com |Perl 6| wrote:
It applies to any operator that has 'chain' associativity --
see S06, Subroutine traits.
If I want to make my own chained operator, perhaps the
curvy #8828;, #8829;, etc. or make my operator #8807;
a synonym for =, how would I tell
On Wed, Apr 16, 2008 at 09:39:52AM -0400, Brandon S. Allbery KF8NH wrote:
On Apr 16, 2008, at 3:49 , John M. Dlugosz wrote:
Or, are the operators written in a tricky way, to return an object that
encapsulates the original right argument and the proper boolean result,
and has forms to take
context is True.
Pardon a lurker, but I'm not sure I understand the point of this. In:
if $x $y $z { ... }
I would expect a sensible compiler short-circuit the $x $y part, and
indeed the Chained comparisons section of S03 (version 135) says
A chain of comparisons short-circuits
Larry Wall larry-at-wall.org |Perl 6| wrote:
Well, that's more or less how Icon does it, but we're not going to expose
anything like that to the user. If we assume that comparisons take two
immutable objects, we can leave it to the compiler to compute the actual
value once, and then feed it to
Suppose I have code that looks like this:
my ($x, $y, $z) = (1, 2, 3);
say sorted backward if ++$x ++$y ++$z;
Will $z be incremented even though the chained comparison is known to be
false after ++$x and ++$y are compared?
Joe Gottman
are compared?
I don't see a reason for chained comparisons not to short-circuit,
besides the surprise factor. But anyone who knows about , and
understands chained comparisons as expanding to , should understand
short-circuiting behavior.
Luke
the chained comparison is known to be
false after ++$x and ++$y are compared?
I don't see a reason for chained comparisons not to short-circuit,
besides the surprise factor. But anyone who knows about , and
understands chained comparisons as expanding to , should understand
short-circuiting
14 matches
Mail list logo
