On RFC 88: Serendipity while throwing a string.

I have been working on the Perl 5 reference implementation of RFC 88 functionality (Try.pm, which is currently available at: http://www.avrasoft.com/perl6/try6-ref5.txt ), and I stumbled across the following result. If you are writing some code, and there is a "throw" subroutine in scope, and the

Re: RFC 159 (v1) True Polymorphic Objects

Summary: I think these should all simply break down into a single Boolification test of some sort, as occurs already with operator overload. >LOGHIGHAND Called in && context >LOGHIGHOR Called in || context >LOGLOWAND Called in and context >LOGLOWOR Called in or context >LOGIFE

Re: RFC 161 (v2) OO Integration/Migration Path

I've read over 161 again and I'm starting to see areas where I can clarify things greatly. I apologize for the confusion. I'll make mods to the RFC in the near future, after I get more feedback from you all. Here are my goals as they probably should have been stated in the RFC: - Concentrate re

Re: RFC 161 (v2) OO Integration/Migration Path

On Sun, 27 Aug 2000 06:14:00 -0700, Matt Youell wrote: >So an int gets stored as two bytes and not >four or eight. Gee, I thought it was more like 30. The savings in bytes don't look too impressive in this case. 4 byte addition is as fast as 2 byte addition on most pmodern platforms -- and you

Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()

On Sun, Aug 27, 2000 at 07:29:33PM -, Perl6 RFC Librarian wrote: > This RFC proposes that C and C be dropped from the language > altogether, and instead be replaced with new C and C > builtins, with the following syntaxes: > >$res = match /pattern/flags, $string >$new = subst /pattern

Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes

Nathan Torkington wrote: > > Damian Conway writes: > >> sub foo :lvalue { $foo } > >> post foo { die if $foo == 5 } > >> > >> eval { > >> foo() = 5; > >> }; > > > > Postconditions on lvalue subs are not tested until the end of the complete > > expression in whi

Re: RFC 120 (v2) Implicit counter in for statements, possibly $#.

On Thu, Aug 17, 2000 at 08:46:53PM -, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Implicit counter in for statements, possibly $#. Having read over the entire discussion, I want to make a few comments and thr

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

Re: RFC 161 (v2) OO Integration/Migration Path

Dan Sugalski wrote: > > If the vtable stuff goes into the core perl engine (and it probably will, > barring performance issues), then what could happen in the > > my Foo $bar; > > case would be that all the vtable functions for Foo are taken as specially > named subs/methods in the Foo packag

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

Damian Conway wrote: > > I wouldn't be averse to C as the default and C as a sop to > the Cerites and C<$ME>ophiles. But *they* might be! This is baloney. I agree, we need to *pick something*!! What should we do, make a "rename" pragma so everyone can be happy? use rename want => '$NEED', && =

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

On Sun, Aug 27, 2000 at 07:54:35PM -0700, Nathan Wiger wrote: > And why is passing $self in $_[0] a good thing? Because it eliminates a butt-load of translation to convert Perl5 programs to Perl6 programs. Rather than tracking down each and every sub and figuring out if it's used as a method o

RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

Damian Conway: > My forthcoming proposal will be that invocants still be passed as $_[0] > by default, but that there be a pragma allowing $_[0] to be automagically > shifted somewhere else during dispatch. For example: > > > sub method { print "I was called through: $_[0]"; >

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

Nathan Torkington wrote: > > David L. Nicol writes: > > Any subroutine declaration, for instance > > > > sub Cmp:infix($$){ > > return uc($_[0]) cmp uc($_[1]) > > }; > > > > implicitly sets up a "catch unknown-keyword:Cmp" routine; that is, > > it installs the name of th

Re: RFC 130 (v4) Transaction-enabled variables for Perl6

dLux wrote: > > /--- On Thu, Aug 24, 2000 at 12:30:25PM -0400, John Porter wrote: > | > Still not good. "trans" is too overloaded word. "transaction"? > | > "transactional"? (a bit too long...) "atomic"? > | > | "acid"? > \--- > > "transactional" and "transaction" are quite long, I don't like th

Re: RFC 130 (v4) Transaction-enabled variables for Perl6

> Or what about a variable attribute: > > my $x : transactional > > and making the effect completely lexical? Why would other scopes need to > see such variables? Hear, hear! We do not want zillion and a half new keywords now that we have attributes. -- $jhi++; # http://www.iki.fi/jhi/

RFC 155 (v2) Remove mathematic and trigonomic functions from core binary

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Remove mathematic and trigonomic functions from core binary =head1 VERSION Maintainer: Stephen P. Potter <[EMAIL PROTECTED]> Date: Aug 24 2000 Last Modified: Aug 28 2000 Version: 2 Mailing List: [

Re: RFC 130 (v4) Transaction-enabled variables for Perl6

At 12:19 PM 8/28/00 -0500, Jarkko Hietaniemi wrote: > > Or what about a variable attribute: > > > > my $x : transactional > > > > and making the effect completely lexical? Why would other scopes need to > > see such variables? > >Hear, hear! We do not want zillion and a half new keywords now that

Re: RFC 161 (v2) OO Integration/Migration Path

Nathan Torkington <[EMAIL PROTECTED]> writes: >Dan Sugalski writes: >> If the vtable stuff goes into the core perl engine (and it probably will, >> barring performance issues), then what could happen in the > >I have a lot of questions. Please point me to the appropriate place >if they are answer

Re: multidim. containers

Dan Sugalski wrote: > > > >I'm thinking that a n-dim array could just be a list of lists (of lists of > >lists of...) with the n-dim notation just being syntactic sugar (and perhaps > >helping with optimisation too). > > If you want efficiency, n-dimensional arrays really need to be a concrete >

RE: RFC 146 (v1) Remove socket functions from core

Fisher Mark <[EMAIL PROTECTED]> writes: >>Leaping to conculusions based on no tests at all is even worse... >> >>Will anyone bite the bullet and write the "Internals Decisions should >>be based on actual tests on multiple platforms" RFC ? > >BTW, I have access to Rational Software's Quantify (and

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: 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 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)

>> 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: 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)

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

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]

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

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

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

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

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

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 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()

