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.
Thanks! 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 so. 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
