Re: RFC 76 (v1) Builtin: reduce

Perl6 RFC Librarian <[EMAIL PROTECTED]> (but actually it was Damian Conway) writes: > If the original list has no elements, C immediately returns C. I like everything except this part. Reducing an empty list should be an error. Returning undef (or anything else, really) breaks the algebraic eq

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

John Porter <[EMAIL PROTECTED]> writes: > Michael Fowler wrote: > > > > I think a stringified reference is worth seeing, moreso than a simple undef, > > for debugging purposes if nothing else. > > I personally would like to have the stringification of refs be a > symmetric operation, i.e. such

RFC 80 (v1): Exception objects and classes for builtins

Peter Scott writes: > try { > # fragile code > } catch Exception::IO with { > # handle IO exceptions > } catch Exception::Socket with { > # handle network exceptions > } otherwise { > # handle other exceptions > }; What would the difference betw

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

On Wed, 9 Aug 2000 22:57:34 -0500, Jonathan Scott Duff wrote: >By "local timezone" do you mean that some sort of inspection happens to >determine the local timezone and the date() intrinsically knows about it? >What about daylight savings time? I presume the ability to specify an >offset from GM

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

On Thu, 10 Aug 2000 13:22:46 +1000 (EST), Damian Conway wrote: >The RFC I'm writing specifies that if the subroutine being called has >a lazy context specifier on a given argument, that argument is only >evaluated when the value of the corresponding element of @_ is fetched, >stored, or eval'd.

Re: Proposal for \v and \V, the small- and large- cut regex opera tors.

On Thu, 10 Aug 2000 04:42:56 -0400, Ilya Zakharevich wrote: >> Variable interpolation can be handled using Damian's curried expressions. > >On XRay: > >Summary for query "curried;Damian": > > found 0 matches in 0 files. Look up RFC 23 on : "Higher order functions". -

Re: Things to remove

On Sat, 5 Aug 2000 09:44:47 -0500, Jonathan Scott Duff wrote: >Here in my pre-caffiene morning trance it occurs to me that a few of >the "fringe" features of perl should be removed from the langauge. >Here's a few things that I would venture to say that none of the >"perl5 is my first perl" peopl

And A Parser In A Pared Tree (was Re: Overloading && ||)

On Thu, 10 Aug 2000, David L. Nicol wrote: > "Bryan C. Warnock" wrote: > > > This was the ass that I never found the gall to scratch, because I've > > identified no solutions, and have found only problems. > > > > -- > > Bryan C. Warnock > > ([EMAIL PROTECTED]) While I appreciate the creative c

Re: Overloading && ||

On Wed, 9 Aug 2000, Bryan C. Warnock wrote: > What I was trying to say, is that I think most of the language RFCs > could be addressed (in one way) by affecting whether and how the parser > interprets what the lexer gives to it. That's closer to the truth, though the RFCs that don't introduce br

we might as well give up now: CobolScript(R)

We will never conquer the world with Perl 6: CobolScript(R) got there before us. http://www.cobolscript.com/ -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen

Re: RFC 80 (v1) Exception objects and classes for builti

2000-08-10-02:40:41 Perl6 RFC Librarian: > RFC 70 proposes that all builtins throw trappable exceptions on > error. Not quite. RFC 70 acknowleges that perl's current behavior is preferred by some very focal participants in the language's development, and even if it weren't, that switching all bu

Portable upper/lower case regexp matches

As far as I know, there is a basic bit of regexp functionality which Perl should support but doesn't. Perl regexps support the following features, though they're a bit obscure to my tastes... (from perlre:) \l lowercase next char (think vi) \u uppercase next char (think

Re: RFC 78 (v1) Improved Module Versioning And Searching

2000-08-09-21:00:31 Chaim Frenkel: > Making a module local to the using package, might have interesting > properties. [...] > The only breakage that I see, is having some way of globally setting > a variable. For example, turning on debugging for all uses. (FTP::Debug > I find quite popular.) > >

Re: RFC 78 (v1) Improved Module Versioning And Searching

2000-08-09-17:33:25 Steve Simmons: > If that's the intent, then yes, author name must become part of the > package identifier. Rather than change the meaning of "ref $object" > unexpectedly, I'd add one or more alternate forms of ref. Off the > top of the head, something like > > ( $version

Re: Portable upper/lower case regexp matches

On Thu, 10 Aug 2000 17:21:44 +0300, Jason Elbaum wrote: > \x match lowercase alpha char >\X match uppercase alpha char > >Thus /\X\x*/ would match all capitalized words, while /\X+/ would match >acronyms, and /(\X\x+)+/ would match Java class names. You've got my vote, ap

Re: RFC 78 (v1) Improved Module Versioning And Searching

On Wed, Aug 09, 2000 at 05:53:44PM -0400, Ted Ashton wrote: > I'll take that as my cue ;-). Ah, nothing like a man who knows when to pick up his cues. > <*shudder*> This whole business is getting pretty scary . . . [[ discussion of ugly implicatations elided ]] The short answer is that (ass

Re: Portable upper/lower case regexp matches

On Thu, Aug 10, 2000 at 05:21:44PM +0300, Jason Elbaum wrote: > As far as I know, there is a basic bit of regexp functionality which > Perl should support but doesn't. > > Perl regexps support the following features, though they're a bit > obscure to my tastes... > > (from perlre:) > \l

Re: RFC 80 (v1): Exception objects and classes for builtins

At 02:56 AM 8/10/00 -0500, Jonathan Scott Duff wrote: >Peter Scott writes: > > try { > > # fragile code > > } catch Exception::IO with { > > # handle IO exceptions > > } catch Exception::Socket with { > > # handle network exceptions > > } otherwise { > >

Re: Portable upper/lower case regexp matches

Jason Elbaum <[EMAIL PROTECTED]> writes: > Perl regexps support the following features, though they're a bit > obscure to my tastes... > > (from perlre:) > \l lowercase next char (think vi) Actually, this has little to do with regexes, it a string issue. > ...but Perl doesn't offe

Re: RFC 78 (v1) Improved Module Versioning And Searching

Thus it was written in the epistle of Steve Simmons, > On Wed, Aug 09, 2000 at 05:53:44PM -0400, Ted Ashton wrote: > > > I'll take that as my cue ;-). > > Ah, nothing like a man who knows when to pick up his cues. :-) > > <*shudder*> This whole business is getting pretty scary . . . > [[ di

Re: RFC 78 (v1) Improved Module Versioning And Searching

On Thu, Aug 10, 2000 at 11:01:39AM -0400, Bennett Todd wrote: > Rather than proliferating the number of keywords eaten with all > these *ref varients, this sounds like a useful place for returning > an object with a default stringification of the class: > . . . > Ref RFC 37, RFC 73. I have no p

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

At 03:38 PM 8/10/00 +1000, Damian Conway wrote: >> >> An object that has many different -ify methods: >> >> stringify >> >> numify >> >> hashify >> >> listify >> >> objectify (!) >> > >> > Possible, but blech. >> >> Why is t

Re: RFC 78 (v1) Improved Module Versioning And Searching

At 10:43 AM 8/10/00 -0400, Bennett Todd wrote: >2000-08-09-21:00:31 Chaim Frenkel: > > Making a module local to the using package, might have interesting > > properties. [...] > > The only breakage that I see, is having some way of globally setting > > a variable. For example, turning on debugging

Re: RFC 67 (v1) Deep Copying, aka, cloning around.

At 11:01 PM 8/9/00 -0500, Jonathan Scott Duff wrote: >On Wed, Aug 09, 2000 at 11:46:12AM -0500, Garrett Goebel wrote: > > From: Peter Scott [mailto:[EMAIL PROTECTED]] > > > > > > >I would like deep copying to include copying CODE. It would > > > >be useful for implementing object methods... > > >

Re: Portable upper/lower case regexp matches

At 10:28 AM 8/10/00 -0500, Jarkko Hietaniemi wrote: >On Thu, Aug 10, 2000 at 05:21:44PM +0300, Jason Elbaum wrote: > > As far as I know, there is a basic bit of regexp functionality which > > Perl should support but doesn't. > > > > Perl regexps support the following features, though they're a bit

Re: Portable upper/lower case regexp matches

On Thu, Aug 10, 2000 at 08:55:27AM -0700, Peter Scott wrote: > At 10:28 AM 8/10/00 -0500, Jarkko Hietaniemi wrote: > >On Thu, Aug 10, 2000 at 05:21:44PM +0300, Jason Elbaum wrote: > > > As far as I know, there is a basic bit of regexp functionality which > > > Perl should support but doesn't. > >

Re: RFC 78 (v1) Improved Module Versioning And Searching

You might want to check out Umbrella Frameworks: http://arstechnica.com/reviews/2q00/macos-x-dp4/macos-x-dp4-3.html It would be good for some of us to have an easier way of using multiple versions of modules sometimes. -Hao

RE: RFC 78 (v1) Improved Module Versioning And Searching

-Original Message- From: Steve Simmons [mailto:[EMAIL PROTECTED]] > For the record, I prefer hashes for that sort of thing too. But > perl has traditionally done ordered list returns, and I followed in > that vein. Perhaps Damian's want() (RFC 21) can be used to allow allow either ret

Re: RFC 78 (v1) Improved Module Versioning And Searching

2000-08-10-11:52:31 Dan Sugalski: > Why not, then, introduce non-fatal errors and a new keyword to > throw them? If we were to add a non-fatal exception type, that would just mean that those of us who want errors to behave differently than they do now, would have to wrap our whole program in a ca

Re: RFC 80 (v1): Exception objects and classes for builtins

On Thu, Aug 10, 2000 at 02:56:59AM -0500, Jonathan Scott Duff wrote: > Peter Scott writes: > > try { > > # fragile code > > } catch Exception::IO with { > > # handle IO exceptions > > } catch Exception::Socket with { > > # handle network exceptions > > } oth

Re: RFC 80 (v1) Exception objects and classes for builti

At 09:44 AM 8/10/00 -0400, Bennett Todd wrote: >2000-08-10-02:40:41 Perl6 RFC Librarian: > > RFC 70 proposes that all builtins throw trappable exceptions on > > error. > >Not quite. RFC 70 acknowleges that perl's current behavior is >preferred by some very focal participants in the language's >dev

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

Jonathan Scott Duff <[EMAIL PROTECTED]> writes: > By "local timezone" do you mean that some sort of inspection happens to > determine the local timezone and the date() intrinsically knows about > it? What about daylight savings time? This all should be handled by the operating system. If you c

Re: RFC 78 (v1) Improved Module Versioning And Searching

At 12:11 PM 8/10/00 -0400, Bennett Todd wrote: >2000-08-10-11:52:31 Dan Sugalski: > > Why not, then, introduce non-fatal errors and a new keyword to > > throw them? > >Arranging for all the builtins to throw a non-fatal exception would >impose a cost on the rest of the folks, who prefer to have mo

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

Bart Lateur <[EMAIL PROTECTED]> writes: > As for the parameter's format: GMT is easy, you can pass "GMT" (or > "+"). For localtime(), you often don't explicitely know the time > zone and Daylight savings Time rule, so this looks like a good candidate > for undef. The string "GMT" is technica

Re: RFC 80 (v1): Exception objects and classes for builtins

At 05:11 PM 8/10/00 +0100, Graham Barr wrote: >I was more thinking of > > eval { > # fragile code > } > else { # catch ALL exceptions > switch ($@) { > case __->isa('IO') { ... } > case __->isa

Re: RFC 80 (v1): Exception objects and classes for builtins

On Thu, Aug 10, 2000 at 09:34:43AM -0700, Peter Scott wrote: > At 05:11 PM 8/10/00 +0100, Graham Barr wrote: > >I was more thinking of > > > > eval { > > # fragile code > > } > > else { # catch ALL exceptions > > switch ($@) { >

Re: RFC 78 (v1) Improved Module Versioning And Searching

On Thu, Aug 10, 2000 at 12:28:05PM -0400, Dan Sugalski wrote: > No, it wouldn't, really. We could make "use fatal;" scoped, so that the > quit op (or whatever it is) only jumps through all its hoops if the > pragma's in effect. If its not, then quit(foo, bar, baz) does a bare return > and that'

My opposition to RFC20, and an alternative

Overloading an existing operator such that it changes the performance in prior situation is evil, evil, evil. Yes, I know it can have some wins, and I agree they're big ones. But no win is worth having to debug this (admittedly contrived for the example) situation: if ( ( $ares = A() ) && (

Re: RFC 80 (v1): Exception objects and classes for builtins

Graham Barr wrote: > > The catch syntax is less flexable, if you wanted to catch two > different types with the same code you are forced to either > * duplicate code > * put it in a sub, which is away from the statement. > * put a switch statement in the otherwise Could catch lists of type

Re: RFC 80 (v1) Exception objects and classes for builti

Peter Scott <[EMAIL PROTECTED]>: > > try { > # fragile code > } catch Exception::IO with { > # handle IO exceptions > } catch Exception::Socket with { > # handle network exceptions > } otherwise { > # handle other exceptions > }; I'd l

Re: RFC 78 (v1) Improved Module Versioning And Searching

At 05:46 PM 8/10/00 +0100, Graham Barr wrote: >On Thu, Aug 10, 2000 at 12:28:05PM -0400, Dan Sugalski wrote: > > No, it wouldn't, really. We could make "use fatal;" scoped, so that the > > quit op (or whatever it is) only jumps through all its hoops if the > > pragma's in effect. If its not, then

Re: RFC 80 (v1) Exception objects and classes for builti

2000-08-10-12:19:49 Peter Scott: > Ah, got it. Now we have actually two types of error from builtins: > > Non-trapped (builtins return 0, undef, 1 :-) , n where n < # requests, etc). > RFC 70 wants all these to be turned into optional exceptions if Fatal is used. Ultimately, yes, that's my goal

Re: RFC 78 (v1) Improved Module Versioning And Searching

> Perhaps Damian's want() (RFC 21) can be used to allow allow either return > type? Yes indeed. > Assuming that's adopted, of course. Sure looks to me like a good idea; I hope it does.

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

Jeremy Howard wrote: > The reason that having (1..) implies having (..-1) is that if you allow > (1..), then this is a valid construct: > > @dot_dot_neg_one = reverse (map {-$_} (1..)); > > which is identical to (..-1)! No, NOT identical. The same set of numbers, yes, but generated in the o

Re: RFC 80 (v1): Exception objects and classes for builtins

On Thu, 10 Aug 2000 09:34:43 -0700, Peter Scott wrote: >Do you propose this solely to conserve keywords, or is there another >advantage? I find > > try { > # > } catch Exception::Thingy with { > # > } catch Exception::Whatsit with { > # >

Re: RFC 8 (v2) The AUTOLOAD subroutine should be able t

[EMAIL PROTECTED] writes: : =head1 IMPLEMENTATION : : This strikes me as being a fairly easy thing to do, but then again : internals ain't my thing, baby. The problem I see here isn't the internals--it's how do you translate Perl 5 to Perl 6? Larry

Re: And A Parser In A Pared Tree (was Re: Overloading && ||)

perl parser compiles perl language into perl op-code tree. Larry ("the" Larry) has said that a new parser might parse other languages into perl op-code trees too. If the parts of the language are well organized, a LanguageSwitch (the computer equivalent of a "context switch" in a conversation

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

On Thu, Aug 10, 2000 at 09:30:05AM -0700, Russ Allbery wrote: > Bart Lateur <[EMAIL PROTECTED]> writes: > > > As for the parameter's format: GMT is easy, you can pass "GMT" (or > > "+"). For localtime(), you often don't explicitely know the time > > zone and Daylight savings Time rule, so thi

Re: Overloading && ||

> We may be able to fake it with source filters and parser abuse, though. I'm intending to write RFCs on revamping source filters, and also on run-time access to the parse tree. Just as soon as I grow those two extra hands so I can run that second keyboard in parallel. Damian

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

Why push it through a user subroutine. Might as well make it part of the core language. Why add another keyword non_lazy. though it isn't an antonym, eval{} has the right meaning and effect. I can see the utility of having the callee specify the alacrity of the parameter. But this would put quit

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

Perl6 RFC Librarian wrote: > It is proposed that a new syntax for declaring constants be introduced: > > my constant $PI = 3.1415926; > my constant @FIB = (1,1,2,3,5,8,13,21); > my constant %ENG_ERRORS = (E_UNDEF=>'undefined', E_FAILED=>'failed'); I like this. Implementation wise, it coul

Re: RFC: Higher resolution time values

Dan Sugalski <[EMAIL PROTECTED]> writes: >>Why - the 1/10 of second is not exact anyway (unless you happen to >>have an atomic clock in an appropriate physical enviroment attached to >>your machine). A double's mantissa is better than your typical oscillator. > >While it may not be correct, at lea

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

On Thu, 10 Aug 2000, Larry Wall wrote: > Can't put a modifier like "constant" in the type slot. The syntax for > variable attributes will look more like this: > > my num $PI : constant = 3.1415926; > my int @FIB : constant = (1,1,2,3,5,8,13,21); > my str %ENG_ERRORS : constant = (E_

Re: RFC 80 (v1) Exception objects and classes for builti

(I'm not quite in favour. But assuming this flys...) Why not use Damien's switch syntax. Much more powerful and the flow is better controlled. And why add another keyword. Just extend eval{} to accept two blocks. eval { } catch { } finally { } Wi

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

> my %STRUCT : constant = ( > Name =>str 'Jane', Isn't this ambiguous, considering that the => operator quotes the left side? -Hao

Re: RFC 8 (v2) The AUTOLOAD subroutine should be able t

> Instead of calling the right thing or actually doing the right thing, > AUTOLOAD subroutines should return a coderef which will be run as if > it were the method called. If an AUTOLOAD subroutine does not wish to > cope with a method call, it should return undef. Perl would then wal

Re: RFC 76 (v1) Builtin: reduce

> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes: >> If the original list has no elements, C immediately returns C. AS> I like everything except this part. Reducing an empty list should be AS> an error. AS> Returning undef (or anything else, really) breaks the algebraic AS> equivalence

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

> Why push it through a user subroutine. Might as well make it part of the > core language. Why exacerbate the core, when I one-line user sub can do it? > Why add another keyword non_lazy. though it isn't an antonym, eval{} > has the right meaning and effect. No, "non-lazy" was jus

Re: RFC 80 (v1): Exception objects and classes for builtins

Nice. The continue clause, I assume would re-raise an uncaught exception. But, a big but. How does the 'else' clause indicate that the exception was handled? A couple of possiblities 1. Undef $@. But that's a bit of extra work in each leg. 2. switch is 'slightly' special in an eval/else block.

Re: RFC 76 (v1) Builtin: reduce

> I don't see it. > >1 == f((reduce +, undef), 1) == reduce +, undef, 1 undef isn't an empty list, it's a one element list. Consider the other "common" reduction: sub f { $_[0] * $_[1] } Now: f((reduce \&f, ()), 1) == 0 # f(undef,1) -> f(0,1) -> 0 But

Re: RFC 76 (v1) Builtin: reduce

Chaim Frenkel <[EMAIL PROTECTED]> writes: > > "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes: > > >> If the original list has no elements, C immediately returns C. > > AS> I like everything except this part. Reducing an empty list should be > AS> an error. > > AS> Returning undef (or

Re: RFC 78 (v1) Improved Module Versioning And Searching

I'd put it into Perl::Option{__Package__} There was some talk about making Perl:: special. So that might be the one and only truely global space. Hmm, that wouldn't work with multiple versions without cooperation. Alternatively, we could treat a set Perl::Option{FTP::Net}->

Re: RFC 76 (v1) Builtin: reduce

> By writing @sum = reduce __+__ 0, @numbers > you deal elegantly with both cases. > > NOTE: I find this trick very elegant. I wish it were my trick, > instead of Damian's... Damian wishes it were Damian's, but is sure it's at least a few hundred years old :-) Damian

Re: RFC 8 (v2) The AUTOLOAD subroutine should be able t

On Fri, Aug 11, 2000 at 06:22:46AM +1000, Damian Conway wrote: > I don't *dislike* your proposal, except that it interposes another layer of > indirection on a process that is already too slow. > > >> =head2 $AUTOLOAD >> >> While w

Re: RFC 80 (v1): Exception objects and classes for builtins

On Thu, Aug 10, 2000 at 04:34:50PM -0400, Chaim Frenkel wrote: > Nice. > > The continue clause, I assume would re-raise an uncaught exception. > But, a big but. How does the 'else' clause indicate that the exception > was handled? By not rethrowing it. ie if it does not want to handle the error

Re: RFC 78 (v1) Improved Module Versioning And Searching

On Thu, Aug 10, 2000 at 10:43:02AM -0400, Bennett Todd wrote: > If the only real problem that can be found with making module use > package-local is in these few option-flag type variables, perhaps > they could be handled differently. E.g. suppose normal package > variables end up being local to t

Re: RFC 78 (v1) Improved Module Versioning And Searching

2000-08-10-17:36:41 Graham Barr: > And the difference is ? > > $ perl -e 'warn \$main::fred::x," ",\$fred::x' > SCALAR(0x80dc254) SCALAR(0x80dc254) at -e line 1. Today there's no difference. If the proposal under discussion were to pass, and packages' namespaces were to become local to the names

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

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace => (stringifying comma) with => (pair constructor) =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 10 August 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 84

RFC 85 (v1) All perl generated errors should have a

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE All perl generated errors should have a unique identifier =head1 VERSION Maintainer: Chaim Frenkel <[EMAIL PROTECTED]> Date: 9 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 85 All

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

On 10 Aug 2000, Perl6 RFC Librarian wrote: > %hash = ( a=>1, b=>2, 'c', 3 ); > > does what it does in Perl 5, but works slightly differently. The list being > assigned consists of four elements (not six): a pair reference, another pair > reference, a string, and an integer. Well, I supp

Re: RFC 76 (v1) Builtin: reduce

Damian Conway wrote: >> AS> Also, the RFC should specify that the function is always evaluated in >> AS> a scalar context (for things to make sense). >> >> Why? reduce should be able to reduce a set of matrices to a matrix. Or >> actually any aggregate (plural whatzit). >>

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

John Porter wrote: > Jeremy Howard wrote: > > The reason that having (1..) implies having (..-1) is that if you allow > > (1..), then this is a valid construct: > > > > @dot_dot_neg_one = reverse (map {-$_} (1..)); > > > > which is identical to (..-1)! > > No, NOT identical. The same set of num

Re: RFC 80 (v1): Exception objects and classes for builtins

> "GB" == Graham Barr <[EMAIL PROTECTED]> writes: GB> On Thu, Aug 10, 2000 at 04:34:50PM -0400, Chaim Frenkel wrote: >> Nice. >> >> The continue clause, I assume would re-raise an uncaught exception. >> But, a big but. How does the 'else' clause indicate that the exception >> was handled? G

Re: RFC 76 (v1) Builtin: reduce

> Couldn't reduce return a list just through concatenating its elements? For > instance: > > @a = (1,3,2,4,3,6,4,8); > @sum = reduce( (^total, ^x+^y ), @a ); # (4,6,9,12) Currying placeholders are scalars, so you want: @sum = @{reduce (@^total, ^x+^y ), [], @a }; More

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

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: >> $fooA->foo >> $fooB->foo >> >> What is a poor perl parser to do? DC> Ignore the prototype unless $fooA and $fooB are typed lexicals. DC> I.e. act just like it does now. Hmm, would it be too nasty for perl to recognize that al

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

> Hmm, would it be too nasty for perl to recognize that all foo's have the > same prototype? (Consider the singular foo case.) Probably. Remember that the programmer can always C or C and completely change inheritance hierarchies. Anyway, the overloading functionality you want will be avai

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

Perl6 RFC Librarian wrote: > The first component of a pair would be called its C, and the second, it's > C. It is proposed to either extend the semantics of C and > C to allow them to operate of pair references, or else introduce > two new built-ins -- C and C -- to access the components of a pair

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

Perl6 RFC Librarian wrote: [...] > This RFC proposes the introduction of a new data type -- the I [...] I hereby propose that all current Perl 6 Project Plan deadlines be extended 3 months so that Damian has more time to come up with gems like this. I have no idea if it ultimately makes sense or

Re: RFC 76 (v1) Builtin: reduce

Okay, then for reduce &avg $identity, @list What should $identity be? > "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes: AS> Think of the first element of the list as different from the rest -- AS> it is the initial value to reduce from (for + and *, you'll usually AS> pick an

Re: RFC 76 (v1) Builtin: reduce

Chaim Frenkel wrote: > Okay, then for > > reduce &avg $identity, @list > > What should $identity be? > What's wrong with: $average = reduce (^last+^this, @^list) / scalar @^list; print $average->([1,3,5]); # Prints '3' You don't need to explicitly add a '0' to the front of the summed list.

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

> > When a pair reference is assigned (in)to an array, it remains a > > single scalar (referential) value. So: > > > > @array = ( a=>1, b=>2, 'c', 3 ); > > > > assigns four elements (not six) to @array. > > How do we get keys and values out? The proposed C and C

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

A semantic definition of "constant" would be nice. I'd like to propose the following definition: A constant value cannot be assigned to, deleted, or used as the argument to a mutating function/operator. Doing any of these would be a catchable error. (However, it can be deleted by the GC, and th

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

On Thu, 10 Aug 2000 14:39:39 -0500, Jarkko Hietaniemi wrote: > people in Newfoundland are going to expect to be >> able to pass in -0230 and have that work, and that's interestingly hard. What's so hard? Subtracting 2 hours and 30 minutes from the official referential time (GMT)? Or the Daylight

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

On Fri, Aug 11, 2000 at 02:09:43AM +0200, Bart Lateur wrote: > On Thu, 10 Aug 2000 14:39:39 -0500, Jarkko Hietaniemi wrote: Did not. > > people in Newfoundland are going to expect to be > >> able to pass in -0230 and have that work, and that's interestingly hard. > > What's so hard? Subtracting

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

Damian Conway wrote: >> > When a pair reference is assigned (in)to an array, it remains a >> > single scalar (referential) value. So: >> > >> > @array = ( a=>1, b=>2, 'c', 3 ); >> > >> > assigns four elements (not six) to @array. > The proposed C and C built-ins (o

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

Shades of LISP, batman. I can see it now, the '=>' operator will be called cons-ing. And the new keword for accessing a pair will be CAR and CDR. Are the two values of a pair restricted in anyway? All your examples were scalar. What about a plural whatzit or a reference to a plural whatzit?

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

> Are the two values of a pair restricted in anyway? All your examples > were scalar. Yes. The two components must be scalars. The key is stringified iff it's a bareword. Otherwise no restrictions. > What about a plural whatzit or a reference to a plural > whatzit? References ar

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

On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote: > This method of creating constants has three serious drawbacks: They're also quite heavy, although I think that CONSTSUB was to take care of that. What I never understood, although I'm sure there's a very simple reason, is why it wasn't simply mad

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

> @array = ( a=>1, b=>2, 'c', 3 ); Isn't this just an array of hashrefs in in disguise? Or am I missing something? I don't see a problem for adding more ways to do something, my only problem would be if the "key" and "value" builtins were the only ways to get to the data. You should be a

Re: RFC 85 (v1) All perl generated errors should have a

On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote: > All perl generated errors should have a unique identity. So that > changes in the text should not cause breakage in code. > Good idea. A lot of programs do this. It could make it easier to handle error callbacks. (If you ever get a 'no space l

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

Perl6 RFC Librarian wrote: > The => operator would cease to be a > first-argument-stringifying comma operator I find nothing in the documentation that suggests that => is anything other than a plain comma operator, yet you call it a "first-argument-stringifying comma operator". In fact, the doc

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

> I find nothing in the documentation that suggests that => is > anything other than a plain comma operator, yet you call it a > "first-argument-stringifying comma operator". In fact, the > documentation explicitly claims "=>" is a synonym of "," (see > perldata). The Perl documen

Re: RFC 85 (v1) All perl generated errors should have a

>=head1 TITLE > >All perl generated errors should have a unique identifier This looks awfully similar to RFC 80. Certainly the exception objects RFC 80 is thinking about can well have unique numeric attributes. >All perl generated errors should have a unique identity. So that >changes in the

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

At 02:39 PM 8/10/00 -0500, Jarkko Hietaniemi wrote: >There are quarter-hour time zones... And then there's Damian, who lives in a non-linear time zone... -- Peter Scott Pacific Systems Design Technologies

Re: RFC 80 (v1) Exception objects and classes for builti

At 12:59 PM 8/10/00 -0400, John Porter wrote: >I'd like to recommend just "catch" instead of "otherwise", >because sometimes you'll do this: > > try { > # fragile code > } > catch { > # handle other exceptions > }; > >And it would loo

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

Perhaps a pair is a degenerate pseudo-hash (but then a pseudo-hash is degenerate period.) So the correct access should be print keys %$array[0] During the give and take of Topaz, having arrays and hashes have similar access functions was bandied about. So that one could possibly have a

Re: RFC 76 (v1) Builtin: reduce

Damian Conway wrote: > Currying placeholders are scalars Is that a general truth? It wasn't obvious from RFC 23... If you rev it, perhaps you could make that clearer. Looking back, the defining example did give a list of (;) in the prototype. I suppose it would be pretty complex to infer

Re: RFC 80 (v1): Exception objects and classes for builtins

At 05:44 PM 8/10/00 +0100, Graham Barr wrote: >In fact the syntax could be > > eval { > } > continue { > } > > switch ($@) { > } if $@; > >I just don't see the need to make perl look like other languages just for >the sake of makeing it look like other languages. No, I wasn't thinking

Re: RFC 89 (v1) Controllable Data Typing

Syloke Soong <[EMAIL PROTECTED]> writes: > my $varname type; The syntax my $varname : constant; # pun not intended :) Was brought up earlier (but probably not before this RFC was written). Perhaps something similar could be used for the sake of consistency. > if ($somecond

Re: RFC 80 (v1): Exception objects and classes for builtins

At 05:44 PM 8/10/00 +0100, Graham Barr wrote: >Well what is the difference between try and eval ? There isn't any. I could have sworn I once read that the block eval was so different from the string eval that Larry wanted to use 'try', but didn't want to add another keyword, but later wished h

  1   2   >