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

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

[CC'ed to pod-people -- doc patch changed C<@-> to C<@-Z<>> to avoid
Unterminated C<...> errors.]

On Mon, Jan 24, 2000 at 03:04:16PM -0500, Ilya Zakharevich wrote:
> Ronald J Kimball writes:
> > > 	** Unterminated C<...> at .../pod/perlvar.pod line 188
> > > 	** Unterminated C<...> at .../pod/perlvar.pod line 188
> > > 	** Unterminated C<...> at .../pod/perlvar.pod line 424
> > > 
> > > This is due to C<@-> and the like.
> > > 
> > > Patch below
> > 
> > Why can't the POD parser be fixed, rather than hacking the POD?  POD is
> > supposed to be readable; C<@-Z<>> and C<$#-Z<>> are not readable.
> 
> This is another indication that the idea of allowing -> and => inside
> a group is a broken idea.
> 

Ah, so the problem is a choice between C<@-Z<>> and C<$a-E<gt>[0]>, neither
of which is particularly readable.

I propose a third solution, which I think preserves the simplicity and
readability of POD.

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.

The above two examples would become:

C<@->
C<<$a->[0]>>

And other examples:

C<<{ key => 'value' }>>
C<<<$b >> 4>>>


However, this would be a problem for a code section such as C<<>.  In that
situation C<E<lt>> would then be necessary.  (Also, C<E<gt>> would still be
necessary, as before.)  So this solution is not perfect either.  But I'll
put it out for consideration.


Ronald

---

References to:

Ronald J Kimball <rjk@linguist.dartmouth.edu>
Ilya Zakharevich <ilya@math.ohio-state.edu>

---

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

---