Re: Multiple for loop variables

On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote: > Peter Scott wrote: > >Graham Barr once allowed as how he thought it would be neat if you could say > > > > for my($x, $y, $z) (@list) { ... } > > ObLanguageMinimalist: > > Um. Is this so frequently-used that the above syntax is pr

Re: RFC 122 (v1) types and structures

This is a bit limiting. I'd offer a more flexible approach. We should be able to represent any packed structure. We should be able to handle anything that an pack/unpack format can currently handle. Except that the data does not have to be moved out into an array/hash. This might fit in with t

Re: New match and subst replacements for =~ and !~ (was Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.)

"Randy J. Ray" wrote: > > ># These are pretty cool... > >foreach (@old) { @new = subst /hello/X/gi, @old; > > s/hello/X/gi; > > push @new, $_; > >} > > > This implies that the subst keyword would *both* modify LIST in-place and > return a complete copy of t

Re: New match and subst replacements for =~ and !~ (was Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.)

> Just to extend this idea, at least for the exercise of it, consider: > >match; # all defaults (pattern is /\w+/?) >match /pat/;# match $_ >match /pat/, $str; # match $str >match /pat/, @strs; # match any of @strs > >subst; # like s///, pre

Re: RFC 168 (v1) Built-in functions should be functions

>Well, as I mentioned in another recent parallel thread, if C is to >be properly functionalized, Whoa -- why? Syntax keywords (eg if, unless) certainly need not be expressible as functions.This isn't tcl! --tom

Re: Nice to have it

On Mon, 28 Aug 2000 14:43:08 -0400 (EDT), Eric Roode wrote: >Damian Conway wrote: > >> @hash{grep /^[^_]/} >> >>gives you the public values of %hash. > > >And the advantage of that over > >@hash{ grep /^[^_]/, keys %hash } > >would be what? Brevity? What if I want those keys of %has

Re: Beefier prototypes (was Re: Multiple for loop variables)

