ble as soon as possible?) If so, how much more
encouragement do you need to proceed?
> From: Michael Mathews [mailto:[EMAIL PROTECTED]
> As a competing suggestion, how about...
> http://pugs.kwiki.org/?perl6
Very interesting. But did you look at it? :-) I found this on the home page
lin
I for one, think a Perl6-users wiki would be extremely useful, I'm
just not sure why a site that distinguishes itself as "a portal for
the Australian and New Zealand Perl community" makes the most sense
(particularly to anyone trying to find the Perl6-users wiki from
outside this mailing list).
O
Kirrily Robert said:
> What relationship does this have to RFC 5 (multiline comments), and
> hasn't the discussion of inline comments occurred in detail already?
There is a distinction, because the proposal for multiline comments requires
(like all here docs) the opening and closing be on their o
Larry Wall said:
> John Porter writes:
> : So, are you saying that if this RFC is implemented, POD would be
> : an good way to comment code?
> It already is, as far as I'm concerned.
Please, if I'm missing something specific please explain it to me. But
here's what I can tell from the documentati
John Porter asked:
> Michael Mathews wrote:
> > This ... underlines why POD is not a good way to comment code. ...
> > This RFC would seem to address the issue quite neatly.
> So, are you saying that if this RFC is implemented, POD would be
> a good way to comment code?
From: "Perl6 RFC Librarian"
> This allows actual running code to be inserted directly into the
documentation
> for that code.
This (if I understand your aim here) points out The Difference between
comments and POD, and underlines why POD is not a good way to comment code.
Comments can always be
Bart Lateur said:
> So what are these really good for? To get rid of the line terminator, or
> "Record Separator", when reading from a file. That is what they are for,
> that is what we should facilitate. Not the chop()ping or chomp()ing of
> just any string.
>
> So, let's keep in tune with the R
Ted Ashton said:
> Thus it was written in the epistle of Uri Guttman,
> >
> > how do you tell the above two apart? by array do you mean only an array
> > variable? then you can't chomp a list of scalar values or multiple
> > arrays, etc.
> >
> > this needs to be clarified.
>
> Quite true. The two
Dan Sugalski said:
> > > * Do we even want to allow after-the-fact chomps, or do it
automagically
> >at read time?
> "Yes" is rather ambiguous.
To clarify: "Yes", we (I) want to allow after-the-fact chomps. As you
alluded to yourself there are times when you may want to chomp strings that
were no
Dan Sugalski said:
> Which brings up the questions:
>
> * What about scalars that didn't come from filehandles?
> * Should the chomp function use the filehandle's current separator, or the
> one in effect when it was read?
> * Do we even want to allow after-the-fact chomps, or do it automagically
Graham Barr said:
> > Would result in "25" being printed out. Here's why:
> >
> >1. The C<$x = 10> is automatically scoped with its own C.
> >
> >2. The C<$x = 5> inside the B block is automatically
> > scoped with its own C.
> >
> >3. The C<$x = 25> code, however, inside the C s
> In a scalar context, it could produce a date object always:
>
>$date = date;
>
> However, when you went to do anything with it in a string context, it
> would call the appropriate method:
>
>print "$date"; # calls $date->STRING, which in this case would
> # prin
John Porter said:
> that long post contained nothing that anyone
> reading perl6-language isn't already
> fully conscious of. At least, IMHO.
I admit I took artistic license with my point. I should have expected
programers to prefer short, logical statements (preferably ending with
semicolons).
Please post further MLC remarks to the MLC sublist:
[EMAIL PROTECTED]
I can't guarentee that any MLC comments posted under a different subject,
and on a different list will make it into the final Multiline Comments RFC!
Not to mention that this specific argument is already addressed in the
curre
Here's a thought. Wouldn't this be cool (see below)? The idea is that in
Perl 6 you should be able to read from a file handle one character or one
line at a time (just like you can in Perl 5) BUT if you just go ahead and
use the filehandle, directly, in a scalar context then perl will read it in
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
Snippet from O'Reilly's upcoming fictional novel, the first in a new series
written for its loyal audience of CS professionals:
"Young Perl had definitely reached that 'awkward stage' in life -- not quite
a fully-accepted adult, but definitely not a child anymore. Her parents,
/they/ loved her, sh
> =head1 EXAMPLES
>
> # multiline comments
>
> sub comment
> {
> return '';
> }
>
> use immediate 'comment';
>
> sub foo
> {
> # ...
> comment {
> this is a multiline comment;
> the call to comment is executed at parse time
> and returns an empty string that replaces
> the whole call in the parse
Larry Wall wrote:
> Note in particular that multi-line comments
> are something we *could* have added at any time, but chose not to.
> This means you're gonna have to argue a little harder for it than you
> would for something that wasn't possible before, but that we think
> might become possible
Jonathan Scott Duff said
> BTW, I propose that RFCs have a Status: field as part of the VERSION.
> Here are some possible values that I can see:
> Status: accepted # we all agree that it should go in
> Status: rejected # we all agree that it shouldn't go in
> Status: tabled # shelved
Steve Simmons explained
> >
> > IMHO someone should write an RFC on why perl6 should NOT have
> > comments. The RFC editor doesn't have time to follow these zillions
> > of discussions and write documents based on them.
>
> Ooog, horrible phrasing on my part. That should read ``the editor
> of t
Nathan Torkington said
> Steve Simmons writes:
> > This idea is both important and more general. If we go thru a huge
> > discussion of, say, multi-line comments and decide *not* to do it,
> > we don't want to have the whole thing repeated with perl 6.1, 7.0,
> > etc, etc. When something reaches
BTW: the correct link is http://tmtowtdi.perl.org/lists.shtml (note the
"shtml") to see and subscribe to sublist.
--Michael (who won't be discussing that MLC thing here anymore, I promise)
- Original Message -
From: "Michael Stevens" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wedn
quot;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?
2) what if the bloack contains unmatched braces?
3) this is not easier to type or remember than the currently available
workarounds.
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:
> 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
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
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:
#<
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
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
On Tue, 1 Aug 2000 23:43:24 -0500, Jonathan Scott Duff <[EMAIL PROTECTED]>
wrote:
> (I, for one, support renaming local() to Something Better (if only I
> know what that was))
how about clone()?
Okay, I'm impressed. 108 messages in my box this morning from the list. Shows spunk.
But I'm concerned. Are you getting enough sleep?
--Michael
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
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
>
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
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
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 /#
--Michael
As far as Perl being an offspring of Unix I think that's great if it is in
meant **in spirit**. But any opportunity for Perl6 can make things more
understandable to the average programmer vs. the average Unix user should be
taken advantage of. The "unlink()" example is a good one. Now that Perl is
40 matches
Mail list logo
