Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread Damian Conway
Is this not just a module which creates the necessary subs in the calling package ? The catchall can be done with an AUTOLOAD sub. That's certainly how Class::Delegation is implemented. It isn't quite adequate however, because if you trigger the AUTOLOAD and it *fails* to delegate, you

Re: RFC 91 (v2) Builtin: part

2000-09-05 Thread David L. Nicol
In order to work with lists of arbitary size, it is often necessary to split a list into equal sized sub-lists. A Cpart function is proposed that achieves this: Are the sublists copies or aliases? I imagine they are aliases, but this could be specified in the RFC --

Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword toforce list context (like Cscalar))

2000-09-05 Thread Graham Barr
On Tue, Sep 05, 2000 at 11:16:48AM +1100, Damian Conway wrote: By RFC 21, it looks like the call would be if ( want 'LIST' ) { $num_to_return = want; # do stuff } or, more efficiently: if ( ($num_to_return) = want 'LIST' ) {

Re: code repository

2000-09-05 Thread Stephen Zander
"Bradley" == Bradley M Kuhn [EMAIL PROTECTED] writes: Bradley On a personal note, I would not be able to participate in Bradley Perl6 development if doing so required that I use Bradley perforce, because I have personal ethical beliefs that Bradley prohibit me from using free

Re: Profiling

2000-09-05 Thread Nick Ing-Simmons
[EMAIL PROTECTED] writes: Anyone surprised by the top few entries: Nope. It looks close to what I saw when I profiled perl 5.004 and 5.005 running over innlog.pl and cleanfeed. The only difference is the method stuff, since neither of those were OO apps. The current Perl seems to spend most

Re: RFC 178 (v1) Lightweight Threads

2000-09-05 Thread Chaim Frenkel
"SWM" == Steven W McDougall [EMAIL PROTECTED] writes: my $a; Perl simply ignores locking. Thread gets the value of the winner in a race condition. Perl does _not_ crash and burn. Internal structures, mallocs, and accesses are properly mutexed. SWM I don't understand this. SWM Is $a

Re: RFC 145 (alternate approach)

2000-09-05 Thread Nathan Wiger
I think it's cool too, I don't like the @^g and ^@G either. But I worry about the double-meaning of the []'s in your solution, and the fact that these: /\m[...]...\M/; /\d[...]...\D/; Will work so differently. Maybe another character like ()'s that takes a list: /\m(,[).*?\M(,])/;

Re: code repository

2000-09-05 Thread Dan Sugalski
At 09:29 AM 9/4/00 -0400, Bradley M. Kuhn wrote: Ask Bjoern Hansen wrote: the perl-qa people have some code they need to manage in a repository of some kind. For now I have directed them to SourceForge, but I have a 100 users license for perforce I got for perl, so if we can get a quick

Re: Proposed RFC for matrix indexing and slicing

2000-09-05 Thread Dan Sugalski
At 08:28 PM 8/31/00 -0700, Nathan Wiger wrote: Larry Wall wrote: More generally, for all X, I wouldn't mind if Perl became the language of choice for X. Who wouldn't! But I think that would probably have to be, "if Perl became the language of choice for X - 1". Perl's gotta be written in

Re: RFC 72 (v3) Variable-length lookbehind: the regexp engine should also go backward.

2000-09-05 Thread mike mulligan
From: Peter Heslin [EMAIL PROTECTED] Sent: Thursday, August 31, 2000 10:49 PM Simply put, I want variable-length lookbehind. The RFC seems to say you want this so that you can optimize the operation of the regex execution. I've been looking at the existing fixed-length look-behind and see

Re: RFC 145 (alternate approach)

2000-09-05 Thread David Corbin
Nathan Wiger wrote: I think it's cool too, I don't like the @^g and ^@G either. But I worry about the double-meaning of the []'s in your solution, and the fact that these: /\m[...]...\M/; /\d[...]...\D/; Well, it's not really a double meaning. It's a set of characters, just like

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-09-05 Thread Nathan Torkington
Peter Scott writes: Hey, waitaminute. That isn't a list in sub fn in the first place; it's three expressions separated by scalar commas. Why is there no complaint about useless use of a constant in void context? $ perl -Mstrict -wle 'sub f{return(3,5,7)} my $x = f()' $ perl -Mstrict

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-09-05 Thread Tom Christiansen
Hey, waitaminute. That isn't a list in sub fn in the first place; it's three expressions separated by scalar commas. Why is there no complaint about useless use of a constant in void context? $ perl -Mstrict -wle 'sub f{return(3,5,7)} my $x = f()' $ perl -Mstrict -wle 'my $x = (3,5,7)'

Re: RFC 145 (alternate approach)

2000-09-05 Thread Jonathan Scott Duff
On Tue, Sep 05, 2000 at 02:12:23PM -0400, Eric Roode wrote: Unfortunately, as Richard Proctor pointed out, ?m is taken. Perhaps (?[list|of|openers) and (?]list|of|closers) ? That breaks the visual meaning of "|" as alternation if the RE engine is to be smart enough to match the closers

Re: RFC 145 (alternate approach)

2000-09-05 Thread Richard Proctor
On Tue 05 Sep, Nathan Wiger wrote: Eric Roode wrote: Now *that* sounds cool, I like it! What if the RFC only suggested the addition of two new constructs, (?[) and (?]), which did nested matches. The rest would be bound by standard regex constructs and your imagination! That is, the ?]

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread David E. Wheeler
Damian Conway wrote: Err, that *is* the default behaviour. Delegation doesn't occur unless you specify it. Or am I missing your meaning here? use delegation attr1 = [qw( method1 method2 method3 )], attr2 = [qw( method4 method5 )], attr3 = __ALL__, # Use all of them. attr4 =

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-05 Thread Jonathan Scott Duff
On Fri, Sep 01, 2000 at 08:59:10PM -, Perl6 RFC Librarian wrote: =head1 TITLE Objects : Private keys and methods =head1 ABSTRACT This RFC proposes a new keyword -- Cprivate -- that limits the accessibility of keys in a hash, and of methods. Its primary use would be to provide

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread Damian Conway
When I see those empty arrayrefs, I think "delegate to *no* methods in those classes stored in attr3 and att4," rather than "delegate all method calls to those attributes." Just in the name of greater clarity, I might like to see something like URI suggested: attr3 =

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread Nathan Wiger
Damian Conway wrote: attr3 = [ALL] It was (and is) a good suggestion. I suspect however that it should be attr3 = [__ALL__] Any consideration given to the :all export-like tag? attr3 = [:all]# could be uppercase too -Nate

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread David E. Wheeler
Damian Conway wrote: It was (and is) a good suggestion. I suspect however that it should be attr3 = [__ALL__] so that classes can still have an CALL method delegated. (Yes, now they can't have an C__ALL__ method, but maybe that's a Good Thing ;-) Agreed. Yes, that's very good,

