On Sun, Jun 24, 2001 at 11:14:25PM -0300, Rogério Brito wrote:
> On Jun 24 2001, Michael Fowler wrote:
> > On Sun, Jun 24, 2001 at 07:13:47PM -0300, Rogério Brito wrote:
> > > $n = () = m/string/g;
> > >
> > > In particular, is "()" an lvalue in Perl?
> >
> > Yes, it is. () is a list assignment with no values.
>
> I'm now a little bit confused. You meant "() is IN a list
> assignment...", right (since it would provide the list context
> to the assignment, =, operator)? Or did you mean that () IS
> indeed an assignment?
No, as in () IS indeed an assignment. A list assignment is:
($foo, $bar) = ("foo", "bar");
i.e. the LHS of the assignment is a list. In this case, it's something
like:
$n = (@matches) = m//g;
Except there's no temporary array, @matches. The list assignment does
indeed provide the list context to the m//g.
> I'm a bit lost here, since I would have thought that () would
> be a literal/constant empty list, like, say "" is the empty
> literal string in C.
Normally it would be, except in this case it's on the left hand side of an
assignment expresion, so it becomes a list assignment.
> To make matters worse, I thought that since (1, 2, 3) is a
> literal, non-empty list, that () would be the similar,
> constant empty string. It was my surprise that the snippet
> above indeed worked -- I guess I'm not enough familiar with
> the semantics of the language. :-(
There is nothing to be constant in (), since there are no values. If you
had tried to assign to constant values you would, of course, encounter
errors.
> But if () is an lvalue in perl, where are its contents stored?
I can't be certain where the contents of an empty list assignment are
stored; running the snippet through perl -Dx (which gives a syntax dump)
leads me to believe the operation is optimized to only count the elements.
> > This behaviour of m//g, not matching overlaps, is desirable and correct.
>
> It may be desired, but I'm not so sure that it is "correct".
> I'm not even sure that there is only one value of correct,
> since I can count at least two such values. :-)
Then let me clarify my statement: correct for most situations in which this
operator is used.
> > m//g is usually used for parsing, not counting occurrences, and parsing out
> > overlaps as individual tokens would be a Very Bad Thing.
>
> Well, the perlop manpage should be changed then. :-(
Possibly, though this is the only time I've seen the issue come up. Also,
to me, whether or not there is one or two 'ana' sequences in 'banana' is
debateable.
> P.S.: On page 71, it says "The /g modifier specifies global pattern
> matching---that is, matching as many times as possible within a
> string". Perhaps both semantics could be provided by Perl in a future
> version? If not possible, giving a warning would be fine.
Matching overlaps can be done without the need for a new modifier on regex
operations, and it's probably better done that way. The need for the
feature, as far as I can tell, is infrequent enough that it really doesn't
need to be a feature of the language.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
