Front page | perl.perl5.porters |
Postings from March 2001
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.
Abigail
Thread Previous
|
Thread Next