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

> 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

> In order to work with lists of arbitary size, it is often necessary to > split a list into equal sized sub-lists. A C 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 C keyword toforce list context (like C))

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

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

Re: Profiling

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

Re: RFC 178 (v1) Lightweight Threads

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

Re: RFC 145 (alternate approach)

I never saw one comment on this, and the more I think about it, the more I like it. So, I thought I'd throw it back out one more time...(If I get no comments this time, I'll be quiet :) David Corbin wrote: > > I haven't given this a WHOLE lot of thought, so please, shoot it full > of holes. > >

Re: RFC 145 (alternate approach)

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

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 q

Re: Proposed RFC for matrix indexing and slicing

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

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

Piers Cawley wrote: > > Well, you keep advancing this idea which has, as far as I can tell, no > upside apart from the reduction in keystrokes required to instantiate > an object. And in doing that you remove useful functionality from a > bunch of other cases. > > No wonder we're down on the ide

Re: RFC 110 (v3) counting matches

On Thu, Aug 31, 2000 at 12:52:23PM -0400, Joe McMahon wrote: > > /($pat1)($pat2)($pat3)(?{sub1(@\)$pat4|?{sub2(@\)}$pat5|?{sub3(@\)})/ > > This would translate to "if pat1pat2pat3 matches, call sub1 with all the > matches to that point if pat4 matches afterward, otherwise call s

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

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 t

Re: RFC 145 (alternate approach)

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

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

At 01:45 PM 9/4/00 -0600, Tom Christiansen wrote: > >package main; > >sub fn { return (3, 5, 7) } > >tie $x, 'MaiTai'; > >$x = fn; > >$ /tmp/foo > >STORE: 7 > > >Why don't I see three STOREs? > >Because Perl is too clever to bother. :-) Hey, waitaminute. That isn't a list in sub fn in the first

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

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

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

>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: The distinction between "do BLOCK while COND" and "EXPR while COND" should go

At 01:20 PM 9/3/00 +1100, Damian Conway wrote: >> Modulo some superpositional silliness, > >Hey! I resemble that remark! > >Damian I guess this means we should expect a N'Yuk module some time in the future... -- Peter Scott Pacific Systems Design Technologies

Re: RFC 145 (alternate approach)

Eric Roode wrote: > > Unfortunately, as Richard Proctor pointed out, ?m is taken. Perhaps > (?[list|of|openers) and (?]list|of|closers) ? > > Does that look too bizarre, with the lone square bracket in each? > Or does that serve to make it mnemonic (which is my intention)? Actually, I persona

Re: RFC 145 (alternate approach)

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 wi

Re: RFC 145 (alternate approach)

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,

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

Damian Conway wrote: > > Stupid, stupid, stupid! Of course, that should be: > > attr3 => __ALL__ > > and then delegated methods can be named any(crazy)thing. Damn, Damian, don't be so hard on yourself! You're right about __ALL__, of course, but I suspect that most of us would have a pr

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

> >> This way, I know that an empty arrayref means "all methods" > >> rather than "none." > > > > Kinda redundant since that's the default behaviour, but perhaps > > useful as a documentation mechanism. > > Unless you change the default behavio[u]r to "don't delegate

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

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

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 -- C -- that limits the > accessibility of keys in a hash, and of methods. Its primary use would be to > provide encap

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

> use delegation > attr1 => [qw( method1 method2 method3 )], > attr2 => [qw( method4 method5 )], > attr3 => __ALL__, # Use all of them. > attr4 => []; # Use none of them. > > Yes, I realize that not putting attr4 in there at all is the same > (default)

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

> 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

Too early in the morning, I wrote: >> I might like to see something like URI suggested: >> >> attr3 => [ALL] > > It was (and is) a good suggestion. I suspect however that it should be > > attr3 => [__ALL__] > > so that classes can still have an C

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

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

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 C method delegated. > (Yes, now they can't have an C<__ALL__> method, > but maybe that's a Good Thing ;-) Agreed. Yes, that's very goo

Re: RFC 145 (alternate approach)

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

Re: RFC 145 (alternate approach)

Nathan Wiger wrote: > >"normal" "reversed" >-- --- >{__A1( )A1__} That should be: {__A1( )1A__} Why you would delimit text this way I have no idea, but it could still work... -Nate

Re: RFC 145 (alternate approach)

David Corbin wrote: > > I've got some vague ideas on solving all of these, I'll go into if > > people like the basic concept enough. not just in regexes, but in general, a way to extend the set of bratches that Perl knows about would be very nice. for instance it is very difficult for people us

Re: RFC 91 (v2) Builtin: part

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 C function is proposed > > that achieves this: > > Are the sublists copies or aliases? I imagine they are aliases, > but this could be specified in the

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

On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote: > The proposed delegation mechanism would work via a pragma: > > use delegation > attr1 => [qw( method1 method2 method3 )], > attr2 => [qw( method4 method5 )], > attr3 => [], >

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

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

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

> > mark the entire hash as non-autovivifying (except via future calls to > > C -- see below) > > This bothers me. Name an operation in perl that, when applied to a single > element of an aggregate, affects all other elements of the aggregate > (especially future, as-yet-unborn

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

> exists (sometimes causes autovivification, which affects C) That's not technically accurate--exists never causes autovivification. --tom

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

When you want to turn off an inherited delegation in an ISA situation? "David E. Wheeler" wrote: > > 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 =>

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

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

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

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

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

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Objects : Core support for method delegation I *want* this. Delegation is cool. Delegation that gets set up at compile time and is marked as such

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

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 del

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

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 pr

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

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 forgott

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

At 04:40 PM 9/5/00 -0700, Jon Ericson wrote: >Bart Lateur wrote: > > For input, the handle is marked as a source: > > > > $data = ; > > > > In order to be symmetrical, your ousput handle should look and act like > > a sink: > > > > >STDOUT< = $data; > > > > There. Now it's symmetri

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

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

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

>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 ) >The main point of this statement is the Sc

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

Tom Christiansen wrote: > Perl already *has* a print operator: "print". :-) I think what I really want is a tee operator. > The problem with what you have there is that it hides the act of > output within an arbitrarily long circumfix operator whose terminating > portion is potentially very far

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

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

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

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

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

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

