develooper Front page | perl.perl6.language | Postings from March 2005

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

Thread Previous | Thread Next
Brent 'Dax' Royal-Gordon
March 17, 2005 14:08
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Message ID:
Aaron Sherman <> wrote:
> > Specifically, I like the use of angle brackets in Pod.  Angle brackets
> > are simple, distinctive shapes; they remain wide in variable-width
> This is aesthetic preference. I could cite the reasons that I have an
> aesthetic preference for the other syntax, but the reality is that angle
> brackets aren't angle brackets; they are less-than (E<lt>) and greater-
> than signs (E<gt>). We ignore this fact at our peril, 

Only in name.  Years of HTML and Perl have trained me to treat these
as bracketing constructs, and Perl 6 is set to increase that use.

> and the hacks in
> pod syntax (e.g. C<< < >>) to get around this are glaring anti-
> huffmanisms.

Whatever bracketing character we decide to use, there will always be
occasions where we need to use it in an unbalanced way within a
formatting code.  (Though I do admit that angle brackets are more
likely to be unbalanced than other characters.)

The problem I have with square brackets specifically is that they get
lost really easily, especially in variable-width fonts.  Gmail, for
example, displays e-mail in a sans-serif font, and virtually all such
fonts have narrow square brackets.  The square brackets in your
examples were visually lost in the surrounding text--without spaces,
square brackets are invisible.  That's okay when you're subscripting,
because your brain doesn't really need them to understand what's going
on, but it's not when you're applying and reading formatting codes.

Further, although Perl 6 is the time to make such a change, I'm not
convinced the change is really necessary.  We might be able to avoid a
few uses of C<< >>, but is that a big enough win to change *yet
another* aspect of Perl?  Especially an aspect programmers can--and
traditionally did--ignore?

> > The most common use of them in Perl 5--method call/dereference--is
> > going away in Perl 6
> Hmm, I remain unconvinced of that as the most common use, especially
> with the copious use of =>. Still, in my local source tree you're right,
> though by < a factor of 2.

Are you looking at your entire source tree, or just the Pod in it? 
The code in Pod--and especially the short snippets of code typically
included in a C<> construct--is very different from arbitrary Perl

> Perl 6 also adds new uses of E<gt> and E<lt> for pipelining, and further
> expands the usefulness of the => operator as a pair constructor. Rules
> also add new uses of these characters, but those are balanced, so
> improving POD with a real grammar specification would solve for that.

I definitely support intelligently defining the way Pod handles angle
brackets which aren't part of a formatting code.  I also think writing
a reference grammar would be an excellent idea.

> Thanks Brent, I'm not sure if you intended your mail as an endorsement,
> but other than one sticking point, you and I appear to be on the same
> page. Thank you for your message.

I intended my e-mail to be an endorsement of Pod as it exists, with
extensions rather than a redesign.  I think you have mostly the right
idea, but I really don't think switching to square brackets is

By the way, I think I've seen a few people suggest some sort of
syntax-switching mechanism for "Pod6".  The day people have to think
about what dialect of Pod they're using is the day Pod dies as a
useful documentation language.

Brent 'Dax' Royal-Gordon <>
Perl and Parrot hacker

"I used to have a life, but I liked mail-reading so much better."

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About