Re: [svn:perl6-synopsis] r14447 - doc/trunk/design/syn
So 'orelse' is exactly like '//', except that the result of the left side gets passed to the right side as an error message. Is there a reason to make this exception, as opposed to altering '//' to behave exactly like 'orelse' does? -- Jonathan Dataweaver Lang
Re: [svn:perl6-synopsis] r14447 - doc/trunk/design/syn
On Thu, Sep 06, 2007 at 01:40:20PM -0700, Jonathan Lang wrote: : So 'orelse' is exactly like '//', except that the result of the left : side gets passed to the right side as an error message. Is there a : reason to make this exception, as opposed to altering '//' to behave : exactly like 'orelse' does? How 'bout, it's convenient to have the simpler defaulting semantics when you don't care what kind of undefined value is on the left. Larry
Re: [svn:perl6-synopsis] r14447 - doc/trunk/design/syn
[EMAIL PROTECTED] wrote:
Author: larry
Date: Thu Sep 6 09:31:16 2007
New Revision: 14447
+
+C infix:andthen , proceed on success
+
+test1() andthen test2()
+
+Returns the left argument if the left argument indicates failure
+(that is, if the result is undefined). Otherwise it
+evaluates and returns the right argument.
+
+If the right side is a block or pointy block, the result of the left
+side is bound to any arguments of the block. If the right side is
+not a block, a block scope is assumed around the right side, and the
+result of the left side is implicitly bound to C$_ for the scope
+of the right side. That is,
+
+test1() andthen test2()
+
+is equivalent to
+
+test1() andthen - $_ { test2() }
+
+There is no corresponding high-precedence version.
+
=back
+C infix:orelse , proceed on failure
-$value err $default
+test1() orelse test2()
-Returns the left argument if it's defined, otherwise evaluates and
-returns the right argument. In list context forces a false return
-to mean C(). See C// above for high-precedence version.
+Returns the left argument if the left argument indicates success
+(that is, if the result is defined). Otherwise it evaluates and
+returns the right argument.
+
+If the right side is a block or pointy block, the result of the left
+side is bound to any arguments of the block. If the right side is
+not a block, a block scope is assumed around the right side, and the
+result of the left side is implicitly bound to C$! for the scope
+of the right side. That is,
+
+test1() orelse test2()
+
+is equivalent to
+
+test1() orelse - $! { test2() }
+
+(The low-precedence C// operator is similar, but does not set C$! or
+treat blocks specially.)
=back
Do the results of andthen and orelse really bind to ANY arguments of
the second block? If the second block has two parameters it makes more
sense to me for the results to bind to the first parameter and nothing
to bind to the second parameter.
Joe Gottman
Re: [svn:perl6-synopsis] r14447 - doc/trunk/design/syn
Larry Wall wrote: Jonathan Lang wrote: : So 'orelse' is exactly like '//', except that the result of the left : side gets passed to the right side as an error message. Is there a : reason to make this exception, as opposed to altering '//' to behave : exactly like 'orelse' does? How 'bout, it's convenient to have the simpler defaulting semantics when you don't care what kind of undefined value is on the left. If you don't care what kind of undefined value is on the left, you probably won't notice if it's passed to the right; and the optimizer may very well end up implementing the simpler semantics in this case, even if you use 'orelse'. And if you explicitly want to use the simpler semantics, you can come very close by blocking the right side in a block that takes no arguments. Conversely: if you do care about the undefined value, the subtle distinction between '//' and 'orelse' (beyond the implied difference in precedence) will be yet another language quirk that you'll have to remember. Very inconvenient. -- Jonathan Dataweaver Lang
Re: [svn:perl6-synopsis] r14447 - doc/trunk/design/syn
On Thu, Sep 06, 2007 at 08:32:55PM -0400, Joe Gottman wrote: : Do the results of andthen and orelse really bind to ANY arguments of : the second block? If the second block has two parameters it makes more : sense to me for the results to bind to the first parameter and nothing : to bind to the second parameter. I suspect the left side is a Capture context, so test1() could return multiple arguments to be bound to the right side. In any case, if test1() calls fail() then the orelse should fail regardless of whether the orelse is in list or scalar context. Should probably make the orelse itself fail if the binding doesn't work too. Larry
