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
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 ?
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 ?
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 ?
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 . 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
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 ?
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 ?
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 ?
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 ≼, ≽, etc. or make my operator ≧ 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 assoc is looser(...) { ... } Pm Your answer is the opposite of Brandon's.
Re: Chained Comparisons ?
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 into A op B AND B op C on an innate level. Does > that apply to any user-defined operator with those names? 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 ≼, ≽, etc. or make my operator ≧ > 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 assoc is looser(...) { ... } Pm
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
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 ≼, ≽, etc. or make my operator ≧ 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: 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
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
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