Aaron Sherman <[EMAIL PROTECTED]> 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 code. > 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 necessary. 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 <[EMAIL PROTECTED]> Perl and Parrot hacker "I used to have a life, but I liked mail-reading so much better."
