On Tue, Jan 25, 2000 at 08:22:01AM -0600, Brad Appleton wrote:
> On Tue, Jan 25, 2000 at 12:03:51AM -0500, Ronald J Kimball wrote:
> > I'm concerned that someone may find another exception, and then another,
> > and then another, and soon POD parsing becomes extremely complicated.
>
> Too late - thats already the case with special-handling -> and =>
> inside of C<...>. It won't get significantly more or less complicated
> by limiting what can appear to the left of [-=]>. In fact its more likely
> to make the code less complicated.
The code may become less complicated, but the parsing rules may become more
complicated, which would make writing more complicated. The POD author
would have to remember when -> and => end the block and when they don't,
depending on the characters which appear before.
> > > its not enough to simply be '->' or '=>', perhaps we only want to allow
> > > certain classes of characters to be to the left of '->' and '=>' and
> > > maybe only a select few punctuation characters are in that set.
> >
> > This has the drawback of trading simplicity for readibility. I think it
> > would create too many special cases to remember.
>
> Unlike the dozen or so special cases we already have where we want
> to allow -> and => but not ==> --> !=> /=> and <<op>>= in general.
> Perhaps you're not fully aware of the existing special cases. The
> regexp in the code looks something like:
>
> qr/(?:[^-+*/=!&|%^x.<>$]+=|[^-$]+-)$/;
>
> If anything I bet the above proposal would decrease the amount of special
> cases rather than increase it.
>
How would you allow both C<@-> and C<$@->[0]> while decreasing the number of
special cases?
I think I'm starting the favor the original proposal of C<@-Z<>>. :D
Ronald
