On Mon, 19 Mar 2001 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. if( underlined_section_is_flame ) { Thank you for assuming that because I'm not as intimately familiar with perl or with your own explanation of this issue as are you that I have no familiarity with lexing or parsing. } The thread, as quoted by Abigail, read to me as if you meant that an existing body of code expected one or the other match on a single line to become `$1'. I realized it was not your example, but the context in which I was reading I understood to be proper context for what you said. I must have misunderstood what point Abigail was trying to make. > 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". That's something on which I am not prepared to comment, given that I haven't studied that section of the interpreter thoroughly enough. The only thing I will say is that if there's a way to do either the programmer wishes, which you seem to say there is, then that should be a definite plus compared to forcing `$1' itself one way or the other. If `$1' is lazy now and can be forced to be a copy when wanted, then that makes for the best flexibility. > >A line of > >code following the above example shouldn't expect one or the other > >expression to be either `first' or `last', let alone expect which one > >will be the value of `$1'. > > Things get less clear when you have something like: > > some_sub( (s/(0x([a-f0-9]+))/another_sub($1)/ie || s/(\d+)/third($1)/e) ? $1 : ... ); > > In such cases "lazy" is what _I_ want for that last one at least and only > by a lot of looking do you know which that is. I notice you underline `I'. That's a good habit in a discussion such as this. ;-) Chris StithThread Previous | Thread Next