>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 (v3) Perl should have a print operator

Bart Lateur wrote: > For input, the handle is marked as a source: > > $data = ; > > In order to be symmetrical, your ousput handle should look and act like > a sink: > > >STDOUT< = $data; > > There. Now it's symmetrical. = $data; is symmetrical. I am considering thi

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

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 Perl should have a print operator

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 ? > Tom Christiansen's complaint seems irrelevant to me because a print > statement i

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

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

Re: code repository

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

Re: RFC 39 Perl should have a print operator

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

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

> > exists (sometimes causes autovivification, which affects C) > > That's not technically accurate--exists never causes autovivification. print keys %hash, "\n"; exists $hash{key}{subkey}; print keys %hash, "\n"; Or did that get fixed when I wasn't looking

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

> > > exists (sometimes causes autovivification, which affects C) > > > > That's not technically accurate--exists never causes autovivification. > print keys %hash, "\n"; > exists $hash{key}{subkey}; > print keys %hash, "\n"; >Or did that get fixed when I wasn't looki

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

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

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

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

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

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 C would also need to DWIM, presumably by retu

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

On Wed, 6 Sep 2000 05:33:27 +1100 (EST), Damian Conway wrote: >A scalar context C would also need to DWIM, presumably by returning >"0, but true" in that (unusual) situation. I don't understand the existence of that phrase, and the fact that it doesn't give a warning when used in numerical cont

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

> > A scalar context C 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 the

YAVTBL: yet another vtbl scheme

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 pos

Re: RFC 136 (v2) Implementation of hash iterators

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 r

Re: RFC 136 (v2) Implementation of hash iterators

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: >> This could be a lot more efficient than modifying the vtbl and filling >> up the stack with the keys. I really am suspicious of replacing the >> vtbl entry, there may be more than one thread working its way through >> the hash. DS> Or hav

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

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 http://www.mail-

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

> > =head1 ABSTRACT > > When programming in perl we need really often to calculate > union, intersection, difference between arrays. It will be > cool if such functions could be part of the perl6 language. Arrays/Lists are ordered, sets are not. For sets, hashes are a better perl representati

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

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 comple

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

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

Re: RFC 136 (v2) Implementation of hash iterators

At 08:18 PM 9/4/00 -0400, Chaim Frenkel wrote: > > "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > >PRL> =head2 Freezing state for keys and values efficiently > >PRL> I believe this problem can be solved by using the vtable for the >PRL> hash to wrap any mutating functions with a co

Re: RFC 178 (v2) Lightweight Threads

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

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

/--- 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 130 (v4) Transaction-enabled variables for Perl6

/--- On Tue, Sep 05, 2000 at 10:57:30PM -0400, Chaim Frenkel wrote: | > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: | | >> Now, "all" that needs to be taken care of, is make sure that | >> the final | >> assignment from the localized and changed variables to their | >> outer-sco

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

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 orig

Re: RFC 145 (alternate approach)

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(<<)|\[)

Re: RFC 145 (alternate approach)

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(<<)|\[)

Re: RFC 145 (alternate approach)

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: Change "($one, $two)=" behavior for optimization? (was Re:RFC 175 (v1) Add C keyword to force list context (likeC))

Peter Scott wrote: > > At 11:48 AM 9/3/00 +1100, Damian Conway wrote: > >> Ever consider then having > >> > >> ($a, $b, $c) = ; > >> or > >> @a[4,1,5] = ; > >> > >> only read three lines? > > > >I think this is a superb idea, and look forward to someone's RFC'i

Re: RFC 178 (v2) Lightweight Threads

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

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

> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: >> Now, "all" that needs to be taken care of, is make sure that the final >> assignment from the localized and changed variables to their >> outer-scoped counterparts happens in *one step*, i.e. no task switching >> while this is going o

Re: YAVTBL: yet another vtbl scheme

> "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes: BS> variables BS> "know" how to perform ops upon themselves. An operation is BS> separate from the data it operates on. Therefore, I propose BS> the following vtbl scheme, with two goals: The point is to avoid the switches. There is no ne

Re: RFC 178 (v2) Lightweight Threads

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

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

> >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); > ... >

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

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

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

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

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 >

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

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