On Mon, Aug 28, 2000 at 04:04:20PM -0400, John Porter wrote: > Well, I think it's likely that the perl6 parser would be made to > handle this; but even if not, it shouldn't be too hard to get it > to allow a ref to such a list: > > for [ $x, $y, $z ] ( @list ) { ... I'm wondering how we ge

Re: Nice to have'it

Damian Conway wrote: > I have a draft RFC that proposes that the LIST argument of a > grep be optional in a hash slice, and default to the key list > of the sliced hash. So: That's a waste of RFC paper, Damian. But let's generalize it a bit, and say that Perl6 should have a standard intrinsic

Re: Multiple for loop variables

Peter Scott wrote: >Graham Barr once allowed as how he thought it would be neat if you could say > > for my($x, $y, $z) (@list) { ... } ObLanguageMinimalist: Um. Is this so frequently-used that the above syntax is preferable to: while ( ($x, $y, $z) = splice (@list, 0, 3) ) {...} ?

Re: RFC 168 (v1) Built-in functions should be functions

Damian Conway wrote: >> I think it would be a good thing for user prototypes to be able to >> handle this case and I wholeheartedly support the RFC; but it opens >> a can of worms that should be addressed. Perhaps in another RFC. Do >> any other (Damian) RFCs on (Damian) prototypin

Beefier prototypes (was Re: Multiple for loop variables)

Peter Scott wrote: > > for my($x, $y, $z) (@list) { ... } > ... > IANAPE (I Am Not A Parsing Expert). So I thought I would see if anyone who > was could say whether this construct would really give the parser problems > or whether looking ahead for the block will disambiguate. Well, I t

Re: RFC 168 (v1) Built-in functions should be functions

> I think it would be a good thing for user prototypes to be able to > handle this case and I wholeheartedly support the RFC; but it opens > a can of worms that should be addressed. Perhaps in another RFC. Do > any other (Damian) RFCs on (Damian) prototyping impact (Damian) > this a

Re: Nice to have it

> And the advantage of that over > > @hash{ grep /^[^_]/, keys %hash } > > would be what? Brevity? Yes. Damian

Re: Nice to have it

Damian Conway wrote: >I have a draft RFC that proposes that the LIST argument of a >grep be optional in a hash slice, and default to the key list >of the sliced hash. So: > > @hash{grep /^[^_]/} > >gives you the public values of %hash. And the advantage of that over @hash{ grep /^[^

Re: RFC 126 (v2) Ensuring Perl's object-oriented future

On 8/28/00 2:35 PM, Tom Christiansen wrote: >> Object-oriented features were added to Perl with version 5, and in many >> ways still appear somewhat "tacked on", with perhaps undue respect >> for the Old Ways of Perl 4. > > [NB: This is not a serious missive.] > > Hey, that Perl uses packages fo

Re: Do we really need eq?

Steve Simmons wrote: > > IMHO the code > > $a = '3.14'; # from reading a file > $b = '3.1400'; # from user input > if ($a == $b) { ... } > > should see the two args being tested in numeric context, do the numeric > casting, get floats, and do a floating compare. Durned if I know wh

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

My apologies for being too succinct. "lost" is a bit of an emotive word which is somewhat inaccuracte. I still believe in RFC 109 and I think I made a good case based on my own reasons. However the overwhelming majority of responses were negative, for their own very good albeit different reasons

Re: Nice to have'it

> Well, $hash{/re/} would only evaluate to a single scalar. > More likely, you'd want @hash{/re/}, which would be > equivalent to @hash{ grep { /re/ } keys %hash }. I have a draft RFC that proposes that the LIST argument of a grep be optional in a hash slice, and default to the key li

Re: RFC 126 (v2) Ensuring Perl's object-oriented future

>Object-oriented features were added to Perl with version 5, and in many >ways still appear somewhat "tacked on", with perhaps undue respect >for the Old Ways of Perl 4. [NB: This is not a serious missive.] Hey, that Perl uses packages for classes, subroutines for methods, and references for o

Re: RFC 168 (v1) Built-in functions should be functions

At 07:32 PM 8/27/00 +, Perl6 RFC Librarian wrote: >=head2 Prototypes > >Currently, several built-ins do not provide prototype information. > > prototype("CORE::abs") ==> ;$ > prototype("CORE::shift") ==> undef > >This must be fixed. One might even call this a bug, although the >cur

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

On Mon, Aug 28, 2000 at 05:39:20PM -, Perl6 RFC Librarian wrote: > =head1 TITLE > > Less line noise - let's get rid of @% ... > I withdrew it on 28th August as I figured I had lost the > argument! I'm sorry, but this just doesn't jive with me. There is no "argument". We are discussing pro

Re: HERE construct

Steve Simmons wrote: >In all the straining at gnats over whitespace, filtering, etc, I have yet >to see a single proposal that isn't accomplished by just using variables >and manipulating them appropriately. And it avoids all the problems with >whitespace on the HERE word. In many cases, I agree

HERE construct

General comment on all the discussion of HERE docs. When HERE docs cause you a problem, don't use 'em. There is little win if any over print << HERE; Dear Sir: You owe me bucks. Pay up. Me. HERE and $msg = 'Dear Sir: You owe

RFC 126 (v2) Ensuring Perl's object-oriented future

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Ensuring Perl's object-oriented future =head1 VERSION Maintainer: John Siracusa <[EMAIL PROTECTED]> Date: Aug 16 2000 Last Modified: Aug 28 2000 Version: 2 Mailing List: [EMAIL PROTECTED

Multiple for loop variables

Graham Barr once allowed as how he thought it would be neat if you could say for my($x, $y, $z) (@list) { ... } i.e., more than one loop variable, assigned successively from the list. He didn't have time to RFC it, but when I looked at it, a problem arose: if the loop variables aren't

Re: RFC 143 (v1) Case ignoring eq and cmp operators

On Thu, Aug 24, 2000 at 03:40:00PM -, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Case ignoring eq and cmp operators IMHO this problem is better solved by using =~ and its brethren, which already allow you to

RFC 133 (v2) Alternate Syntax for variable names

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Alternate Syntax for variable names =head1 VERSION Maintainer: David Corbin <[EMAIL PROTECTED]> Date: 20 Aug 2000 Last Modified: 28 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Number: 13

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

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Less line noise - let's get rid of @% =head1 VERSION Maintainer: Karl Glazebrook <[EMAIL PROTECTED]> Date: 15 August 2000 Last Modified: 28 August 2000 Version: 2 Mailing List: [EMAIL PROTECTED]

Re: Do we really need eq?

I'd like to see eq and it's brethen retained, as dammit there are times I want to know (-w) if numbers are turning up when there should be words and vice-versa. However, spinning off of something Randal wrote: > Yes, but what about: > > $a = '3.14'; # from reading a file > $b =

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)

>> Next you'll propose that >> >> print <> blah >> EOL; print "OK!\n"; >> >> should work too, and print "OK!\n" as well. >> >Yes why not, though it might be bad style. Because it gains you nothing, and loses much. --tom

Re: RFC 162 (v1) Filtering Here Docs

On Mon 28 Aug, Bart Lateur wrote: > On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: > > >It only removes whitespace, > >and it measures whitespace with tabs=8. > > My editor is set to tabs=4. Perl's interpretation wouldn't agree with > the visual appearance in my editor. This doesn't s

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)

On Mon 28 Aug, Bart Lateur wrote: > On Mon, 28 Aug 2000 10:38:42 -0400 (EDT), Eric Roode wrote: > > >People may throw rocks at me for this, but I'd like to suggest that > >not only is a comment allowed on the terminator line, but a semicolon > >also be allowed. Vis: > > > >print < >EOL;

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)

