Mark wrote:
: What about
:
: =comment explain
: The devil made me write this code
:
: =comment future
: Add a :devil option
:
: =comment design
: See www.dev.il/design/S25.pod
:
: =comment etc. etc.
: >:-)
In Perl 6 Pod, those are exactly equivalent to:
=begin comment
explain
The devil made me write this code
=end comment
=begin comment
future
Add a :devil option
=end comment
=begin comment
design
See www.dev.il/design/S25.pod
=end comment
=begin comment
etc. etc.
>:-)
=end comment
So...yes, you certainly *can* have them. ;-)
Then Larry wrote:
Hmm, for single paragraphs, we can huffmanize it further:
=for explain
The devil made me write this code
=for future
Add a :devil option
=for design
See www.dev.il/design/S25.pod
=for etc. etc.
>:-)
Yes. C<=for whatever> is the intermediate form between the abbreviated
C<=whatever> and the explicitly delimited C<=begin whatever/=end whatever>.
So Larry's examples above are exactly equivalent to:
=begin explain
The devil made me write this code
=end explain
=begin future
Add a :devil option
=end future
=begin design
See www.dev.il/design/S25.pod
=end design
=begin etc.
etc.
>:-)
=end etc.
which a pod processor would treat as "external" (i.e. unknown) blocks..at
least, until the Pod specification was extended to make those standard types.
Of course, lowercase block typenames are reserved for future standard blocks,
so it would be totally future-proof to write:
=for Explain
The devil made me write this code
=for Future
Add a :devil option
=for Design
See www.dev.il/design/S25.pod
=for Etc. etc.
>:-)
We're trying our best to get rid of =cut, which is why =end returns
to the parser state the =begin entered from.
Indeed. As does a C<=for> after the first blank line. And, indeed, a
C<=whatever> after the first blank line.
In Perl 6 Pod, C<=cut> is only ever required if you're inside an extended Pod
region (which you initiated with a C<=pod> directive).
: Much cleaner, and I don't like Pascal.
You have to admit it helps it to stand out from the non-Pascal
code though...
Yep. And besides: "There's more than one way to document it". ;-)
All that being said, the final syntax hasn't been nailed down yet,
there are certainly differences of opinion among the designers that
you might successfully drive a wedge into. :-)
But *please* give us a week or two for Ingy and I to release our proposal and
for %Larry{none 'Damian'} to drive nails into it first. ;-)
But the most important thing we're going to introduce is
=use MyPodQuirks
so that syntactic and semantic differences are actually documented
somewhere rather than being implicit in the Postprocessor of the Day.
[Damian scurries off to update S26 to "make it so"...]
