Re: [p5pod] [ID 20000124.002] Unterminated C<...> at perlvar.pod line 188

[Ronald J Kimball <rjk@linguist.dartmouth.edu>]

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

---

Follow-Ups from:

Larry Wall <larry@wall.org>

References to:

Ronald J Kimball <rjk@linguist.dartmouth.edu>
Ilya Zakharevich <ilya@math.ohio-state.edu>
Brad Appleton <bradapp@enteract.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---