Make your suggestions. But I think it is all off-base. None of this is addressing some improvement in working conditions, ease of use, problems in the language, etc. You are addressing stylistic issues. Issues that effect the way _I_ want to work with the language. All of you are being fascist.

Re: Are Perl6 threads preemptive or cooperative?

What if every subroutine tagged itself with a list of the globals it uses, so a calling routine would know to add those to the list of globals it wants locked?

Re: Are Perl6 threads preemptive or cooperative?

At 12:11 PM 8/28/00 -0500, David L. Nicol wrote: >What if every subroutine tagged itself with a list of the globals >it uses, so a calling routine would know to add those to the list >of globals it wants locked? If you're looking for automagic locking of variables, you're treading deep into "In

RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

> What I meant to say was more along the lines of "if this could be done as a > macro, does it need to be a pragma, or could it be part of a standard macro > package?" > > And, secondly, "if this *is* part of a standard macro package, wouldn't it > be cool to let it shove arbitr

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

On 8/28/00 3:09 PM, Damian Conway wrote: >> (Or, was it already intended that the implementation of 'use >> invocant' might be some sort of compile-time macro?) > > No. I think a macro facility for Perl should be more general than just > whacking some code in at the start of every subroutine. >

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

> > The use invocant was proposed as a way to maintain backwards > > compatibility and yet give everyone the invocant access syntax he > > or she personally favours. > > ...while also giving the compiler enough information to allow such > invocant access to execute in an optimize

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

