comment scope
Ruud H.G. van Tol
Has that been discussed before?
Maybe like:
#<<#EOC
# a comment line
# another comment line
<code>
#EOC
Or like:
#{#
# first comment line
# next comment line
<code>
# last comment line
#}#
Or POD-ish.
--
Groet, Ruud
David Green
On 3/14/06, Ruud H.G. van Tol wrote:
>Perl6 could introduce (lexical, nestable) comment scope.
>Has that been discussed before?
I think someone might have mentioned it once. Officially you can use
# or make arbitrary POD sections.
But I'd like to make a new push for extra comment characters, not
because I care about multi-line comments or anything per se, but
because I want to be able to draw pretty boxes around my comments
using characters like \u250F, and since the only reason for doing
that is aesthetic elegance, it would kind of spoil it to have to put
a "use Comments::Boxchars" line first.
#==============#
# -David Green #
#==============#
Ruud H.G. van Tol
> Ruud H.G. van Tol:
>>Perl6 could introduce (lexical, nestable) comment scope.
>>Has that been discussed before?
>
> I think someone might have mentioned it once. Officially you can use
> # or make arbitrary POD sections.
I don't think that covers what I mean. It was thinking about overlapping
scopes of code and comments, under strict with the requirement that the start
and end of the comment scope must be at the same code scope level.
Dumb example follows:
#{# Process the whole file.
while (<>) {
#{# Process a line.
[...]
#{# bug fix by Ruud and Mary
# 2005-10-24 13:10
[...]
#}#
[...]
#}#
}
# Finished processing the whole file.
#}#
The code lines are 'real code', not 'commented out' code.
The comment region information can also be used by an editor to represent
collapse parts of the code by a short comment.
--
Affijn, Ruud
Larry Wall
: Or POD-ish.
Or POD-ish is what A2 proposes. I still like
=begin FOO
...
=end FOO
Larry
Damian Conway
And I'm in the midst of writing S26 (Documentation),
wherein I propose a standard:
=begin comment
...
=end comment
form.
(And, yes, they nest correctly).
Damian
Mark A Biggar
--
Mark Biggar
ma...@biggar.org
mark.a...@comcast.net
mbi...@paypal.com
-------------- Original message ----------------------
From: "Ruud H.G. van Tol" <rv...@isolution.nl>
> Perl6 could introduce (lexical, nestable) comment scope.
>
> Has that been discussed before?
>
>
Mark Overmeer
Looking very much forward to it... as you know.
But don't you think that the term "comment" is too general? The comment
text has a purpose, for instance
- comment to explain code
- comment for future implementation ideas
- references to design documents
- etc etc
The "comment" keyword is telling us nothing more than
=begin skip_this
...
=end
F.i:
=explain code
or
=begin explain code
--
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
Ma...@Overmeer.net solu...@overmeer.net
http://Mark.Overmeer.net http://solutions.overmeer.net
Dave Whipp
In P5 I often us q{...} in void context -- P6 seems to be attaching tags
to the quote operator, so q:comment{...} might fall out naturally.
Damian Conway
> Looking very much forward to it... as you know.
>
> But don't you think that the term "comment" is too general? The comment
> text has a purpose, for instance
> - comment to explain code
> - comment for future implementation ideas
> - references to design documents
> - etc etc
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
Damian
PS: I'll have a draft of S26 for this list to pore over after Ingy and I
work on it at YAPC::Tokyo in just over a week's time.
Mark Overmeer
> 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,
j...@amrita-ebook.org
of the form:
fold::<type>'<name> { <comment>
<body>
}
The basic idea is to use specialist folds for specialist tasks.
For instance "info" folds are used to add structured information.
Thus a file $abc might contain:
fold::info'manpage {
fold::info'syntax {
}
fold::info'description {
}
fold::info'examples {
fold::info'ex1 { basic usage
}
fold::info'ex1 { advanced usage
}
}
}
and I would access ex1 using any of the following:
fold::file $abc [F'ex1] -> script
fold::file $abc {F'manpage} -> {F'examples} -> {F'ex1} -> script
fold::file $abc {F0.1.3.1} -> script
Here [] and {} are used to select sets of folds: [] strips
the fold markers; {} keeps them intact. So to grab both
examples 1 and 2, keeping the fold markers intact, I would use:
fold::file $abc {F'ex1,F'ex2} -> script
I also used folds to provide an "Inline" capability, as in:
fold::perl {
print "A riddle\n";
fold::python {
print "wrapped in a mystery"
fold::ruby {
print "inside an enigma!\n"
}
}
}
plus a multitude of other purposes: fold::amr_sol introduces
a domain specfic languages for performing fluid-flow simulations;
fold::print and fold::latex use a re-entrant here-document mechanism
for generating dynamic reports; fold::sable is a text-to-speech
synthesizer; etc., etc. . For more details, see:
http://www.amrita-ebook.org/doc/drink-me
Now the point of the above rambling is that I believe it would be
short-sighted to add nested comments to Perl6 without considering
how the approach might be generalized to accomodate the co-operative
spirit of program-folds. Note I'm not arguing for the above syntax
over another, say:
<fold::perl5>
<fold::perl6>
</fold::perl6>
</fold::perl5>
But with the arrival of Parrot it would seem natural to consider
building re-entrant languages that can co-operate with one another
via a common backplane. If nothing else, it would ease the trauma
of herding the Perl5 userbase to Perl6, and then on to Perl7.
James Quirk
Larry Wall
: * Damian Conway (dam...@conway.org) [060315 01:52]:
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
Damian Conway
> : 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"...]