On Mon, Jan 24, 2000 at 10:51:28PM -0600, Brad Appleton wrote:
> On Mon, Jan 24, 2000 at 11:28:52PM -0500, Ronald J Kimball wrote:
> > Ah, so the problem is a choice between C<@-Z<>> and C<$a-E<gt>[0]>, neither
> > of which is particularly readable.
>
> So why not come up with a patch to the regular expression in Pod::Parser
> so that neither one is required?
I'm concerned that someone may find another exception, and then another,
and then another, and soon POD parsing becomes extremely complicated.
> I'm the first one to say how much I dislike having that code inside
> Pod::Parser to hack things up to allow -> and => in certain cases. I'm
> also the first one to admit the overwhelmingly vast majority of p5p
> was pretty insistent upon it at the time - which is why I coded it up
> anyway, even though my own preference and instincts went against it.
I can understand the desire, perhaps even the need, for it.
C<$ref-E<gt>[0]> is hard to read.
> > Code sections (and others, if desired) may begin with one or more
> > consecutive left angle brackets, and are terminated by the same number of
> > consecutive right angle brackets. Within the code section, any lesser
> > number of consecutive angle brackets is ignored (unless, of course, they're
> > part of a nested section). Other than at the beginning and end of a
> > section, angles would _not_ nest.
>
> Zoinks - I don't care for that at all. I think it is far more limiting and
> restrictive than is necessary. Why not just try to be more precise about
> the circumstances under which '>' does NOT terminate a C<...>. Maybe
> 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. As a start, the
characters that would have to be allowed before -> and => would include
[\w '\]}]. Of course, -> can follow any variable name, so these would both
be legal code -- $x->[0] , $@->[0] -- but only one could put in a C<>
block as is. (Note that the second case may be quite common with exception
objects.)
> Thats a heckuva lot more accommodating and less restrictive than
> forbidding most forms of nesting (something which I'm not willing to do
> because Pod::Parser gets used for lots more stuff than just translation
> and removing the nesting will break lots of code that I personally have
> a stake in).
I'm not sure what you mean by "removing the nesting"... Is C<a<b>c> an
entire code section, including c>? If that's the case, there's no reason
to change it. I was under the impression that bare angle brackets did not
nest, which is why I stated it that way. My mistake.
In that case, under my proposal, C<<a<b>> would be an unterminated code
block.
Actually, I think the subtlest problem to my proposal is that someone might
try to represent the comparison operator as C<<=>>, which would actually be
the assignment operator. Hmm.
Ronald
