Re: Multiline comments in Perl6
On Thu, Jan 03, 2008 at 08:55:24PM +0200, Gabor Szabo wrote: : On Jan 3, 2008 6:36 PM, Larry Wall <[EMAIL PROTECTED]> wrote: : > On Wed, Jan 02, 2008 at 11:28:54AM -0800, Jonathan Lang wrote: : > : Paul Hodges wrote: : > : > http://perl6.org/doc/design/syn/S02.html still says: : > : > "Intra-line comments will not be supported in standard Perl" : : > Note that the document on perl6.org is nearly three years out-of-date! : > Anyone know who runs that site? We need a better GC algorithm. :) : > : > The best place to read synopses right now is probably perlcabal.org/syn : > because it has the test suite interspersed, so you can easily click : > to see test examples if you don't understand a particular passage. : : : What about http://dev.perl.org/perl6/synopsis/ ? : Is that also out of date? : http://www.pugscode.org/ links there... That is up-to-date with respect to (very official) synopses that live in svn.perl.org's repository, but not with respect to those draft synopses that currently live in pugs's repository. (The perlcabal page tracks both sets.) Larry
Re: Multiline comments in Perl6
--- Jonathan Lang <[EMAIL PROTECTED]> wrote: > Paul Hodges wrote: > > http://perl6.org/doc/design/syn/S02.html still says: > > "Intra-line comments will not be supported in standard Perl" > > This is wrong, since S02 also defines intra-line comments, under > "Whitespace and Comments". It calls them 'embedded comments'. You > don't need a 'use' statement. So I found something worth fixing? =o] === Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: Multiline comments in Perl6
On Jan 3, 2008 6:36 PM, Larry Wall <[EMAIL PROTECTED]> wrote: > On Wed, Jan 02, 2008 at 11:28:54AM -0800, Jonathan Lang wrote: > : Paul Hodges wrote: > : > http://perl6.org/doc/design/syn/S02.html still says: > : > "Intra-line comments will not be supported in standard Perl" > Note that the document on perl6.org is nearly three years out-of-date! > Anyone know who runs that site? We need a better GC algorithm. :) > > The best place to read synopses right now is probably perlcabal.org/syn > because it has the test suite interspersed, so you can easily click > to see test examples if you don't understand a particular passage. What about http://dev.perl.org/perl6/synopsis/ ? Is that also out of date? http://www.pugscode.org/ links there... Gabor
Re: Multiline comments in Perl6
On Wed, Jan 02, 2008 at 11:28:54AM -0800, Jonathan Lang wrote: : Paul Hodges wrote: : > http://perl6.org/doc/design/syn/S02.html still says: : > "Intra-line comments will not be supported in standard Perl" : : This is wrong, since S02 also defines intra-line comments, under : "Whitespace and Comments". It calls them 'embedded comments'. You : don't need a 'use' statement. Note that the document on perl6.org is nearly three years out-of-date! Anyone know who runs that site? We need a better GC algorithm. :) The best place to read synopses right now is probably perlcabal.org/syn because it has the test suite interspersed, so you can easily click to see test examples if you don't understand a particular passage. Larry
Re: Multiline comments in Perl6
Jonathan Lang wrote: > How about '~#', meaning something along the lines of "string-like > comment"? The idea is that the syntax that follows this would conform > closely to that of string literals (i.e., quotes). We might even > consider loosening the restrictions on delimiter characters, allowing > the full versatility of quoting delimiters, since there'd no longer be > any danger of confusing this with a line comment. So: For the record: if this gets implemented as I'm describing above, I will personally restrict myself to using bracketing characters as the delimiters. Non-bracketing delimiters have issues that, as a programmer, I don't want to have to deal with: e.g., if I were to use '~#/ ... /' to comment out a block of code, I'd have to be very sure that said code doesn't do any division. This is still a problem with brackets, but less so - especially with the ability to double up (or more) on the brackets. E.g., '~#[[ ... ]]' pretty much guarantees that I'll comment out exactly what I want to comment out on the first try. Oh, and I just realized: '~#( ... )' looks a bit like an ascii-graphics thought bubble, as used in old text-based MUXs. If '~#' gets nixed, perhaps 'oO' would be a viable alternative? $x = oO(here's a comment) 5; -- Jonathan "Dataweaver" Lang
Re: Multiline comments in Perl6
I've been putting a fair amount of thought into this. Here's what
I've come up with:
Perl 6 has several instances where whitespace is required or forbidden
in order to better facilitate "Do What I Mean" programming: for
instance, by having the presence or absence of whitespace before curly
braces affect their meaning, you're allowed to omit the parentheses
around the parameters of the various control structures: e.g., 'if $x
{ ... }' is now valid, whereas in Perl 5 you would have had to say 'if
($x) { ... }'. Likewise, the same technique lets you provide an
unambiguous distinction between an infix operator and a postfix
operator (IIRC). So it isn't much of a stretch to require the use of
whitespace in order to distinguish between a standard "line comment"
and an embedded comment.
Except that that isn't what Perl 6 is doing. All that it does is to
say "there's this one case where there's some ambiguity between line
comments and embedded comments; it's up to the programmer to remove
the ambiguity, through whatever means he sees fit." In many ways,
this is the opposite of the above cases, and is more akin to how role
composition must be explicitly disambiguated by the programmer,
instead of having the compiler take a best guess.
I must admit: as nice as it is to be able to create an embedded
comment by wrapping the actual comment in brackets, the existence of
that one point of ambiguity is troubling.
--
What I like about the current embedded comments:
1. They're short. You need a single leading character (the '#'),
followed by content wrapped in as little as a pair of bracketing
characters. That's three characters in addition to the content
itself.
2. They're flexible. By going with user-specified bracketing
characters, the programmer can choose an intuitive "closing sequence"
that won't conflict with content that he's commenting out.
Of the two features, the second one is the more important one.
Likewise, the central most important feature concerning line comments
is that you can initiate them using a single character, allowing you
to reliably comment out a set of lines through a straightforward - and
short - sequence of keystrokes.
The problem arises from the fact that embedded comments start with the
same character that line comments start with. This means that the
second character is the one that gets used to distinguish between line
comments and embedded comments, which at best interferes with the main
benefit of line comments described above, and at worst leads to an
extra round of debugging as the programmer is forced to go through and
add whitespace (or other characters) to disambiguate the two.
--
The solution, then, would be to change embedded comments so that
they're initiated by something that doesn't begin with a '#'.
Ideally, you'd still use a single character (plus the brackets) to
define an embedded comment. Unfortunately, I'm pretty sure that we've
got a severe shortage of such characters available for use. Assume,
then, that a two-character initializer is going to be needed, and that
the first character cannot be a '#'.
--
I'm leery about making the first character be a '=', as there's the
potential for conflict with POD sections. IIRC, there's a (currently
unspoken?) design goal involving POD sections that says that any line
beginning with a '=' ought to be able to be stripped out of the
program without affecting the code. Those with more familiarity with
POD design philosophy can please speak up?
OTOH, it might be possible that '=#[ ... ]' could be used to add
versatility to the POD syntax. Consider the possibility of saying
that '=#[blah blah blah]' at the start of a line is equivalent to
'=blah blah blah', except that the POD header ends at the ']' instead
of the first '\n'. This could be used to wrap a POD header over
several lines, and/or to put the first line of POD content on the same
line as a short POD header. So:
=#[for comment
] text
foo;
would be equivalent to:
=for comment
text
foo;
...or not; this could lead to the same sort of trouble that we
currently have with line comments vs. embedded comments. If we were
to go this route, I'd be inclined to say that '=#[ ... ]' isn't just
an embedded comment; it's an "embedded POD header". This removes all
ambiguity regarding what it is, at the expense of forcing the POD
Parser to look at more than just the first character of each line to
determine whether or not it's meaningful. The expense may be too
great. At the very least, it opens up a whole new can of worms.
--
OK; so let's assume a two-character sequence prior to the opening
bracket of an embedded comment, with the first character being
something other than '#' or '='. It's perfectly acceptable (and,
IMHO, desirable) for the second character to be a '#'.
How about '~#', meaning something along the lines of "string-like
comment"? The idea is that the syntax that follows this would conform
closely to that of string literal
Re: Multiline comments in Perl6
Paul Hodges wrote:
> http://perl6.org/doc/design/syn/S02.html still says:
> "Intra-line comments will not be supported in standard Perl"
This is wrong, since S02 also defines intra-line comments, under
"Whitespace and Comments". It calls them 'embedded comments'. You
don't need a 'use' statement.
> Is there any restriction of the whitespace *inside* the comment?
Not from my reading of it, no.
> And is / a valid bracketer?
No. The valid bracketers are defined under "Lexical Conventions" - in
layman's terms, bracketing characters are matching pairs of
characters: so '(' and ')' are bracketing characters, but '/' is not.
Likewise, the matches are based on individual characters, so if you
use "<--" at the start of a bracketed segment, only the "<" counts as
a bracketing character.
> or should I stick to things like
>
>$x = #<-- comment --> 1;
>$x = #{ comment #} 1;
>$x = #( comment +) 1;
>$x = #[ comment =o] 1;
>
> Or will any of these not work?
All four of those work as written.
In addition, S06 demonstrates how you can use macros to create custom
embedded comments:
macro circumfix:«» ($text) is parsed / .*? / { "" }
--
Jonathan "Dataweaver" Lang
Re: Multiline comments in Perl6
I love this list. I wish I had more of value to contribute. =o]
But for those of you who don't want to read a long blather, this is
mostly opinion, hopefully sans soapbox. Feel free to skip to the end.
> What's with the sudden influx of people swooping in at the
> last minute and attacking design decisions that were made, with much
> angst and public debate, over the span of months and years? It's not
> like @Larry are doing things based on whim; if they were, Perl6 would
> have been done 2+ years ago.
I agree 100%. In fact, I've been guilty of this myself, but the point
is valid...and I think the was a nice touch. Still, we do want
to keep polling the user base, if hopefully with a minimum of spam. As
long as we don't lose the forum under a deluge of whining and
me-too-isms, I think it's good to get the occasional, abbreviated
re-airing of old issues. For example, I missed this one the first dozen
times through
I don't like having to think about whitespace so much, but I'll get
used to that. Virtually every language uses significant whitespace, and
though P6 seems to be more saturated with *relevant* whitespace issues,
as a rule of thumb I have been bluntly impressed with what the @Larry
have been accomplishing. I'll learn, I'll deal, and I'll be happy for
the toys they let me buy with those quirks, lol
But for my meager $.02 in the matter
http://perl6.org/doc/design/syn/S02.html still says:
"Intra-line comments will not be supported in standard Perl"
I obviously missed something again here. Could someone clue me in?
Isn't that what this thread is talking about with #{...}?
I assume it's a module-based construct, like most everything else?
Line comments and POD are fine, but I have (on occasion) missed being
able to use embedded comments. I'm glad they'll be available now, but I
doubt I'd add a use() to get them most of the time -- just personal
preference; I'd rather save the line of code, lol. I don't personally
even mind having to deal with the whitespace rule, though it does feel
pretty wierd to me.
I think the bracketing construct is a cool concept. Start with a
hashmark and follow it with a bracketing construct, and it comments
everything in the bracket but I have to say just for the
accumulation of weight on the issue that it's going to really take some
time for me to get used to thinking of comments as ending with just a
bracket, especially since I'll have to trace back to the matching
structure to make sure it's the right bracket.
Syntactically, I know @Larry's a lot smarter than I am, so I defer, but
could we start thinking now, as a community, in terms of standards for
this? I mean, correct me if I'm wrong, but didn't most of us follow the
general convention of making filehandle names capitalized in P5? Perl
didn't care, but it's a courtesy we observed for ourselves and the
inheritors of our code. Of course, I usually used a scratchpad variable
instead.
So I'll probably tend to use some standard set of brackets and "flag"
characters just for my own benefit. On that note, I do have a couple of
actual questions. =o)
Is there any restriction of the whitespace *inside* the comment?
And is / a valid bracketer? Is there any problem with something like:
@x = #/* here's an embedded comment */ 1..99;
or should I stick to things like
$x = #<-- comment --> 1;
$x = #{ comment #} 1;
$x = #( comment +) 1;
$x = #[ comment =o] 1;
Or will any of these not work?
I suppose there's always #{/* foo */}
Or when all else fails, just move the comment to a line of it's own, or
a block of POD. ;o]
Thanks for your patience and your input,
Paul
--- "Mark J. Reed" <[EMAIL PROTECTED]> wrote:
> Whitespace is significant in many places. Even in some of the
> corners of Perl 5. Perl 6 has a different set of rules, and it
> will take some getting used to, but the rules are designed to
> let you do things as naturally as possible.
> This, for instance, works fine:
>
> my @values =
> # (1,2,3) # older values, don't use
> (4,5,6);
>
> If I were suddenly granted the magical ability to impose my will upon
> the design of Perl 6 and change anything I wanted, the multi-line
> comments leading-whitespace exception would not make the top 5.
>
> What's with the sudden influx of people swooping in at the
> last minute and attacking design decisions that were made, with much
> angst and public debate, over the span of months and years? It's not
> like @Larry are doing things based on whim; if they were, Perl6 would
> have been done 2+ years ago.
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: Multiline comments in Perl6
On Dec 30, 2007 8:10 AM, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Let's say that the programmer in question wants to comment out all but
> the third line; so he prefixes everything else with '#':
>
> #if ($test)
> #{
>.say;
> #} else {
> # .doit;
> #}
>
> What the writer _wants_ this to do is the equivalent of:
>
>.say;
>
> What he'd get with embedded comments would be the equivalent of:
>
>else {
>
Isn't this still a problem if you have something like:
if ($test)
{
.say;
#if ($test2)
#{
.dothat;
#} else {
# .dosomethingelse;
#}
} else {
.doit;
}
I know the answer is to comment at the beginning of the line instead of
later, but still, this is a fairly common practice and is likely to be just
as confusing (if not more, because of the whitespace rules), as allowing #()
to come at the beginning of the line. I'm all for DWIM, but this seems like
it will lead to a lot of head scratching.
Most places in the grammar that have strange whitespace rules or require
other methods of disambiguation at least seem to have a good reason for it;
these are comments, should we really create a mess of potential compiler
errors and limit where embedded comments can be (not allowing them to be the
first thing on a line is pretty strange) just to use this particular
syntax? Like someone else mentioned, every other language has multi line
comments without weird problems like this, why can't we just pick a
construct that isn't so prone to ambiguity?
I suggest we use # for single line comments and ##() for multi line comments
(just adding an extra leading # to differentiate). This has the added
benefit of standing out a bit more to anyone skimming the code.
Re: Multiline comments in Perl6
>> Thanks for the reply - can you please what is the problem with having it in the beginning of the line? > > Short answer: the compiler has no way of knowing whether the > programmer wants an embedded comment or a line comment; so instead of guessing, it requires the programmer to disambiguate. > Is it not possible to skip the commented sections by the parser? Why have every other popular language, that i know, multiline comments included without any problems? It would be very useful for better developing with perl. If you would use a mlc like =# #= where the opening tag must stay on the beginning of the line and you would leave complete the line on closing tag #= also commented you could put it into perl5 and none existing script or module should get broken. Christian
Re: Multiline comments in Perl6
Offer Kaye wrote:
> #( commenting out a large code section, yey for Perl6 multi-line comments...
>if ($foo) {
> print "...or not :(\n"
>}
> ) # this should have been the end of the embedded comment
...and since it wasn't, you probably should have chosen other brackets such as:
#[[ commenting out a large code section, yey for Perl6 multi-line comments...
if ($foo) {
print "...or not :(\n"
}
]]
or just used POD sections:
=begin comment
if ($foo) {
print "...or not :(\n"
}
=end comment
> Comments are a some of the most commonly used constructs in code.
> Every code has them, even the simplest script. If you have to "get
> around" a limitation whenever using them (your words - "but it's easy
> enough to get around that restriction") you're doing something wrong
> with their design.
My words; not the designer's.
> Where is the sense in making the closing of the
> embedded comment a single bracket only?
It seems so natural to me that I find myself wondering how it can be
thought of as nonsense.
> I think the Perl 5 method of having just # for single-line and =pod
> for multi-line was better.
IMHO, the _only_ problem with the current commenting system is that
there's potential ambiguity when you start a line with '#('. Many of
us find that the benefits of having embedded comments outweigh this
one flaw.
> Yes simple Perl users I know didn't use
> =pod but it was there if they needed it.
It still is. Embedded comments do not replace POD sections any more
than they replace traditional line comments.
--
Jonathan "Dataweaver" Lang
Re: Multiline comments in Perl6
Whitespace is significant in many places. Even in some of the corners of Perl 5. Perl 6 has a different set of rules, and it will take some getting used to, but the rules are designed to let you do things as naturally as possible.This, for instance, works fine: my @values = # (1,2,3) # older values, don't use (4,5,6); If I were suddenly granted the magical ability to impose my will upon the design of Perl 6 and change anything I wanted, the multi-line comments leading-whitespace exception would not make the top 5. What's with the sudden influx of people swooping in at the last minute and attacking design decisions that were made, with much angst and public debate, over the span of months and years? It's not like @Larry are doing things based on whim; if they were, Perl6 would have been done 2+ years ago.
Re: Multiline comments in Perl6
On Dec 30, 2007 6:10 PM, Jonathan Lang wrote:
>
> Short answer: the compiler has no way of knowing whether the
> programmer wants an embedded comment or a line comment; so instead of
> guessing, it requires the programmer to disambiguate.
>
[...snip...]
>
> # if ($test)
> # {
> .say;
> # } else {
> # .doit;
> # }
>
> or
>
>#{ start here } if ($test)
> {
> .say;
> } else {
> .doit;
> }
>
> --
> Jonathan "Dataweaver" Lang
>
This feature is horrible :(
I'm sure many people will be confused and badly surprised when
commenting out code and getting un-expected errors or worse behaviour
they didn't expect. It forces me as a Perl programmer to pay attention
to whitespace at locations where whitespace, for me, has always been
trivial:
my @arr =
#(1,2,3); # older values, don't use...
(4,5,6); # correct set of values
Oops compiler error? Or strange behavior? If I wanted to be careful of
my whitespace I would be writing Python...
#( commenting out a large code section, yey for Perl6 multi-line comments...
if ($foo) {
print "...or not :(\n"
}
) # this should have been the end of the embedded comment
This is like that thing that makes me hate Tcl comments, you know,
bracers in comments causing compiler errors...
Comments are a some of the most commonly used constructs in code.
Every code has them, even the simplest script. If you have to "get
around" a limitation whenever using them (your words - "but it's easy
enough to get around that restriction") you're doing something wrong
with their design. Where is the sense in making the closing of the
embedded comment a single bracket only?
I know a lot of very smart people are working on the design of Perl 6
and have no problem keeping their sample Perl6 code working with the
new comment system. But you have to remember the typical Perl user (I
am one and I meet others at work ;)) is not going to like getting
spurious compiler errors, only to find out he did leave (or didn't
leave) a whitespace before (or after) his comment char (see how
confusing that sounds?), or that his multi-line comment closed
un-expectedly by a single brace. I can already see the debugging
sessions...
I think the Perl 5 method of having just # for single-line and =pod
for multi-line was better. Yes simple Perl users I know didn't use
=pod but it was there if they needed it. A good script-able editor was
really all that was needed if you wanted to comment or un-comment
several lines at once.
Maybe some people will even argue that "=pod" is too confusing - you
need to worry about whitespace there too which is bad - but at least
you could not close that multi-line by accident.
Please stick with what works, don't build a solution that is worse
than the problem it is meant to solve...
Best regards,
--
Offer Kaye
Re: Multiline comments in Perl6
Amir E. Aharoni wrote:
> On 30/12/2007, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> > The only wart
> > is that '#( ... )' cannot begin at the very start of a line; but it's
> > easy enough to get around that restriction - say, with some leading
> > whitespace.
>
> Thanks for the reply - can you please what is the problem with having
> it in the beginning of the line?
Short answer: the compiler has no way of knowing whether the
programmer wants an embedded comment or a line comment; so instead of
guessing, it requires the programmer to disambiguate.
Long answer: a standard method of commenting out code is to manually
prefix each line with a '#'. If embedded comments were allowed at the
beginning of a line, then people using this technique would
occasionally get some nasty surprises. For example:
if ($test)
{
.say;
} else {
.doit;
}
Let's say that the programmer in question wants to comment out all but
the third line; so he prefixes everything else with '#':
#if ($test)
#{
.say;
#} else {
# .doit;
#}
What the writer _wants_ this to do is the equivalent of:
.say;
What he'd get with embedded comments would be the equivalent of:
else {
--
Initially, the rule was that any line beginning with a '#' would be
considered a line comment, regardless of what the second character is.
The result was that the above code worked as expected. However, it
lead to the possibility of someone putting a '#{' at the start of a
line, expecting an embedded comment, and getting a line comment
instead:
#{ start here } if ($test)
{
.say;
} else {
.doit;
}
There's no way for the compiler to reliably guess which semantics the
programmer intended, so it complains. The easiest way to keep it from
complaining is to add some whitespace:
# if ($test)
# {
.say;
# } else {
# .doit;
# }
or
#{ start here } if ($test)
{
.say;
} else {
.doit;
}
--
Jonathan "Dataweaver" Lang
Re: Multiline comments in Perl6
On 30/12/2007, Jonathan Lang <[EMAIL PROTECTED]> wrote: > The only wart > is that '#( ... )' cannot begin at the very start of a line; but it's > easy enough to get around that restriction - say, with some leading > whitespace. Thanks for the reply - can you please what is the problem with having it in the beginning of the line?
Re: Multiline comments in Perl6
Christian Mueller wrote:
> i don't know the actually state in the discussion about multiline
> comments, but i would propose an idea.. a combination of POD's = and the
> traditional route char...
Perl 6 already has a robust system for multiline and embedded
comments, as described in S02 under "Whitespace and Comments". In
brief, multiline comments are handled by means of POD sections, while
embedded comments are handled by '#( ... )', where '(' and ')' can be
any matching pair of one or more bracketing characters. The only wart
is that '#( ... )' cannot begin at the very start of a line; but it's
easy enough to get around that restriction - say, with some leading
whitespace.
There was a brief flirtation with the idea of having '#(' at the start
of the line begin a multiline comment instead of simply being an
error; but the notion was quickly abandoned.
--
Jonathan "Dataweaver" Lang
Re: multiline comments
It was just kind of a pain because you had to put a "=cut" after the "=end", and because you had to put paragraph spaces between everything. We're getting rid of both of those restrictions. Excellent! That's what was really bugging me. I'm really glad that is changing :) Thanks, Alfie
Re: multiline comments
Alfie John skribis 2005-10-12 15:28 (+1000): > Does Perl6 support multiline comments? All incarnations of Perl have allowed us to begin multiple subsequent lines with the comment glyph '#'. I am sure Perl 6 will not break this tradition. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: multiline comments
On 10/12/05, Alfie John <[EMAIL PROTECTED]> wrote: > On 12/10/2005, at 3:33 PM, Luke Palmer wrote: > > =begin comment > > =end comment > > But does that then break my lovely formatted pod like it does in Perl5? Try this: % cat > dosomething.pl =head1 TITLE Thingy - do something =head1 DESCRIPTION =over =item * do_something() does something =cut =begin comment Commented out code. =end comment =cut =item * do_something_else() does something different from C. =back =cut ^D % perldoc dosomething.pl # note the lack of the string "Commented out code" So it worked in Perl 5, too. It was just kind of a pain because you had to put a "=cut" after the "=end", and because you had to put paragraph spaces between everything. We're getting rid of both of those restrictions. Luke
Re: multiline comments
On 12/10/2005, at 4:18 PM, Mark A. Biggar wrote: Alfie John wrote: Hi (), This is probably a stupid question, but I can't find anything from google: Does Perl6 support multiline comments? Briefly, No and kind of. Standard Perl 6 comments are just like those in Perl 5. A '#' starts a comment that is terminated by the end of line. But, both Perl 5 and 6 are intended to support the POD system of embedded documentation (for the 'kind of'.) Of course the grammar is planed to be dynamically modifiable so a Perl module could theoriticaly declare it own special multi-line comment system. -- [EMAIL PROTECTED] [EMAIL PROTECTED] So, my question now is will the Perl6 perldoc be extended to allow filters to be run so that these "theoretical multi-line comment systems" will be run before spitting out to STDOUT? Alfie
Re: multiline comments
Alfie John wrote: Hi (), This is probably a stupid question, but I can't find anything from google: Does Perl6 support multiline comments? Briefly, No and kind of. Standard Perl 6 comments are just like those in Perl 5. A '#' starts a comment that is terminated by the end of line. But, both Perl 5 and 6 are intended to support the POD system of embedded documentation (for the 'kind of'.) Of course the grammar is planed to be dynamically modifiable so a Perl module could theoriticaly declare it own special multi-line comment system. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: multiline comments
On 12/10/2005, at 3:33 PM, Luke Palmer wrote: On 10/11/05, Alfie John <[EMAIL PROTECTED]> wrote: Does Perl6 support multiline comments? Yes, in the form of pod blocks. =begin comment =end comment They nest, too. Luke But does that then break my lovely formatted pod like it does in Perl5? Alfie
Re: multiline comments
On 10/11/05, Alfie John <[EMAIL PROTECTED]> wrote: > Does Perl6 support multiline comments? Yes, in the form of pod blocks. =begin comment =end comment They nest, too. Luke
Re: multiline comments
>Tom Christiansen wrote: >> #if 0 >> ... >> #endif >Ahem, has somebody already mentioned -P (perldoc perlrun)? >If you want 'em, you already got 'em! I'm in the choir, preacher! IWTFM. :-)/3 --tom
Re: multiline comments
Tom Christiansen wrote: > #if 0 > ... > #endif Ahem, has somebody already mentioned -P (perldoc perlrun)? If you want 'em, you already got 'em! -- [EMAIL PROTECTED]
RE: multiline comments
I thought that that was just the plan. Form sub lists to collect ideas that needed hashing, if that hashing got involved make sub-lists to reach consensus on those. You have a nice thread handeling mail client, don-ch tom? -Corwin -Original Message- From: Tom Christiansen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 02, 2000 4:58 PM To: Michael Mathews Cc: [EMAIL PROTECTED] Subject: Re: multiline comments >The way I see it Santa (aka Larry) has asked for our wish list. This is not >the time to dwell on all the ways we can make due with our old toys. I still think saying :10,20s/^/##XXX## / is the cleanest and most visually apparent block comment. >PS I'm all for a new list. How do I get one? I see no reason to have per-sub-sub-sub-topic lists. --tom
Re: multiline comments
>The way I see it Santa (aka Larry) has asked for our wish list. This is not >the time to dwell on all the ways we can make due with our old toys. I still think saying :10,20s/^/##XXX## / is the cleanest and most visually apparent block comment. >PS I'm all for a new list. How do I get one? I see no reason to have per-sub-sub-sub-topic lists. --tom
Re: multiline comments
Hi Tom,
Of course you should consider that the programmer may be block commenting a
section of code precisely because it does contain sytax errors. I often do
so as a way of isolating hard to track bugs. I can't imagine how getting
more courteous error messages would be a Good Thing!
Lets face it -- comments in general are a luxury. Certainly "#" could be
eliminated from Perl and people could all invent workarounds using POD, or
stuff like $comment="check counter variable here" in their code. I just
don't understand why folks are so opposed to real block comments like other
languages have (yeh yeh, I know).
The way I see it Santa (aka Larry) has asked for our wish list. This is not
the time to dwell on all the ways we can make due with our old toys.
--Michael
PS I'm all for a new list. How do I get one?
- Original Message -
From: "Tom Christiansen" <[EMAIL PROTECTED]>
To: "Michael Mathews" <[EMAIL PROTECTED]>
Cc: "Nick Ing-Simmons" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, August 02, 2000 5:33 PM
Subject: Re: multiline comments
> >> What is wrong with
> >>
> >> if (0) {
> >>
> >> }
>
> >1) what if the block contains syntax errors?
>
> Then the compiler carefully and courteously notifies you of such.
>
> >2) what if the bloack contains unmatched braces?
>
> See above.
>
> >3) this is not easier to type or remember than the currently available
> >workarounds.
>
> Au contraire. It's *TRIVIAL* to remember, as it requires no new syntax
> and hacks and features and scoot-arounds. Likewise most of the rest
> of them.
>
> --tom
Re: multiline comments
Michael Mathews wrote:
>
> > if (0) {
> > }
>
> 1) what if the block contains syntax errors?
> 2) what if the bloack contains unmatched braces?
> 3) this is not easier to type or remember than the currently available
> workarounds.
TIMTOWTDI.
--
John Porter
Re: multiline comments
>> What is wrong with
>>
>> if (0) {
>>
>> }
>1) what if the block contains syntax errors?
Then the compiler carefully and courteously notifies you of such.
>2) what if the bloack contains unmatched braces?
See above.
>3) this is not easier to type or remember than the currently available
>workarounds.
Au contraire. It's *TRIVIAL* to remember, as it requires no new syntax
and hacks and features and scoot-arounds. Likewise most of the rest
of them.
--tom
Re: multiline comments
>What is wrong with
> if (0) {
> }
>(and of course teaching op builder not to build them in this case).
Funny, I was going to mention that I always use
#if 0
...
#endif
in C for nesting, block comments. Which is rare anyway, rarer perhaps
than this discussion would seem to merit.
--tom
Re: multiline comments
> What is wrong with
>
> if (0) {
>
> }
1) what if the block contains syntax errors?
2) what if the bloack contains unmatched braces?
3) this is not easier to type or remember than the currently available
workarounds.
Re: multiline comments
Buddha Buck <[EMAIL PROTECTED]> writes:
>
>The one concern I would raise about this is that a common use of multi-line
>comments is to dyke out code.
What is wrong with
if (0) {
}
(and of course teaching op builder not to build them in this case).
--
Nick Ing-Simmons
Re: multiline comments
Peter Scott wrote: > At 02:53 PM 8/2/00 -0400, John Porter wrote: > >Perhaps a better way would be a change in the semantics of scalar > >literals in void context, to be silently ignored. > > No! It's a major typo/bug-catcher. Strange, my experience does not confirm that one whit. -- John Porter
Re: multiline comments
At 02:53 PM 8/2/00 -0400, John Porter wrote: >Perhaps a better way would be a change in the semantics of scalar >literals in void context, to be silently ignored. No! It's a major typo/bug-catcher. -- Peter Scott Pacific Systems Design Technologies
Re: multiline comments
Bart Lateur wrote: > > < This is comment! > And more... > END_OF_COMMENT > > Apart from the warning "Useless use of a constant in void context", it > works. Yes; but it was precisely that warning which I was intending to address. Perhaps a better way would be a change in the semantics of scalar literals in void context, to be silently ignored. Then you can make a comment any way you want. -- John Porter
Re: multiline comments
On Wed, 2 Aug 2000 12:51:10 -0400, John Porter wrote:
>> At the risk getting too exotic how about:
>>
>> #<> some
>> comments
>> EOC
>
>Just introduce a new function which is a bit bucket:
>
> # works in perl5.
> sub comment(@) { }
>
> comment q{ comments... };
"Function"? Who needs a function?
<
Re: multiline comments
>It nice to be able to bounce on % in vi, too:
>=#{
>comment
>=#}
You easy to do this already:
=begin comment {
=end comment }
--tom
Re: multiline comments
Michael Mathews wrote:
>
> At the risk getting too exotic how about:
>
> #< some
> comments
> EOC
Just introduce a new function which is a bit bucket:
# works in perl5.
sub comment(@) { }
comment q{ comments... };
comment <
Re: multiline comments
Buddha Buck wrote:
>
> The one concern I would raise about this is that a common use of multi-line
> comments is to dyke out code. As such, it is handy to have the start and
> end markers different, and allow nesting.
It nice to be able to bounce on % in vi, too:
=#{
comment
=#}
--
John Porter
Re: multiline comments
Buddha Buck wrote: > The one concern I would raise about this is that a common use of multi-line > comments is to dyke out code. As such, it is handy to have the start and > end markers different, and allow nesting I see your point. At the risk getting too exotic how about: #<
Re: multiline comments
At 10:55 AM 8/2/00 -0400, Michael Mathews wrote: >I am prone to agree with this. I would be willing to promote the requirement >of starting and ending multiline comments on their own line. Maybe something >like this (this will not work in Perl 5): > >code to execute >=# >some >comments to >ignore >=# >more code to execute The one concern I would raise about this is that a common use of multi-line comments is to dyke out code. As such, it is handy to have the start and end markers different, and allow nesting. With identical start and end markers, I risk un-commenting previously commented material by accident. Commenting out your example: =# code to execute # commented out =# some comments to ignore # that aren't being ignored =# more code to execute # commented out =# I see problems. Changing the "=#" to "=#<" and =#>" (or something) would allow comments to nest properly. >And this would also be more backwards similar. > >--Michael
Re: multiline comments
Tom Christiansen responded: > One argument *against* intra-token-sequence multiline comments is that they > are harder to see, and thus render readers of the code more prone to > misunderstand it. Is this worth really promoting? > Settling on one > pod target for multiline comments, and then defining the =for and =end of > that target to implicitly =cut back to code, would seem to address both of > these issues I am prone to agree with this. I would be willing to promote the requirement of starting and ending multiline comments on their own line. Maybe something like this (this will not work in Perl 5): code to execute =# some comments to ignore =# more code to execute And this would also be more backwards similar. --Michael
Re: multiline comments
One argument *against* intra-token-sequence multiline comments is that they are harder to see, and thus render readers of the code more prone to misunderstand it. Is this worth really promoting? The extant pod-based multiline comment solution does not suffer from this, as it is quite easy to see, owing to its column-zero constraint. It also avoids the gnarly games that C programmers play of /* covertly placing */ comments midsequence in the token stream. However, as currently employed, these pod comments *do* suffer from a couple of potentially non-trivial problems in their own right. The more important of these is that when you're done with a "=for commentary" or an "=end commentary", you're not back in code mode. The other issue is that there is no standardly accepted target name indicative of comment status, which means that people's choices in this will not be predictable. Lack of predictability hampers machine analysis, which is desirable for easy extraction (perhaps for significant comments?) and so that the translators can casually ignore these without remonstration. Can we do something about this easily enough? I think so. Settling on one pod target for multiline comments, and then defining the =for and =end of that target to implicitly =cut back to code, would seem to address both of these issues. Is there some reason that these funky punctuational and easy-to-miss intra-sequential multiline comments are to be preferred over this strategy? As a quasi post script, that reminds me that *perhaps* pod is the way to go as far as significant comments are concerned. If we don't get sufficiently rich declarations of input and output types and ranges to happify the poor tiny-active-working-set people with their expert-hostile, user-obsequious IDEs, then we could probably painlessly stake out some structured pod territory for this explicit purpose. This would have the advantage of being backwards compatible, but perhaps one doesn't care so much in this particular arena. --tom
Re: multiline comments
Tom Christiansen asked > Do you really think > =for comments > or > =begin comments > ... > =end comments > are that bad? Sure, they have to be on statement boundaries, but > that's more of a feature than a bug. Hi Tom, Do I think it is "that bad"? No. Of course not. I use it all the time. In fact I'm very used to it. But that's not the point. The question I, as a member of this mailing-list was presented with was (something like) "If you, the perl programming community, could reinvent Perl, what would you like to end up with?" So rather than making a list of things I am used to, or things that I don't think are that bad, I chose to look at Perl with fresh eyes. I considered other programming languages I use. I tried to recall the things that made Perl so hard for me to learn, back in the beginning. Lack of multiline comments was not a big thing, nor was it high on the list, but I *was* asked to say whatever my opinion was, so I did. Can Perl survive and even thrive without multiline comments? Yes! Could we continue to instruct newcommers that perl multiline comment are spelled "P - O - D". Sure! Heck, we could even say its a quaint feature, a reminder of Perl's roots as a (primarily) Unix shell scripting language. Perhaps that will be what we all decide -- that its not worth the trouble, that we like things how they are, or whatever. I will happily continue using and supporting Perl. However the proposition is on the table. I've given my arguments for why I think it should be considered. But, to paraphrase JFK, I don't believe the question is *why* (make things clearer, more logical, more powerful) but instead I would ask you, why not?!! (And this is not retorical. I invite you, and everyone, to offer up some arguments, just please, a little meatier than "its not that bad".) --Michael
Re: multiline comments
Plus you're still running à la pod mode, not à la code mode, as mentioned on p630 of PP3. (I just looked to make sure multiline comments were in the index. They are.) --tom
Re: multiline comments
>I apologize if this has already been gone over but I would really like to >throw one out there: real Multi-line comments. >This one has been bugging me for a long time. Any ideas? >How about #/ lots of lines of code here, this is not backwards compatable, >however /# Do you really think =for comments or =begin comments ... =end comments are that bad? Sure, they have to be on statement boundaries, but that's more of a feature than a bug. --tom
