RE: What will be the Perl6 code name ?!!

2000-10-19 Thread Mike Pastore
On Thu, 19 Oct 2000, Garrett Goebel wrote: > The only acceptable code name other than "Perl6" is "YACN" ;) > What's that? You Actually Cannot Tell? Yes, All the Code is New? Yet Another Crazy Notion? -- Mike Pastore

Re: Perl6Storm: Intent to RFC #0101

2000-09-27 Thread Mike Pastore
quot;Line break after this string". $OLS; /^[A-Z]{3,6}/ && { $v = sca rev $MTC }; And they thought Perl was unreadable before... just wait 'til they get a load of this! -- Mike Pastore #!Perl Monk [EMAIL PROTECTED] bilogic.org Sys Admin

Re: McNamara's C<$#> as a property of any array element

2000-08-17 Thread Mike Pastore
ast index, 4) maybe others? $#ARY could be depreciated (another "confusing" special variable bites the dust) and we would have a whole lot more detail regarding arrays during array ops. Any thoughts on this? -- Mike Pastore [EMAIL PROTECTED]

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread Mike Pastore
gs>, because from a "birds-eye view" a programmer would see the C<@> and move to the next line, not pausing to read all the way through to see that C is obviously plural. Again, I refer you to Dan Sugalski's message about this. > You are asking wrong/unnecessary questions, and getting wrong answers. That was disturbingly Zen. ;-) -- Mike Pastore [EMAIL PROTECTED]

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread Mike Pastore
On Wed, 16 Aug 2000, David Corbin wrote: > Mike Pastore wrote: > > > $hashish{'dog'}# one whutzit > > @hashish{'dog', 'cat'} # more than one whutzits > > each %hashish # one whutzit, indexed > > %hashish

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread Mike Pastore
x27;m trying to make is that the contextual clues (@$%) don't tell you what IT is, but what you're getting from IT. That's what's so important. Take this away and Perl becomes C. int a; struct b; *cough* No, thank you. -- Mike Pastore [EMAIL PROTECTED]

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-15 Thread Mike Pastore
about decreasing line noise. :) Maybe not about making Perl 6 extensible for future struct types, but line noise indeed... Please excuse the silly example. -- Mike Pastore [EMAIL PROTECTED] PS - my @foo = ('apples', 'oranges'); my %bar = ('apples' => 'crunch

Re: RFC 83 (v1) Make constants look like variables

2000-08-12 Thread Mike Pastore
w Klingon.pm to Perl 6. $pkg'var! $det'yiu! -- Mike Pastore [EMAIL PROTECTED]

Re: RFC 91 (v1) Builtin: partition

2000-08-11 Thread Mike Pastore
e determinate, multiplying matrices, adding matrices, etc. It almost sounds like it needs it's own struct type. Between this an HOFN (higher-order function notation), it sounds like Perl is starting to become much more math oriented! Maybe they'll start teaching Perl 6 instead of Fortran for CS300, hmm? -- Mike Pastore [EMAIL PROTECTED]

Re: RFC 90 (v1) Builtins: zip() and unzip()

2000-08-11 Thread Mike Pastore
On Fri, 11 Aug 2000, Brad Hughes wrote: > Andy Wardley wrote: > > > fold() and unfold()? > > > > merge() and cleave()? > > collate() and ...? > Sure, and if it throws an exception you get a papercut().

Re: RFC 83 (v1) Make constants look like variables

2000-08-11 Thread Mike Pastore
# mutable key :Birthday => '08/15' ); what about: $!foo = 'immobile';# mnemonic, NOT as in NOT change $'bar = 'unchanging'; # klingon? $.zot = 'static'; Foo for thought. -- Mike Pastore [EMAIL PROTECTED]

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

2000-08-10 Thread Mike Pastore
tring, and an integer. Well, I suppose that takes care of the typing issue. Nice work. -- Mike Pastore [EMAIL PROTECTED]

Re: RFC 83 (v1) Make constants look like variables

2000-08-10 Thread Mike Pastore
to be made constant, simply because they're CONSTANT and unchanging. One more thing: Does the 'constant' refer to the hash (ie, the ability to add and delete items) or to the individual data elements? Darn typing!! Darn constants!! -- Mike Pastore [EMAIL PROTECTED]

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-08 Thread Mike Pastore
On Wed, 9 Aug 2000, Ken Fox wrote: > Dan Sugalski wrote: > > The number of different vtables needed to deal with this (along with > > the functions in those tables) is rather formidable, and it will tend > > to impact performance. > > Hey! That sounds like an implementation topic... ;) (The inte

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-08 Thread Mike Pastore
Perl++ as a name for the language, instead of Perl6. :) -- Mike Pastore [EMAIL PROTECTED]

