Re: comment scope
* Damian Conway ([EMAIL PROTECTED]) [060315 01:52]: > That's why the general Perl 6 Pod syntax allows any block construct to be > labelled: > > =begin comment (explanation) > The devil made me write this code > =end comment > > =begin comment (future implementation) > Add a :devil option > =end comment > > =begin comment (design) > See www.dev.il/design/S25.pod > =end comment > > =begin comment (etc. etc.) > >:-) > =end comment But are we still applying huffman encoding here? I mean: do we really write that little comments that long constructs are acceptable? 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. >:-) =cut Much cleaner, and I don't like Pascal. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: comment scope
On Wed, Mar 15, 2006 at 04:42:53PM +0100, Mark Overmeer wrote: : * Damian Conway ([EMAIL PROTECTED]) [060315 01:52]: : > That's why the general Perl 6 Pod syntax allows any block construct to be : > labelled: : > : > =begin comment (explanation) : > The devil made me write this code : > =end comment : > : > =begin comment (future implementation) : > Add a :devil option : > =end comment : > : > =begin comment (design) : > See www.dev.il/design/S25.pod : > =end comment : > : > =begin comment (etc. etc.) : > >:-) : > =end comment : : But are we still applying huffman encoding here? I mean: do we really : write that little comments that long constructs are acceptable? : : 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. : >:-) : =cut 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. >:-) But of course that doesn't work if those are supposed to be =head-like in front of bare paragraphs. In which case the whole thing needs to be wrapped in =begin/=end and then you really do use =head (or whatever heading syntax we end up with). =cut We're trying our best to get rid of =cut, which is why =end returns to the parser state the =begin entered from. If you put =begin into code, the =end leaves back into code (unlike in Perl 5). =cut was a bad mistake on my part, and I'd like to forget my mistakes. : Much cleaner, and I don't like Pascal. You have to admit it helps it to stand out from the non-Pascal code though... 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 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. So it'll be easy to drive a cultural wedge between yourself and the rest of humanity, as long as you describe it to the anthropologists... That goes for Perl 6 in general too. Larry
Re: comment scope
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"...]
