On Tue, Apr 19, 2005 at 01:31:12AM +0800, Autrijus Tang wrote:
: On Sat, Apr 16, 2005 at 12:10:48PM -0700, Larry Wall wrote:
: > I think I have to clarify what I mean by that last phrase.  Trailing
: > delimiters are hidden inside any token that has already been started,
: > but not at the start of a token (where token is taken to be fairly
: > restrictive).  Therefore these are errors:
: > 
: >     qq. $foo.bar() .
: >     qq: @foo::bar[] :
: > 
: > However
: > 
: >     qq/ &foobar( $a / $b ) /
: > 
: > is just fine, since (...) is looking for its own termination.
: 
: Consider this:
: 
:     rx/abc$/
:     qq/abc$/
: 
: After roie's refactoring, both now breaks, whilst in Perl 5, only
: the latter break -- qr/abc$/ is just fine.  Is it something we need
: to special-case for rx?

Certainly.  rx// does not do any kind of interpolation any more.  It is
a language of its own, and $ is just a token in that language.  On the
other hand, like Perl 5, that language does have variables in addition
to $, so we still have to distinguish whether the character after the $
indicates a variable.  Perl 5's rule was that $ meant "end-of-whatever"
if it was followed by ), | or the end of the interpolated string.
(Or by # or whitespace in /x mode.)  Otherwise it's a variable.
Since we're parsing left-to-right, we can't do exactly the same, but
I suspect we can check after the $ for ), ], |, #, whitespace, or the
terminator, which rules out direct use of $/ inside /.../.  That's not
a great hardship, since we have the $1 and $<foo> shortcuts for
backrefs, and anything fancier probably wants to be in {...} anyway.

As for qq/abc$/, I think it's okay for that to notice that you're trying
to interpolate a variable that has the same name as the delimiter, and
blow up immediately.  While we could let people interpolate such
variables by default, it's probably better to stop and make people
clarify what the mean in that case.  There aren't that many puncuational
variables any more.  Certainly we don't have $' and $" anymore, which
would be the usual ambiguous cases for normal quotes.

And yes, this is pretty much the opposite of what I said about

    " @foo.bar.baz[] "

But in either case we're just trying to figure out what the user expects.
Or doesn't expect, in the case of qq/abc$/.

Larry

Reply via email to