Re: RFC 145 (alternate approach)

2000-09-05 Thread Nathan Wiger
Richard Proctor wrote: No ?] should match the closest ?[ it should nest the ?[s bound by any brackets in the regex and act accordingly. Good point. Also this does not work as a definition of simple bracket matching as you need ( to match ) not ( to match (. A ?[ list should specify for

Re: RFC 91 (v2) Builtin: part

2000-09-05 Thread Jeremy Howard
David L. Nicol wrote: In order to work with lists of arbitary size, it is often necessary to split a list into equal sized sub-lists. A Cpart function is proposed that achieves this: Are the sublists copies or aliases? I imagine they are aliases, but this could be specified in the RFC

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread Damian Conway
When you want to turn off an inherited delegation in an ISA situation? Um, I don't think I understand the question. I'm confused by the question, too. Delegation is not inherited. Any module you inherit from you won't use for delegation, AFAIK. They're two different

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-05 Thread Tom Christiansen
exists (sometimes causes autovivification, which affects Ckeys) That's not technically accurate--exists never causes autovivification. --tom

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread David E. Wheeler
"David L. Nicol" wrote: When you want to turn off an inherited delegation in an ISA situation? Um, I don't think I understand the question. Delegation is not inherited. Any module you inherit from you won't use for delegation, AFAIK. They're two different beasts. Or am I misunderstanding

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-05 Thread Piers Cawley
Michael Fowler [EMAIL PROTECTED] writes: On Mon, Sep 04, 2000 at 10:34:37AM +0100, Piers Cawley wrote: Well then, that's one nay vote. :) Make that two. Three. But I think Michael already knew about mine and forgot to count it. Heh, I am not counting votes. That was

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread Piers Cawley
Michael G Schwern [EMAIL PROTECTED] writes: On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote: Objects : Core support for method delegation I like it! One gripe (of course)... The proposed delegation mechanism would work via a pragma: use delegation

Re: RFC 39 (v3) Perl should have a print operator

2000-09-05 Thread Bart Lateur
On Tue, 05 Sep 2000 16:46:03 -0700, Nathan Wiger wrote: Would this be solved if print returned the string it printed? This seems to be what everyone's getting at: my $output = print $r-name . " is $age years old\n"; I think that's the idea... and print may return undef if it fails to print,

Re: RFC 39 (v3) Perl should have a print operator

2000-09-05 Thread Jon Ericson
Bart Lateur wrote: Also, print @items; should then return join($,, @items).$\ I would want it to return @items: @sorted = sort print @items; I'd prefer a different name (tee?) and keep print as it is. Jon -- Knowledge is that which remains when what is learned is forgotten.

Re: RFC 39 (v3) Perl should have a print operator

2000-09-05 Thread Tom Christiansen
Jon Ericson wrote: Agreed. Good style would avoid this problem. The example in the synopsis of this RFC should be: my $output = "Print this line.\n"; Would this be solved if print returned the string it printed? This seems to be what everyone's getting at: my $output = print

Re: RFC 39 (v3) Perl should have a print operator

2000-09-05 Thread Tom Christiansen
This is what I'd consider good style: my @output = map { $_-[0] } sort { $a-[1] cmp $b-[1] } map { [$_, expensive_func($_)] } # print original lines ; (Modified from http://www.perlmonks.org/index.pl?node_id=9108) The main point of this statement is the Schwartzian

Re: RFC 39 (v3) Perl should have a print operator

2000-09-05 Thread Tom Christiansen
I think that's the idea... and print may return undef if it fails to print, and the printed string otherwise (always defined, even if it's an emtpy string). Those are not the semantics of print. It returns true (1) if successful, and false (undef) otherwise. You cannot change that. If I

Re: RFC 39 (v3) Perl should have a print operator

2000-09-05 Thread Nathan Wiger
Jon Ericson wrote: I would want it to return @items: @sorted = sort print @items; I'd prefer a different name (tee?) and keep print as it is. Pretty much all the stuff being discussed right now can be stuck in a module: package Print::Variations; use Exporter; @EXPORT =

Re: RFC 39 (v3) Perl should have a print operator

2000-09-05 Thread Jon Ericson
Tom Christiansen wrote: Again, I can't *ever* remember wanting a function that did this. Rare things shouldn't have hard-to-figure-out names. Why do you want it? Debugging or something? Have you tried tie? I've found myself wanting this operator several times since I wrote the RFC -

Re: RFC 39 (v3) Perl should have a print operator

2000-09-05 Thread Tom Christiansen
I've found myself wanting this operator several times since I wrote the RFC - mostly for debugging and indicating progress. Nobody else seems to be as fond of the syntax as I am, so I will withdraw the RFC. (Its only virtue is the syntax.) I suggest you create a clever tie module that does

Re: RFC 39 Perl should have a print operator

2000-09-05 Thread Jon Ericson
Ken Rich wrote: How about quotes? A quoted lhs expression could mean print. A quoted lhs expression preceded by a file handle could mean print to filehandle. Have you seen http://dev.perl.org/rfc/2.pod? Tom Christiansen's complaint seems irrelevant to me because a print statement is

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-09-05 Thread Chaim Frenkel
"PS" == Peter Scott [EMAIL PROTECTED] writes: PS I find myself wishing there were something we could do about the PS context rules. They seem simple enough, individually, but when PS you put them together - well, there was a quiz a year or so ago - PS I forget whether it was in TPJ or Usenet -

Re: code repository

2000-09-05 Thread Bradley M. Kuhn
Dan Sugalski wrote: I don't think we should make decisions about the software we use for development based on political views. While I do have many political views regarding free software, this is an issue of ethical views. It against my personal ethics to use proprietary software.

Re: RFC 39 Perl should have a print operator

2000-09-05 Thread Eryq
Jon Ericson wrote: I had considered this, but I don't want Yet Another Quote-like Operator (YAQO). Perhaps I should just change this RFC to call for a built-in tee operator: push @lines, tee($_) for ; I would vote strongly against a built-in "tee" operator. You can achieve the same

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread David E. Wheeler
Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects : Core support for method delegation This idea rocks, Damian! I want it now! Just one suggestion, however... The proposed delegation mechanism would work via a

Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword toforce list context (like Cscalar))

2000-09-05 Thread Damian Conway
if ( ($num_to_return) = want 'LIST' ) { # do stuff } And more correct as I would assume that () = some_func(); $num_to_return would be zero, but the assignment would cause the if() to be true. A scalar context Cwant would

Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175(v1) Add Clist keyword toforce list context (like Cscalar))

2000-09-05 Thread Nathan Wiger
Damian Conway wrote: if ( ($num_to_return) = want 'LIST' ) { # do stuff } $num_to_return would be zero, but the assignment would cause the if() to be true. A scalar context Cwant would also need to DWIM, presumably by returning "0,

Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175(v1) Add Clist keyword toforce list context (like Cscalar))

2000-09-05 Thread Damian Conway
A scalar context Cwant would also need to DWIM, presumably by returning "0, but true" in that (unusual) situation. Actually, given Damian's and my conversations last night, it looks like the first return arg from want() is going to be the context after all (since then

YAVTBL: yet another vtbl scheme

2000-09-05 Thread Benjamin Stuhl
All - I fail to see the reason for imposing that all variables "know" how to perform ops upon themselves. An operation is separate from the data it operates on. Therefore, I propose the following vtbl scheme, with two goals: 1. that the minimal vtbl be just that, minimal 2. that it be

Re: RFC 136 (v2) Implementation of hash iterators

2000-09-05 Thread Tom Hughes
In message [EMAIL PROTECTED] Dan Sugalski [EMAIL PROTECTED] wrote: Or have a "next" vtable function that takes a token and returns the next entry in the variable. Each iterator keeps its own "current token" and the variable's just responsible for figuring out what should get

Re: RFC 179 (v1) More functions from set theory to manipulate arrays

2000-09-05 Thread John Porter
David L. Nicol wrote: For sets, hashes are a better perl representation. I think you must have missed some of this discussion. Rather than reiterate my contributions, I'll point you into the archive: http://www.mail-archive.com/perl6-language%40perl.org/msg03425.html

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

2000-09-05 Thread Bart Lateur
On Tue, 05 Sep 2000 11:48:38 -0400, Dan Sugalski wrote: - two-phase commit handler, rollback coordinator (the above two is connected to this: very simple algorhythm!) Here's the killer. This is *not* simple. At all. Not even close. Doing this properly with data sources you completely

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

2000-09-05 Thread Dan Sugalski
At 01:42 AM 9/4/00 +0200, dLux wrote: What it needs in the core is pretty small btw: I think you underestimate things here a tad... - a new keyword, which is similar to "local" Okay, that's small. - some extension to the TIE interface (some new callbacks) As is this. - some extension to the

Re: RFC 178 (v2) Lightweight Threads

2000-09-05 Thread Dan Sugalski
At 10:57 PM 9/4/00 -0400, Chaim Frenkel wrote: "SWM" == Steven W McDougall [EMAIL PROTECTED] writes: PRL All threads share the same global variables _All_ or only as requested by the user (ala :shared)? SWM All. Dan has gone through this with perl5 and he really would rather not have to

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

2000-09-05 Thread dLux
/--- On Tue, Sep 05, 2000 at 11:48:38AM -0400, Dan Sugalski wrote: | - two-phase commit handler, rollback coordinator (the above two | is |connected to this: very simple algorhythm!) | | Here's the killer. This is *not* simple. At all. Not even close. | | Doing this properly with data

Re: RFC 72 (v3) Variable-length lookbehind: the regexp engine should also go backward.

2000-09-05 Thread Bart Lateur
On Sat, 2 Sep 2000 15:16:20 -0400, Peter Heslin wrote: This looks more natural to me: /(?`!G+A+T+)GA+C/ Your version is closer to the way lookbehind works now, so this syntax might be thought to be clearer; I should add to the RFC an explicit note about this. Look at your original

Re: RFC 145 (alternate approach)

2000-09-05 Thread Richard Proctor
On Tue 05 Sep, David Corbin wrote: Nathan Wiger wrote: But, how about a new ?m operator? /(?m|[).*?(?M|])/; Let's combine yor operator with my example from above where everything inside the (?m) or the ?(M) fits the syntax of a RE. /(?m()|\[).*?(?M()|(\]))

Re: RFC 145 (alternate approach)

2000-09-05 Thread Eric Roode
I think David's on to something good here. A major problem with holding the bracket-matching possibilities in a special variable (or a pair of them) is that one can't figure out what the RE is going to do just by looking at it -- you have to look elsewhere. Nathan Wiger wrote: I think it's cool

Re: RFC 178 (v2) Lightweight Threads

2000-09-05 Thread Chaim Frenkel
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS I'd definitely rather perl not do any sort of explicit user-level locking. DS That's not our job, and there be dragons. Please explain how this is possible? Does this mean that without user specifying a lock, perl will allow a chaotic update

Re: RFC 178 (v2) Lightweight Threads

2000-09-05 Thread Steven W McDougall
DS I'd definitely rather perl not do any sort of explicit user-level locking. DS That's not our job, and there be dragons. Please explain how this is possible? Just say no...to locks. Does this mean that without user specifying a lock, perl will allow a chaotic update pattern to be

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

2000-09-05 Thread Jarkko Hietaniemi
Doing this properly with data sources you completely control in a multi-access situation (read: with threads) is *hard*. Is it? Here's some high-level emulation of what it should do. eval { my($_a, $_b, $c) = ($a, $b, $c); ... ($a,

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

2000-09-05 Thread Bart Lateur
On Tue, 5 Sep 2000 10:48:45 +0200, dLux wrote: /--- On Mon, Sep 04, 2000 at 07:18:56PM -0500, Greg Rollins wrote: | Will perl monitor the commit and rollback actions of transactions? \--- What exactly you mean? And did you have to quote 500+ lines of the RFC just to add this one sentence? --

Re: RFC 127 (v1) Sane resolution to large function returns

2000-09-05 Thread Chaim Frenkel
"GL" == Glenn Linderman [EMAIL PROTECTED] writes: GL Chaim Frenkel wrote: ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become # $foo=1 $baz=2 @bar=(4) GL Actually?

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

2000-09-05 Thread Greg Rollins
Will perl monitor the commit and rollback actions of transactions? - Original Message - From: "Perl6 RFC Librarian" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, September 04, 2000 4:35 PM Subject: RFC 130 (v5) Transaction-enabled variables for Perl6 This

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

2000-09-05 Thread dLux
/--- On Mon, Sep 04, 2000 at 07:18:56PM -0500, Greg Rollins wrote: | Will perl monitor the commit and rollback actions of transactions? \--- What exactly you mean? dLux -- This message is READ-ONLY