Raiph commented:
> 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?
While I'm all in favour of other languages using Pod as a documentation format,
I think that's unlikely. Pod says that anything of the form:
=identfiier
*anywhere* as the first non-whitespace of a line, is considered a Pod directive.
I can't see many other language designers being willing to limit their
assignment
statements that way.
> 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.
I agree that a rewrite would certainly help it. And will be happy to
kibitz anyone
who volunteers to do so! ;-) Or, of course, to accept patches.
> You don't say whether attached pod allows for configuration info or
> formatting codes.
It does. I don't say it doesn't, and I do show attached comments with it
(e.g. the $chainsaw example). I'll make it explicit however.
> (Incidentally, .WHY seems a bit too cute; what about .DOC or .POD?
> Same with .WHEREFORE; my boring suggestion is .CODE.)
I think you're going to have to take that up with Larry. Presumably the WHO,
HOW, WHERE, WHENCE, etc. should go too? Personally (and I say this as
the guy who pioneered "you think that's cute now..." ;-) I think the
interrogatives
work very well, especially because they stay so well out of the way of anything
a sane person (pace Larry) would use to name an ordinary method.
> 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.
We could certainly consider allowing a fourth form of alias like so:
=alias IDENTIFIER
DECLARATOR
which would use the specified identifier as the alias's name, rather
than the declarator. Lets see what other people think.
> Having to use non-attached pod syntax to do an
> attached thing seems very weird.
I think they have to be different, because they do opposite things...or
at least things in opposite directions. A declarator block says "this
Pod belongs to this code"; an alias says "this code can be referred to
in subsequent Pod". I'd be happy to be proved wrong if someone can
come up with a better mechanism than aliases that still allows
us to pull code into Pod.
> 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.
I think aliases are essential. We need a way of referring to ambient code
within Pod, without the Podder having to write more code to get it.
Damian