On 8/28/00 3:35 PM, Damian Conway wrote: >> ...while also giving the compiler enough information to allow such >> invocant access to execute in an optimized manner...right? C'mon, >> I'm dying here thinking that all this (admittedly cool) stuff is >> gonna end up giving Perl 6 even more OO overhea

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

> I was talking about the hypothetical situation where you're (re)using or > modifying a bunch of code or classes written by different people and you > constantly have to be aware of which self-thingie to use in which file or > package or whatever. Yeah, you can just glance up to the

Re: RFC 161 (v2) OO Integration/Migration Path

At 11:28 AM 8/28/00 -0700, Steve Fink wrote: >Dan Sugalski wrote: > > > > If the vtable stuff goes into the core perl engine (and it probably will, > > barring performance issues), then what could happen in the > > > > my Foo $bar; > > > > case would be that all the vtable functions for Foo are

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

On 8/28/00 3:53 PM, Damian Conway wrote: >> Too much B&D for a Monday? > > No. I *do* have sympathy with the desire for One True Way, but *only* if the > access function is called C (my own religion ;-). > > And *that's* the problem. Yeah, there'll never be consensus on this list or in the comm

Re: RFC 159 (v1) True Polymorphic Objects

> Summary: I think these should all simply break down into a single > Boolification test of some sort, as occurs already with operator > overload. Counter-summary: Although the high and low precedence binary ops could be rolled together, the current version of operator o

RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

> (Or, was it already intended that the implementation of 'use > invocant' might be some sort of compile-time macro?) No. I think a macro facility for Perl should be more general than just whacking some code in at the start of every subroutine. The use invocant was proposed as a way to ma

RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

> > (Or, was it already intended that the implementation of 'use > > invocant' might be some sort of compile-time macro?) > No. I think a macro facility for Perl should be more general than just > whacking some code in at the start of every subroutine. Yes. I didn't phrase my comments well

Re: RFC 155 (v2) Remove mathematic and trigonomic functions from core binary

>Move the mathematic functions (C, C, C) from the core >binary into a loadable module. Remove the trigonomic (C, C, >C) functions from the binary, they can already be loaded from the >Math::Trig.pm module. >=head1 DESCRIPTION >It is desirable to make the perl core binary be easy to maintain a

Re: RFC 155 - Remove geometric functions from core

Nick Ing-Simmons <[EMAIL PROTECTED]> writes: > But if perl6 bytecode does not need to be modified to be used I'd assume that. -- Johan

Re: RFC 130 (v4) Transaction-enabled variables for Perl6

Steve Fink wrote: > > "cond" for conditional? I was thinking along that line, too. But coopting "conditional" in any way is probably an ungood idea. Probly "trans" is good; it has multiple useful mnemonic values: transactional, transfer, transparent... -- John Porter We're building

Re: Splitting core functions into multiple shared objects: A warning

I think the importance of splitting the core functionality into shared objects is more general than that. There was some discussion a short time ago about making a pared-down version for embedding, which would seem to require some sort of functionality reduction. There is also the desire of minimi

Re: RFC 155 (v2) Remove mathematic and trigonomic functions from core binary

Tom Christiansen <[EMAIL PROTECTED]> writes: > >Explain why things like #ifdef HAS_SETLOCALE are not sufficient for >this stated purpose. Because the source has to have something like: #ifdef HAS_SETLOCALE ... setlocale(...) ... #else #endif That does not help someone who has Locale

Re: RFC 110 (v3) counting matches

On Mon, Aug 28, 2000 at 12:23:48PM -0600, Tom Christiansen wrote: > >Have you ever wanted to count the number of matches of a patten? s///g > >returns the number of matches it finds. m//g just returns 1 for matching. > >Counts can be made using s//$&/g but this is wastefull, or by putting some

Re: RFC 110 (v3) counting matches

> Which I find cute as a demonstration of the Perl's context concept, > but ugly as hell from usability viewpoint. I how to assign to an s/how/have/; $need_more_coffee++; -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'd

Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()

