On Mon, Sep 09, 2002 at 03:52:30PM +0200, Damian Conway wrote:
> Hi Scott,
>
> You asked (off-list):
Oops, that should've been on-list so that everyone can benefit from my
ignorance :-)
> > Then how do I tell ^^ and $$ to only match just after and just before
> > my platform specific newline sequence? ^^ and $$ seem less useful if
> > I can't do that. (Maybe it's just an erroneous assumption on my part
> > but \n, ^^, and $$ all seem intimately related)
>
> Only in that they use the same set of values when looking for a line
> terminator. You could consider ^^ and $$ to be abbreviations of:
>
> <after <nl>|^>
> <before <nl>|$>
>
> where <nl> matches any newline sequence.
>
> So if you wanted a platform-dependent version, you'd write:
>
> rule <sol> { <after \c[CR]|^> }
> rule <eol> { <before \c[CR]|$> }
>
> and use those.
Okay, that makes sense. Or, presumably, I could lexically redefine ^^
and $$ just like I can any other operator.
> > Then, I'll ask again, why are we storing the sigil in the match object
> > for explicit hypotheticals? The difference between
> >
> > $0{file}{hunk}[2] # and
> > $0{file}{'@adonises'}[2]
> >
> > seems unnecessary. Or, how is
> >
> > rule file { ^ @adonises := <hunk>* $ }
> >
> > different from
> >
> > rule adonises { <hunk> }
> > rule file { ^ <adonises>* $ }
> >
> > aside from the extra indirection?
>
> Yes, they're different. Explicitly binding to @adonises binds the (dereferenced)
> reference to the array of C<hunk> match objects. The implicit binding
> of C<< <adonises>* >> binds the (un-dereferenced) reference to the array
> of match objects.
>
> That is:
>
> rule file { ^ <adonises>* $ }
>
> is like:
>
> rule file { ^ $adonises:=<adonises>* $ }
Aha! Thanks. Can you pop back in time real quick and add these
comments to E5? :)
But it still doesn't make sense to me that we are storing the sigils.
I mean, I thought the whole point of things like:
$aref = @array;
$aref[2] = 5;
was so that we wouldn't have to know or care about the type of thing
we're dealing with and that Perl would just Do The Right Thing. It
seems that by storing the sigils in the match object, we're back to
partitioning rather than unifying.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
