Re: RFC: multiline comments
Of all the variations that I've seen so far (I'm way behind on reading
the list), the one I like the best is:
qc{ multi
line
comment
here }
Second best, but still acceptable would be:
#END
multi
line
comment
END
The reason it's second best, is because qc{ canbeusedinline } as well as
multi-line. It's just an extension of the existing quoting mechanism.
The # comment # variations just don't seem "perlish" to me. Sorry!
That's just a personal feeling.
If you just have to go with the # set for a block comment, I rather
like the idea of making them # and # to end, starting in the first
column.
Again, for the stated purpose, #ifdef seems to be the more reasonable
way to go, rather than putting in a truly cryptic usage of the comment
pound sign.
E.W.
John Porter wrote:
Michael Mathews wrote:
So this should work in Perl 6
code here;
#
# this is a single line comment
$foo = $a + $b # here's an in-line comment # + $c * $d;
#
more code here;
If starting in column 1 is going to be magic, you may as well
make the magic char #, so:
#
# this is a single line comment
$foo = $a + $b # here's an in-line comment # + $c * $d;
#
And then, you may as well make it =, and use some meaningful
verbiage instead of "" and "". So:
=begin comment
# this is a single line comment
$foo = $a + $b # here's an in-line comment # + $c * $d;
=end comment
The pod solution is more or less obvious. Inlinable nestable
comments are something else, and it should look like perl.
qc() -- compiled to nothingness.
--
John Porter
Re: RFC: multiline comments
I should read what has been said about the matter earlier...but lacking the time, I'll just shoot: What's wrong with stealing from C/C++/Java instead of trying to invent our own? In other words, what's wrong with /* ... */? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC: multiline comments
I also confess to liking // more for till-end-of-line comment marker than #, the hash looks so messy to my eye...of course, // already has a meaning... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC: multiline comments
Jarkko Hietaniemi [EMAIL PROTECTED] writes: I also confess to liking // more for till-end-of-line comment marker than #, the hash looks so messy to my eye...of course, // already has a meaning... I'm the other way around. This may depend a lot on whether one comes from a shell scripting background or from a C++ background. I strongly dislike C++ and other than Perl primarily use C and shell, so # is the most natural to me and // looks really odd. Of course, like you said, we really can't use // anyway, as it's valid Perl code and actually semi-frequently used. I do agree that there's a lot to be said for using /* ... */ for multiline comments, but then I'm a C programmer. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC: multiline comments
Russ Allbery wrote: Jarkko Hietaniemi [EMAIL PROTECTED] writes: I also confess to liking // more for till-end-of-line comment marker than #, the hash looks so messy to my eye...of course, // already has a meaning... I'm the other way around. This may depend a lot on whether one comes from a shell scripting background or from a C++ background. I strongly dislike C++ and other than Perl primarily use C and shell, so # is the most natural to me and // looks really odd. Of course, like you said, we really can't use // anyway, as it's valid Perl code and actually semi-frequently used. I do agree that there's a lot to be said for using /* ... */ for multiline comments, but then I'm a C programmer. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ I agree. The '#' has become a staple of Good Formatting in Perl. For multiline comments in Perl, how about something like #$ .. $# or #* .. *#? There is something to be said for the cliche ## comment blocks at the top of Perl programs, but maybe a neater alternative should be considered... -- Mike Pastore [EMAIL PROTECTED]
Re: RFC: multiline comments
please move this thread to the mlc list. thanx, uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
A Unicode fallacy [Was: Re: RFC: multiline comments]
The message below gives the context for this diatribe.
A perl script is probably written in a particular language, probably for
users of that language, possibly for users of a second language. Unless
there are lots of I18N type features added into Perl to allow extracting
all string constants from the language (which, in a text processing
language, or at least for multitudes of text processing scripts, would be
extremely hard), these one or two languages are it.
Now the use of one, or worse, several Unicode character outside the
bounds of those two languages as a choice of delimiter might seem to be a
clever idea, but really it is not. The use of such characters presumes
that all the consumers of the script (those that read it, not run it)
must have installed fonts containing the appropriate glyph for that
character, otherwise it will probably appear as a "splotch" in their
editor. It is not at all clear that the various splotches will be
visually distinguishable in such an editor. An editor like Emacs would
render them in octal, which is visually distinguishable, but rather gross
to view.
Stick with characters in the normal character set of the author of the
script, except for forays into the language of the users of the script.
John Porter wrote:
Glenn Linderman wrote:
qc( Here's a quick comment which actually contains
qc( another comment )
within it
);
This type of comment will not comment out arbitrary text.
In particular, it might have problems with text containing
mismatched (){}.
This is already an issue with the existing q.() operators --
which is to say, I don't think it's something we need to worry about.
That's not to say that we shouldn't have multi-char q.() delimiters;
being able to say qq({ }) might be nice, for example.
Also consider the impact of Unicode, which will allow any reasonable
pair of matching Unicode characters. I.e. instead of multi-char,
think wide-char.
And yet using non-paired
delimiters doesn't allow commenting out comments.
Since what I think this means is false, you probably mean
something else...
--
John Porter
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
Re: A Unicode fallacy [Was: Re: RFC: multiline comments]
Glenn Linderman wrote: Stick with characters in the normal character set of the author of the script, except for forays into the language of the users of the script. Good advice for the programmer, perhaps; but it should not be perl's job to enforce that discipline. -- John Porter
Re: A Unicode fallacy [Was: Re: RFC: multiline comments]
John Porter wrote: Glenn Linderman wrote: Stick with characters in the normal character set of the author of the script, except for forays into the language of the users of the script. Good advice for the programmer, perhaps; but it should not be perl's job to enforce that discipline. Agreed, but neither should perl implement features which make it hard for the programmer to stick to that advice. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: RFC: multiline comments
John Porter wrote: Michael Mathews wrote: Using a two-character syntax to start and end a multiline comment seems to be a good way to satisfy both the desired similarity to "#" and the desired uniqueness to avoid collision with real single-line quotes. I would suggest a (# many lines of comment #) syntax: Nothing personal, but -- Barf. Very non-perlish, IMHO. qc( here's some text which will evaluate to "silent undef". ); I had much the same reaction to (# foo #). I would find qc( foo ) much more acceptable. We lose the "comments are always #" idea, but then there's other languages that have more than one character design used for comments. In the case of C/C++, # would map to //, and qc() would map to /* */. You can use either to simulate the other, but each has one or two things that it handles better than the other. On the other hand, the stated desire for this is for commenting out blocks of code. That might be more achievable with (I forget the right name for this) 'compile time directives' such as "#if", "#endif". We'd have to use a different opening syntax, since # is already taken for comments, but this might be of more general usefulnes than block comments. [I have a sneaking suspicion that this is another one of those 'hot topics'. I suspect that we could abuse pod to achieve the block comment effect, but that would clutter up the documentation rather badly.] E.W.
Re: RFC: multiline comments
Thus it was written in the epistle of Michael Mathews, Ted Ashton wrote: The qc() proposal fits in well with the Perl "look-and-feel" and seems pretty comfortable to me. If there are concerns about obfuscatory potential, a use strict 'comments' could require that the qc( opening start in column one. Further, if qc were flexible about delimiters, those who prefer /* */ could write qc/* Here is a comment */; I think this may be the closest thing to being What Will Make Everyone Happy, but I'm afraid it fails in two very major ways: 1) Perl can't currently handle quote delimiters of arbitrary length. In other words the asterisks would currently be treated as part of the quote, not part of the delimiter. Any idea how to overcome this? I've no intention of overcoming this :-). The delimiter above is the / and should be understood so. The * is a warm fuzzy for C programmers, but as it might lead the masses astray should probably be avoided. 2) Also this proposition fails in one of my goals, which was to allow arbitrary nesting of multiline comments. I believe this would be true for any function based solution. Negative. If you use paired delimiters you're ok. qc( Here's a quick comment which actually contains qc( another comment ) within it ); Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == I advise my students to listen carefully the moment they decide to take no more mathematics courses. They might be able to hear the sound of closing doors. -- Caballero, James == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC: multiline comments
Ted Ashton wrote:
2) Also this proposition fails in one of my goals, which was to allow
arbitrary nesting of multiline comments. I believe this would be true for
any function based solution.
Negative. If you use paired delimiters you're ok.
qc( Here's a quick comment which actually contains
qc( another comment )
within it
);
This type of comment will not comment out arbitrary text. In particular, it
might
have problems with text containing mismatched (){}. And yet using non-paired
delimiters doesn't allow commenting out comments. My ideas, which address both,
were in a concurrent-in-time posting to this one I'm replying to.
And the choice of a single-character delimiter is hard for this sort of muliline
comment for use in commenting out blocks of code, considering the line-noise
nature of perl source code. A multi-character delimiter seems imperative for
commenting out code, just as for here documents.
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
Re: RFC: multiline comments
Glenn Linderman wrote: $foo = $a + $b # can this be an in-line comment? # + $c * $d; Note that with this scheme it would be possible to allow in-line comments to be multi-line comments, or possible to prevent that. I'd vote in favor of keeping in-line comments on a single line. Note that with this scheme it would be possible to allow multi-line comments to start in the middle of a line, or possible to prevent that. I'd vote in favor of making them start as the first thing on the line. This seems like an acceptable variation on what has been suggested so far. I deally one would be able to safely block comment any large section of a Perl 6 script and not worry about any other block comments within (the outermost block comment takes precedence). So this should work in Perl 6 code here; # # this is a single line comment $foo = $a + $b # here's an in-line comment # + $c * $d; # more code here; It is however, also necessary to avoid accidental collision with single line comments or other perl syntax. For example this example (valid in perl5) could confuse a compiler looking for block comments. Don't see anyway around this sort of thing though. print qq#isome html here/i#; --Michael
Re: RFC: multiline comments
Glenn Linderman wrote:
qc( Here's a quick comment which actually contains
qc( another comment )
within it
);
This type of comment will not comment out arbitrary text.
In particular, it might have problems with text containing
mismatched (){}.
This is already an issue with the existing q.() operators --
which is to say, I don't think it's something we need to worry about.
That's not to say that we shouldn't have multi-char q.() delimiters;
being able to say qq({ }) might be nice, for example.
Also consider the impact of Unicode, which will allow any reasonable
pair of matching Unicode characters. I.e. instead of multi-char,
think wide-char.
And yet using non-paired
delimiters doesn't allow commenting out comments.
Since what I think this means is false, you probably mean
something else...
--
John Porter
Re: RFC: multiline comments
Michael Mathews wrote: So this should work in Perl 6 code here; # # this is a single line comment $foo = $a + $b # here's an in-line comment # + $c * $d; # more code here; If starting in column 1 is going to be magic, you may as well make the magic char #, so: # # this is a single line comment $foo = $a + $b # here's an in-line comment # + $c * $d; # And then, you may as well make it =, and use some meaningful verbiage instead of "" and "". So: =begin comment # this is a single line comment $foo = $a + $b # here's an in-line comment # + $c * $d; =end comment The pod solution is more or less obvious. Inlinable nestable comments are something else, and it should look like perl. qc() -- compiled to nothingness. -- John Porter
Re: RFC: multiline comments
This seems like an acceptable variation on what has been suggested so far. I
deally one would be able to safely block comment any large section of a Perl
6 script and not worry about any other block comments within (the outermost
block comment takes precedence).
I still like this solution prototype:
sub comment($) { }
comment "END OF FIRST COMMENT";
asdf
asdf
asdf
asdf
asdf
END OF FIRST COMMENT
--tom
Re: RFC: multiline comments
Proposal: here-docs specified with regexes, and no special meaning for newlines. comment /EOC/; this is an arbitrary comment. EOC Smack--the lexer cowers before you! --tom
Re: RFC: multiline comments
Tom Christiansen wrote: comment /EOC/; this is an arbitrary comment. EOC Smack--the lexer cowers before you! Well, hey, while we're daydreaming... :-) -- John Porter
Re: RFC: multiline comments
On Wed, Aug 02, 2000 at 03:00:04PM -0400, Michael Mathews wrote: Ted Ashton wrote: The qc() proposal fits in well with the Perl "look-and-feel" and seems pretty comfortable to me. If there are concerns about obfuscatory potential, a use strict 'comments' could require that the qc( opening start in column one. Further, if qc were flexible about delimiters, those who prefer /* */ could write qc/* Here is a comment */; I think this may be the closest thing to being What Will Make Everyone Happy, but I'm afraid it fails in two very major ways: 1) Perl can't currently handle quote delimiters of arbitrary length. In other words the asterisks would currently be treated as part of the quote, not part of the delimiter. Any idea how to overcome this? Well hey I am sure perl6 will allow scripts in utf8, so there are plenty of unused characters yet. Graham.
