On Sun, Aug 16, 2009 at 3:26 PM, Damian Conway<dam...@conway.org> wrote:
> It's Sunday evening and, as promised, here's the new draft of S26.


After an initial read thru the summary and spec my overall reaction to
the new pod is "whirled peas!". :)

> * Hence it must always parsed using full Perl 6 grammar: perl6 -doc

Couldn't the pod processing be encapsulated, perhaps in PGE/NQP, so
that it could be reused in a different Parrot language, provided that
said language supports declarators and comments, or even just comments
(if one downgrades the impact of encountering an "attached" comment
that has no declarator to a warning). The latter would fully restore
the generic applicability of the POD 5 parser, right?

> Hopefully this is something close to the final draft...and something that 
> every
> stakeholder and faction in this long discussion can dislike equally. ;-)

While I like the design, and I think it's near enough complete, and I
think a reader who knows perl and pod well could understand your
current description of that design, I think it could do with a major
rewrite to make it less confusing to work out what you really mean as
against what's currently written. ;) However, I think it's too early
to attempt such a rewrite, or even to comment on specific problems; I
plan to wait another couple weeks for some list back-and-forth before
commenting further about clarity and/or proposing edits and/or
providing patches.

The two design questions/comments I have for now are:

You don't say whether attached pod allows for configuration info or
formatting codes. I'm guessing your intent is no on both accounts.
However, presumably the pod parser could process config at the start
of attached pod and attach just the text after the config to the .WHY.
(Incidentally, .WHY seems a bit too cute; what about .DOC or .POD?
Same with .WHEREFORE; my boring suggestion is .CODE.) And formatting
codes could presumably be interpreted by renderers that chose to do

Declarator aliases, as specced, seem to me the weakest part of the
design. Declarator aliases seem to only allow one my, one has, etc. in
a given context. Having to use non-attached pod syntax to do an
attached thing seems very weird. Having to use aliases at all to refer
to things that the Perl 6 compiler already has a name for seems like
an ugly/heavyweight/suboptimal approach.

Anyhoo, thanks for the time spent and great design skills that are so
evident in this new spec. :)

love, raiph

Reply via email to