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
Jarkko Hietaniemi said
> What's wrong with stealing from C/C++/Java instead
> of trying to invent our own?
>
> In other words, what's wrong with /* ... */?
For one thing this would break (looking for zero or many slashes, x, y and
zero to many zs):
if (/\/*xyz*/) { ... };
Perl has gotten its
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 o
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
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
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/
#
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:
#<# variations just don't seem "perlish" to me. Sorry!
That's just a personal feeling.
If you just have to g
John Porter writes:
| qc( here's some text which will evaluate to "silent undef". );
|
| Could be very much like qw(), in the sense that
|
| % perl -w
| qc{
| once upon a time
| # now for the clincher
| happily ever after.
| };
| Possible attempt to put comments in
John Porter wrote:
> Glenn Linderman wrote:
> >
> > Agreed, but neither should perl implement features which make it hard for the
> > programmer to stick to that advice.
>
> That sounds reasonable, on first take, but actually I think that
> goes against the grain of perl's philosophy, which is to
Glenn Linderman wrote:
>
> Agreed, but neither should perl implement features which make it hard for the
> programmer to stick to that advice.
That sounds reasonable, on first take, but actually I think that
goes against the grain of perl's philosophy, which is to let the
programmer do what she
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 discipl
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
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 fr
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 q
>Tom Christiansen wrote:
>> > comment <>
>> Smack--the lexer cowers before you!
>Well, hey, while we're daydreaming... :-)
I suppose I should have written
The lexer misses!
You hit--More--the lexer cowers before you.
--tom
Tom Christiansen wrote:
> > comment <
> Smack--the lexer cowers before you!
Well, hey, while we're daydreaming... :-)
--
John Porter
>Proposal: here-docs specified with regexes, and no special
>meaning for newlines.
> comment <
Tom Christiansen wrote:
>
> I still like this solution prototype:
>
> sub comment($) { }
>
> comment <<"END OF FIRST COMMENT";
> asdf
> asdf
> asdf
> asdf
> asdf
> END OF FIRST COMMENT
So do I. Actually, here-docs can be a bit unwieldy, what with the
requirement for the e
>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 pro
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:
#<
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 alre
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 actu
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.
>
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 ac
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
Edwin Wiles wrote:
> 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
Michael Mathews 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.
>
> For example, this should be okay but I don't see how it could:
>
> 1qc/*
> 2
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 delimi
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.
I think qc() should be allowed to look l
Thus it was written in the epistle of Michael Mathews,
> If don't think multiline comments are worthwhile, then we should leave it
> out. But I don't see the point in arguing that a functionality should be
> kept out of the language because it can be added to the Text-Editing
> software!!
Agreed
If don't think multiline comments are worthwhile, then we should leave it
out. But I don't see the point in arguing that a functionality should be
kept out of the language because it can be added to the Text-Editing
software!!
I am not really arguing about single-line comments anyway. We all kno
>Johan Vromans writes:
>>Well, my editor has no problems to put #'s in front of a section of
>>lines, nor to remove them.
>Not every editor does this. Perl is supposed to be flexible and make things
>easy. It is not more flexible nor easier to require a programmer to use a
>certain type of editor
Johan Vromans writes:
>Well, my editor has no problems to put #'s in front of a section of
>lines, nor to remove them.
Not every editor does this. Perl is supposed to be flexible and make things
easy. It is not more flexible nor easier to require a programmer to use a
certain type of editor.
I d
"Michael Mathews" <[EMAIL PROTECTED]> writes:
> Unlike many programming languages Perl does not currently implement true
> multiline comments. This can be confusing/tedious to programmers.
I fail to see this. What is confusing?
As has been pointed out earlier, with multi-line comments like in C
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 (# man
On Tue, 1 Aug 2000, John Barnette wrote:
> Michael Fowler wrote:
> > On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote:
> > > Unlike many programming languages Perl does not currently implement true
> > > multiline comments. This can be confusing/tedious to programmers. This could
>
Michael Fowler wrote:
> I'm not sure exactly what you consider to be a "true multiline comment", but
> Perl definitely has them by my definition.
>
> =pod
>
> Hi, this is a multiline comment.
>
> =cut
...and there are a lot WORSE ways to do this in current Perl:
sub multiline-comment {}
mul
al Message -
From: "Michael Fowler" <[EMAIL PROTECTED]>
Sent: Tuesday, August 01, 2000 6:15 PM
Subject: Re: RFC: multiline comments
On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote:
> Unlike many programming languages Perl does not currently implement true
>
Michael Fowler wrote:
> On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote:
> > Unlike many programming languages Perl does not currently implement true
> > multiline comments. This can be confusing/tedious to programmers. This could
> > be solved by adding a syntax to Perl 6 that wou
On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote:
> Unlike many programming languages Perl does not currently implement true
> multiline comments. This can be confusing/tedious to programmers. This could
> be solved by adding a syntax to Perl 6 that would allow for true multiline
>
John Porter wrote:
> qc( here's some text which will evaluate to "silent undef". );
> Could be very much like qw() ...
Cool, I like the perlishness of your proposal. But not so sure about "qc".
Would this be a function? Why would it be a function? What would qc imply,
"quote comment"? This is co
Michael Mathews wrote:
>
> =head2 Proposal
>
> 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
Okay, so no one seemed to be offended at my original post/suggestion -- must
mean I should try to take it a little further :)
Here's the RFC in POD even.
--Michael
=head1 TITLE
Multiline Comments for Perl.
=head1 VERSION
Maintainer: Michael J. Mathews <[EMAIL PROTECTED]>
Date: 01 Aug 20
43 matches
Mail list logo
