[perl #132206] Compiler error on WhateverCode and chained comparisons
# New Ticket Created by Brandon Allbery
# Please include the string: [perl #132206]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132206 >
[03 05:10:36] m: subset MyStr of Str where 4 < *.chars <
10; my MyStr $s = 's';
[03 05:10:37] rakudo-moar fcbd8a: OUTPUT: «===SORRY!===
[03 05:10:37] QAST::Block with cuid 1 has not appeared
[03 05:10:37] »
[03 05:11:12] what's happening here, how can I set that
constraint?
[03 05:15:05] the error message is a bit cryptic
[03 05:15:14] it's an internal error that shouldn't happen
(...)
[03 05:19:42] m: my = 4 < *.chars < 10; say ("s")
[03 05:19:43] rakudo-moar fcbd8a: OUTPUT: «===SORRY!===
[03 05:19:43] QAST::Block with cuid 1 has not appeared
[03 05:19:43] »
[03 05:19:58] looks like WhateverCode parsing doesn't mix well
with chained comparisons
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: Chained Comparisons ?
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 can see some merits in that. Is chained associativity specific to this (functions return Bool and are ANDed pairwise), or can it be used for other things like ganging $a+$b+$c+$d to a single +(*$L,*$R,Vector [EMAIL PROTECTED]) function that doesn't keep re-allocating and copying memory but does it all in one shot? 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 like to define + and * to be listfix and commutative, that is independent of order. Note that this is orthogonal to the definition of evaluation order. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Re: Chained Comparisons ?
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) says
A chain of comparisons short-circuits if the first comparison
fails . . .
But the definition of chaining associativity under Operator precedence
says this is equivalent to:
if ($x $y) and ($y $z) { ... }
(modulo multiple evaluation), but IIUC and is not short-circuiting.
and is short-circuiting.
And wouldn't it also be helpful to implement chaining in such a way
that a specialized chained op implementation couldn't mess it up by
returning plain True?
FWIW, PCT and Rakudo do it this way -- the chained op returns a true/false
value and doesn't have to be aware of any chaining taking place.
Pm
Re: Chained Comparisons ?
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 like to define + and * to be listfix and commutative, that is independent of order. Note that this is orthogonal to the definition of evaluation order. Regards, TSa. Because the function is specific for adding a bunch of Vectors, and needs at least two.
Re: Chained Comparisons ?
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 my interpretation to look them up. Thanks, and sorry for the noise. -- Bob
Chained Comparisons ?
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 user-defined operator with those
names? 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
the compiler that they belong to the same set of chained operators?
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.
--John
Re: Chained Comparisons ?
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 multiple-typed values such that (3 5) returns (5 but
True), which used in a numeric context is a 5 that can be chained
with further infix:{''}s but in a boolean context is True.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
Re: Chained Comparisons ?
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 the compiler that they
belong to the same set of chained operators?
sub infix:«≽» ($a, $b) is equiv(infix:«=») { ... }
Or, if you want to create your own chained precedence level
separate from the existing relational ops,
sub infix:«≽» ($a, $b) is assocchain is looser(...) { ... }
Pm
Your answer is the opposite of Brandon's.
Re: Chained Comparisons ?
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 this object as well? IOW, no built-in support.
Yes, they use multiple-typed values such that (3 5) returns (5 but True),
which used in a numeric context is a 5 that can be chained with further
infix:{''}s but in a boolean context is True.
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 both sides of the implicit AND. The
user just writes an ordinary binary comparison that returns a boolean.
For several years now I've been treating any use of but as a code
smell, and changing the design so it isn't necessary. It's been a
rather useful construct that way, like eval and BEGIN. :)
Larry
Re: Chained Comparisons ?
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 this object as well? IOW, no built-in
support.
Yes, they use multiple-typed values such that (3 5) returns (5 but
True), which used in a numeric context is a 5 that can be chained with
further infix:{''}s but in a boolean context is True.
So does (5 3) return (3 but False) or just False ?
Joe Gottman
Re: Chained Comparisons ?
From: Brandon S. Allbery KF8NH [EMAIL PROTECTED]
Date: Wed, 16 Apr 2008 09:39:52 -0400
. . .
Yes, they use multiple-typed values such that (3 5) returns (5 but
True), which used in a numeric context is a 5 that can be chained
with further infix:{''}s but in a boolean 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 if the first comparison
fails . . .
But the definition of chaining associativity under Operator precedence
says this is equivalent to:
if ($x $y) and ($y $z) { ... }
(modulo multiple evaluation), but IIUC and is not short-circuiting.
Which is intended? I am hoping the Operator precedence definition
should be andthen; I would find non-short-circuiting behavior rather
surprising.
Assuming that the intent is for short-circuiting, the compiler
*can't* in general produce code that invokes subsequent chained ops, as
that would require evaluating subsequent arguments. So when would these
Num but True values ever be needed?
And wouldn't it also be helpful to implement chaining in such a way
that a specialized chained op implementation couldn't mess it up by
returning plain True?
My apologies if this is spelled out somewhere; I couldn't find
anything about this application of multiple-typing in S03.
-- Bob Rogers
http://rgrjr.dyndns.org/
Re: Chained Comparisons ?
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 both sides of the implicit AND. The
user just writes an ordinary binary comparison that returns a boolean.
For several years now I've been treating any use of but as a code
smell, and changing the design so it isn't necessary. It's been a
rather useful construct that way, like eval and BEGIN. :)
Thanks for the clarification, Larry.
* hidden from the user (no funny return values, no funny way to write
the function)
* argument only evaluated once
Any strong feeling about order-of-evaluation issues?
I assume this extends to any user-written infix:{''} since we're not
supposed to reuse existing operators for different purposes, but only to
extend the domain of the same meaning.
So how about making a new operator or set of operators that will have
the same behavior? I don't like compiler magic that is not available
for reuse g.
Is chained associativity specific to this (functions return Bool and
are ANDed pairwise), or can it be used for other things like ganging
$a+$b+$c+$d to a single +(*$L,*$R,Vector [EMAIL PROTECTED]) function that doesn't
keep re-allocating and copying memory but does it all in one shot?
--John
Do chained comparisons short-circuit?
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
Re: Do chained comparisons short-circuit?
On 1/19/06, Joe Gottman [EMAIL PROTECTED] wrote: 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? 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
Re: Do chained comparisons short-circuit?
On Thursday 19 January 2006 04:25, Luke Palmer wrote: On 1/19/06, Joe Gottman [EMAIL PROTECTED] wrote: 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? 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. Although that may lead to _longer_ code, which (when extended) is likely to be broken: $x++; $y++; $z++; say sorted backward if $x $y $z; To be honest, in this example it mostly doesn't matter; if $x $y, then ($x+1) ($y+1). But in many quickly written scripts I did some numeric operation to force the value to numeric, even if I got a parameter like string (which becomes 0 when numyfied) How about some flag saying don't short-circuit this? Regards, Phil