> If you want to change STUPID behaviour that should be avoided by current > programs (such as empty regexes) fine. Simple solution. If you want to require formats such as m/.../ (which I actually think is a good idea), then make it part of -w, -W, -ww, or -WW, which would be a perl6 enhancement

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

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: 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: 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

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: 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

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 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

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 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: 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 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 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 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 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)

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 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: 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: 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: 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

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: 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: multidim. containers

At 08:18 AM 8/29/00 +1200, Christian Soeller wrote: >Dan Sugalski wrote: > > That doesn't mean that n-dimensional arrays won't be just sugar over the > > standard list-o-list structure to start, but they won't have to stay > that way. > >That seems to be a possible route. Get multi-dim syntax for

Re: RFC 130 (v4) Transaction-enabled variables for Perl6

> "SF" == Steve Fink <[EMAIL PROTECTED]> writes: SF> Or what about a variable attribute: SF> my $x : transactional SF> and making the effect completely lexical? Why would other scopes need to SF> see such variables? You haven't handled the multiple variable variety. You will need to able t

Re: RFC 155 (v2) Remove mathematic and trigonomic functions from core binary

Stephen P Potter <[EMAIL PROTECTED]> writes: > At this point, should I go ahead and abandon the Math/Trig and/or > Sockets ones? I'm still in favor of moving the socket functions into Socket if for no other reason than it may help beat into people's heads that code like: eval 'require "sys/

Re: RFC 155 (v2) Remove mathematic and trigonomic functions from core binary

> I'm still in favor of moving the socket functions into Socket if for no > other reason than it may help beat into people's heads that code like: > > eval 'require "sys/socket.ph"'; > eval 'sub SOCK_DGRAM {-f "/vmunix" ? 2 : 1;}' if $@; > > and > > $csock = pack('S n a4 x8', 2, 0,

Re: multidim. containers

Dan Sugalski wrote: > If you want efficiency, n-dimensional arrays really need to be a concrete > data type all of their own. That way one big block of memory can be > allocated and, if it's a typed array, properly sized. I wholeheartedly agree ;) > > That doesn't mean that n-dimensional array

RE: RFC 146 (v1) Remove socket functions from core

>Leaping to conculusions based on no tests at all is even worse... > >Will anyone bite the bullet and write the "Internals Decisions should >be based on actual tests on multiple platforms" RFC ? BTW, I have access to Rational Software's Quantify (and PureCoverage and Purify) on WinNT and HP-UX 10

Re: RFC 155 (v2) Remove mathematic and trigonomic functions from core binary

Lightning flashed, thunder crashed and Nick Ing-Simmons <[EMAIL PROTECTED]> whispered: | I think this is inappropriate for sin/cos/tan et. al. and possibly even | sockets (although Win32 sockets are weird enough that it would be worthwhile) | | But for getpw* or shm/queue/msg or other may-not-b

Re: RFC 146 (v1) Remove socket functions from core

It's been strongly indicated that removing sockets (as well as any other Perl functions that are little but wrappers around libc calls) will not meaningfully reduce the size of Perl nor increase its speed. Various VM issues have been discussed, including risks of deadly embrace and egregious perf

Re: multidim. containers

At 10:28 AM 8/28/00 +1000, Jeremy Howard wrote: > > >David L. Nicol wrote: > > If arrays as we know them implement by using a key space restricted to > > integers, I think a reasonable way to get matrices would be to open > > up their key space to lists of integers. > > >I've been thinking along e

RE: RFC 146 (v1) Remove socket functions from core

>>BTW, I have access to Rational Software's Quantify (and PureCoverage and >>Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests. > >If you want to get "in the mood" it would be good to fire it up on >(say) perl5.6.0 and see where the hot-spots are. Planning on it as part of

Re: RFC 148 (v1) Add reshape() for multi-dimensional array reshaping

Consider @x[10:20, 20:40:2, 30:50] This ALMOST works in the current Perl. @x gives array context, then the , produces a list. If [] is overloaded on @a then the subroutine sees a list like "10:20", "20:40:2", "30:50" The only reason it does NOT work in the current perl is that "10:20" is a s

Re: New variable type: matrix

At 10:48 AM 8/28/00 -0400, Karl Glazebrook wrote: >Using semicolons is an interesting idea. But consider: > >@a[10:20; 30:40]; > >The ":"s and ";" are awfully hard to visually distinguish. True, but @a[10..20; 30..40]; isn't hard to distinguish. Even so, you might get such things as: @a[10..20

Re: New variable type: matrix

Karl, all: I have just been auditing this list so far ;) But I would like to speak up in support of Baris' idea. I have long found it confusing (both to myself and to those I must explain my code to) the mix of pdl multi-dimensional lists (lists of refs to lists) and PDLs, which appear to be sc

