On Mon, Mar 19, 2001 at 09:30:06PM +0000, nick@ing-simmons.net wrote: > Chris Stith <mischief@velma.motion.net> writes: > >That is so if the examples are taken exactly as is. It is not so if > >the example is put in the context of code following it. From which > >match operator would the next line pull `$1'? > > > >Nick is talking about a body of code expecting something to be a > >certain way when the code example above is executed. > > No I am not. (The example code is not mine and not a good example. > It has && in it, is calling a builtin as a pseudo-sub and ...) > > I am talking about code that uses $1 in general, and with at least > a basic grasp of how the op tree is built. And with a background > in devious "lexing" schemes. > > Without a lot of flow analysis (that perl does not do) perl cannot tell > that a particular use of $1 is (always) used in a way that means it should > take a copy, or a way which means it should leave it "lazy". > > So my stance is that $1 is lazy, if you want/need a copy then write "$1". The problem isn't $1. $1 is just a figurant in this drama, and its role could be played by any other variable. The lead role is &&. The example might be bad, but if you think that's caused by &&, you are missing the point. It's && that returns aliases, instead of the expected values. Here's another example that shows the problem lies with &&: print +(($x = 2) && $x) + (($x = 3) && $x); That will print `6', not `5'. Or is "$x" lazy as well? As for "$1 is lazy", I say Eh? The word `lazy' turns up a whopping four times in the 5.6.0 pods, and none of them in the meaning you are using. Lazy evaluation has a well defined meaning, but it belongs in the class of functional languages, where order of evaluation is not important. In the class of imperative languages, lazy evaluation doesn't make sense, as the side-effects, and the order in which they happen are vital to write programs. AbigailThread Previous | Thread Next