On Mon 28 Aug, Eric Roode wrote: > Richard Proctor proposed: > > > > All of these should work: > > > > print < >EOL > > print << EOL; > > EOL > > print < >EOL # this is the end of the here doc > > People may throw rocks at me for this, but I'd like to suggest that

Re: Nice to have'it

David Corbin wrote: > raptor wrote: > > > > $hash{/re/} i.e. this is the same like > > > > my @res; > > foreach my $k (keys %hash) > > { > > if ($k =~ /re/) {push $hash{$k},@res} > > }; > > > > OR > > keys %hash{/re/} > > values %hash{/re/} > > each %hash{/re/} > > Way cool. I'd love this

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)

>Bart Lateur wrote: >> >> Next you'll propose that >> >> print <> blah >> EOL; print "OK!\n"; >> >> should work too, and print "OK!\n" as well. >Why not?! This seems like a good thing. ;, #, or \n are all valid >end-of-lines for here string delimiters. Sounds easy enough

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)

On Mon, 28 Aug 2000 08:46:25 -0700, Nathan Wiger wrote: >> OTOH, what about this... >> >> print <> blah >> EOL; >> >> which makes this a full blown statement (note the missing semicolon in >> the first line)... > >No it doesn't! > >perl -e ' > print < Hello world! >E

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)

Bart Lateur wrote: > > Next you'll propose that > > print < blah > EOL; print "OK!\n"; > > should work too, and print "OK!\n" as well. Why not?! This seems like a good thing. ;, #, or \n are all valid end-of-lines for here string delimiters. Sounds easy enough, and consi

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)

On Mon, 28 Aug 2000 10:38:42 -0400 (EDT), Eric Roode wrote: >People may throw rocks at me for this, but I'd like to suggest that >not only is a comment allowed on the terminator line, but a semicolon >also be allowed. Vis: > >print

RE: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

>By the way, for all you thesis writers and thesis advisors out there -- I >suspect that a separate implementation of the Perl6 lexer and/or Perl6 >parser might make a dandy thesis topic... By the way, this message makes more sense if you s/a separate/an independent/... :( > =

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)

Richard Proctor proposed: > > All of these should work: > > print print << EOL; > EOL > print

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)

Bart Lateur <[EMAIL PROTECTED]> writes: > On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: > > >Further it should ignore any whitespace (and comments) that follow the > >terminator. > > > All of these should work: > > > print < >EOL # this is the end of the here doc > >

Re: RFC 162 (v1) Filtering Here Docs