Re: New variable type: matrix

Doug Hunt wrote: > But I would like to speak up in support of Baris' idea. I have long > found it > confusing (both to myself and to those I must explain my code to) the > mix of > pdl multi-dimensional lists (lists of refs to lists) and PDLs, which > appear to be scalars. I was even asked once

Re: New variable type: matrix

Christian: You are right, it would not be best to confuse normal perl lists with compact arrays--they both have their purposes and can be combined usefully. What I meant to say (but failed, alas) was that I support the idea for a new perl variable type called compact array: $foo -- scalar @foo

Re: New variable type: matrix

Doug Hunt wrote: > What I meant to say (but failed, alas) was that I support the idea for a > new perl variable type called compact array: > > $foo -- scalar > @foo -- array > %foo -- hash > ^foo -- compact array (or whatever notation) I seem to remember that ^ was in the process of being hig

Re: New variable type: matrix

> > ^foo -- compact array (or whatever notation) > > I seem to remember that ^ was in the process of being highjacked by some > other RFC already. Was it higher-order functions? Yes: RFC 23 (v4): Higher order functions Damian

Re: New variable type: matrix

Using semicolons is an interesting idea. But consider: @a[10:20; 30:40]; The ":"s and ";" are awfully hard to visually distinguish. c.f. @a[10:20, 30:40]; What do people feel about the whole replacing ".." by ":" issue? Karl

Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()

Tom Christiansen wrote: > > How nice of you to put words in my mouth. Please cite me the precise > message ID, date, and appropriate text in which I said "we can't > change anything because of precedent". First off, I wasn't trying to insult you, or push a hot button, or suggest we should destro

Re: RFC 110 (v3) counting matches

On Mon, Aug 28, 2000 at 06:05:03PM -0400, Mark-Jason Dominus wrote: > # WRONG > while (($mo, $dy, $yr) = ($string =~ /\d\d-\d\d-\d\d/g)) { > ... > } I assume you mean: while (($mo, $dy, $yr) = ($string =~ /(\d\d)-(\d\d)-(\d\d)/g)) { ... } Drawing on some

Re: RFC 110 (v3) counting matches

> Drawing on some of the proposals for extended 'for' syntax: > for my($mo, $dy, $yr) ($string =~ /(\d\d)-(\d\d)-(\d\d)/g) { > ... > } > > This still requires that you know how many () matching groups are in > the RE, of course. I don't think I would consider that onerous. If ther rege

Re: RFC 110 (v3) counting matches

> > 1. Return the number of matches > > > > 2. Iterate over each match in sequence > > > > 3. Return list of all matches > > > > 4. Return a list of backreferences > > Please see RFC 164. It can handle all of 1-3. You seem to have missed my point. I'm not ask

Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()

> >Simple solution. > > >If you want to require formats such as m/.../ (which I actually think is a > >good idea), then make it part of -w, -W, -ww, or -WW, which would be a perl6 > >enhancement of strictness. > > That's like having "use strict" enable mandatory perlstyle compliance > checks, an

  1   2   >