Re: Things to remove

2000-08-08 Thread Mike Pastore
Perl++ :) On Tue, 8 Aug 2000, Bryan C. Warnock wrote: > On Tue, 08 Aug 2000, Bennett Todd wrote: > > > If perl6 substantially fails to fill the important roles that perl5 > > fills, we should stop screwing everybody up by calling it "perl", > > and call it something else. > > Hmmm. I vote fo

Re: RFC 58 (v1) C changes.

2000-08-08 Thread Mike Pastore
$fh->chomp(0); # off, default $fh->chomp(1); # on, use system newline as chomp $fh->chomp('\r\n'); # on, use alternative Hmm.. methinks this is starting to look unperlish. -- Mike Pastore [EMAIL PROTECTED]

Re: RFC 58 (v1) C changes.

2000-08-08 Thread Mike Pastore
econd parameter as a list (ie, @ary = <$fh>), and unfolds it into a for loop, as such: for(@to_be_chomped) { $_ =~ s/$regexp//; } return want(); # etc I hope I'm being clear. :-P On Tue, 8 Aug 2000, Mike Pastore wrote: > On Tue, 8 Aug 2000, Ted Ashton wrote: > > >

Re: RFC 58 (v1) C changes.

2000-08-08 Thread Mike Pastore
On Tue, 8 Aug 2000, Ted Ashton wrote: > > Quite true. The two-argument one is new to me and I hadn't thought much > about it. Do you have a suggestion? Hmm, chomp { /\r\n/ } @chomp_me; ala p5 map, grep, and sort? -- Mike Pastore [EMAIL PROTECTED]

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-06 Thread Mike Pastore
his smacks of closure and other anonymous-subroutine related issues. Maybe I'm drifting off topic. Maybe I'm covering ground that's been trod before. In any case, I'd like to hear what you guys think about this. Especially Damian, because he's the poor sap writing the RFC. :-P -- Mike Pastore [EMAIL PROTECTED]

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-06 Thread Mike Pastore
Ken Fox wrote: > > > - ^foo is the placeholder 'foo' > > That already has perfectly good meaning: XOR with the function foo(). Good point. Back to the drawing board? > > Although, I suppose '&' would not work. > > Why not? I think it would work great. Well, what's the different between the p

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-06 Thread Mike Pastore
. Or even a thumbtack, holding the variable down to be filled in at a later time. Mnemonics galore! My goodness, what have we done. :) Henceforth being seen and not heard (at least for a bit), Mike Pastore [EMAIL PROTECTED]

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-06 Thread Mike Pastore
in (a placeholder, in fact!). Just as simply, - $foo is the variable 'foo' - ^foo is the placeholder 'foo' - $_ is the default variable - ^_ is the default placeholder Or any variation, given Nathan Wiger's original list (! ^ &) and others. Although, I suppose '

Re: RFC 24 (v1) Semi-finite (lazy) lists

2000-08-05 Thread Mike Pastore
e're going to do THAT, why not predeclare functions (or static lists) of different mathematical terms, like the set of all real numbers, the set of all natural numbers, the set of integers, etc.? No sense in mangling the .. operator (not to mention the anonymous array reference) to suit a specific purpose like that. -- Mike Pastore [EMAIL PROTECTED]

Re: RFC: multiline comments

2000-08-05 Thread Mike Pastore
CTED]) <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]