Re: Perl 6 Wiki -- 2 more possibilities, further discussion.

2006-05-25 Thread Michael Mathews
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 link target: Consider using Subversion instead

Re: (Existing) Perl 6 Wiki: (http://perl.net.au/wiki/Perl_6)

2006-05-23 Thread Michael Mathews
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).

Re: RFC 102 (v1) Inline Comments for Perl.

2000-08-15 Thread Michael Mathews
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

Re: RFC 79 (v1) Code which is both executable and POD.

2000-08-09 Thread Michael Mathews
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

Re: RFC 79 (v1) Code which is both executable and POD.

2000-08-09 Thread Michael Mathews
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 documentation

Re: RFC 48 (v2) Objects should have builtin stringifying

2000-08-08 Thread Michael Mathews
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 # print out a

Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa

2000-08-08 Thread Michael Mathews
Graham Barr said: Would result in "25" being printed out. Here's why: 1. The C$x = 10 is automatically scoped with its own Cmy. 2. The C$x = 5 inside the Banonymous block is automatically scoped with its own Cmy. 3. The C$x = 25 code, however, inside the Cif

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Michael Mathews
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-argument one

MLC has its own sublist: WAS: Re: Recording what we decided *not* to do, and why

2000-08-07 Thread Michael Mathews
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

Treating filehandles like strings

2000-08-06 Thread Michael Mathews
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

Re: RFC 18 (v1) Immediate subroutines

2000-08-04 Thread Michael Mathews
=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 stream }; } I

Re: multiline comments

2000-08-02 Thread Michael Mathews
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: #EOC; some comments

Re: RFC: multiline comments

2000-08-02 Thread Michael Mathews
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

Re: multiline comments

2000-08-02 Thread Michael Mathews
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

2000-08-02 Thread Michael Mathews
tiansen" [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

Re: What is Perl?

2000-08-01 Thread Michael Mathews
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