On Mon, 28 Aug 2000 09:11:39 -0400, David Corbin wrote: >Why not make the details of this controlled by a pragma? TMFP Too Many Pragma's. We're trying to write ONE language here, not 150. Depending on what pragmas you're used to, you can no longer read, er, understand, other people's c

RE: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

> > Do we have an RFC yet that proposes Perl to be easier parsable? > > Damian? > >Working on it. By the way, for all you thesis writers and thesis advisors out there -- I suspect that a separate implementation of the Perl6 lexer and/or Perl6 parser might make a dandy thesis topic... ===

Re: RFC 162 (v1) Filtering Here Docs

>On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: >>It only removes whitespace, >>and it measures whitespace with tabs=8. >My editor is set to tabs=4. So don't do that. :set sw=4 ts=8. I am confident that were Dante were writing now, he'd reserve a special pit of Hell for those who

Re: Nice to have'it

raptor wrote: > > Hi, > > I have couple of ideas which may or may not worth it, so I didn't > wrote the RFC but will list them here in short. > Here are the nice to have'it. > > 1. There will be good to have some sort of "match and/or assign" operator > for structures i.e. HASHES. Can't still f

Re: Let's have a Standard for Module Configuration

While I think it is reasonable that all such configuration parameters be changeable by an API, there is clearly a place for system defaults. I've run across two such modules that I know. One wanted you to set the time-zone the system was running in, and the other was to set a default SMTP server

Re: RFC 162 (v1) Filtering Here Docs

Bart Lateur wrote: > > On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: > > >It only removes whitespace, > >and it measures whitespace with tabs=8. > > My editor is set to tabs=4. Perl's interpretation wouldn't agree with > the visual appearance in my editor. This doesn't sound like a

Re: RFC 133 (v1) Alternate Syntax for variable names

Bron Gondwana wrote: > > In [EMAIL PROTECTED], you wrote: > > count = array; # scalar context because of assignment to > > scalar. > > alt_array[] = array; # list context > > and if array is a subroutine? > >count = array(); >count = &array; # warning - special mean

Re: Nice to have'it

Hey Raptor et al: Wow you did some homework! Nice ideas, but the consensus seems to be "roll your own". I've noted that opertors working on arrays are generally discouraged in favor of scalar ops in these discussions, so for example your (min,max) (ceiling, floor) are coded thousands of times

Re: RFC 76 (v1) Builtin: reduce

Lightning flashed, thunder crashed and "Ed Mills" <[EMAIL PROTECTED]> whispe red: | So we establish a var $something=n where n is the array origin. You mean something like $[, which we've had for many, many years. And which for many, many years we've discouraged the use of? $[ The i

Nice to have'it

Hi, I have couple of ideas which may or may not worth it, so I didn't wrote the RFC but will list them here in short. Here are the nice to have'it. 1. There will be good to have some sort of "match and/or assign" operator for structures i.e. HASHES. Can't still figure out the syntax but may be i

Re: Let's have a Standard for Module Configuration

That could be very nice. I would really prefer changing parameters through the API, by calling class functions or something, but I don't see why everyone should agree with me. Keeping source-editable parameters in a standard place would then be a win, especially considering your thoughts about

Re: RFC 162 (v1) Filtering Here Docs

On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: >It only removes whitespace, >and it measures whitespace with tabs=8. My editor is set to tabs=4. Perl's interpretation wouldn't agree with the visual appearance in my editor. This doesn't sound like a neat solution. Why not disallow mer

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)

On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: >Further it should ignore any whitespace (and comments) that follow the >terminator. > All of these should work: > print

Automated "no status" messages

I've just run a nasty hairy script over the RFC repository and sent email to those people who I think have language RFCs but haven't put statuses on them yet. My aim in this is to figure out which RFCs are still actively under discussion and which aren't. Some people haven't updated their RFCs

Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

On Mon, 28 Aug 2000 14:22:03 +1100 (EST), Damian Conway wrote: > > I don't get it. What makes it so hard? If you see a "/" when you're > > expecting an operator, or end of statement, then it's division. If you > > were expecting an expression, it's a regex. Ain't it? > >Yes. And that's what