Re: RFC 132 (v3) Subroutines should be able to return an lvalue

2000-09-01 Thread Johan Vromans
[Quoting Nathan Wiger, on August 31 2000, 14:40, in "Re: RFC 132 (v3) Sub"] > > sub param { > > my ($self, @rest) = @_; > > $self->{aval} = @rest if @rest; # See note > > lreturn $self->{aval}; > > } > > I've been thinking about this for a couple days. The only problem I see >

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

2000-09-01 Thread Gael Pegliasco
Eric Roode wrote: > Adjust your thinking a bit, not the language. Try: >%my_fruit_set = (orange => 1, lemon => 1); >or >@my_fruit_set{qw/orange lemon/} = (); Yes, probably, this could be easiest... :) But, maybe because I'm a mulish person, I still thinking that if we actually use such

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

2000-09-01 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Variable-length lookbehind: the regexp engine should also go backward. =head1 VERSION Maintainer: Peter Heslin <[EMAIL PROTECTED]> Date: 9 Aug 2000 Last Modified: 1 Sep 2000 Mailing List: [EMAIL PR

RFC 191 (v1) smart container slicing

2000-09-01 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE smart container slicing =head1 VERSION Maintainer: David Nicol <[EMAIL PROTECTED]> Date: 1 September 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 191 Status: Developing =head1 ABSTRA

RFC 188 (v1) Objects : Private keys and methods

2000-09-01 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects : Private keys and methods =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 1 September 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 188 Status: Developing

RFC 187 (v1) Objects : Mandatory and enhanced second argument to C

2000-09-01 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects : Mandatory and enhanced second argument to C =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 1 September 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 187 S

RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-01 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects : Hierarchical calls to initializers and destructors =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 1 September 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number:

RFC 190 (v1) Objects : NEXT pseudoclass for method redispatch

2000-09-01 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects : NEXT pseudoclass for method redispatch =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 1 September 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 190 Status

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

2000-09-01 Thread Tom Christiansen
>=head2 Private methods >The C keyword could also be applied to subroutines, to restrict >where they may be called. Access rules similar to those for private hash >entries would apply: >package Base; > >sub new { ... } > >private sub check { ... } >

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

2000-09-01 Thread Tom Christiansen
>=head1 REFERENCES >Christiansen & Torkington, I, pp. 470-472. >Conway, I, pp. 309-326. One might add refs to Camel-3's new OO chapter on privacy approaches. --tom

Re: RFC 181 (v1) Formats out of core / New format syntax

2000-09-01 Thread H . Merijn Brand
On 31 Aug 2000 06:28:10 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote: Being one of world's active format users, I have to comment. > Formats out of core / New format syntax > Currently, the general consensus is that formats aren't widely used > enough to justify their living in the core

Re: perl6-language-regex summary for 20000831

2000-09-01 Thread Peter Heslin
On Thu, Aug 31, 2000 at 12:34:05PM -0400, Mark-Jason Dominus wrote: > > perl6-language-regex > > Summary report 2831 > > RFC 72: The regexp engine should go backward as well as > forward. (Peter Heslin) > > This topic did not attract much discussion until the very end of the > week

Re: RFC 181 (v1) Formats out of core / New format syntax

2000-09-01 Thread H . Merijn Brand
Why private and not on perl6? Posted this to both, hope you don't care. On Fri, 1 Sep 2000 13:11:53 +0200 (CEST), [EMAIL PROTECTED] (Johan Vromans) wrote: > [Quoting H.Merijn Brand, on September 1 2000, 11:02, in "Re: RFC 181 (v1) For"] > > > Is there any reason left to maintain formats as somet

Re: Proposed RFC for matrix indexing and slicing

2000-09-01 Thread Karl Glazebrook
Larry Wall wrote: > > Karl Glazebrook writes: > : I have a lot of respect for Larry, but as a scientist I distrust all this > : deference to one single authority. > > Well, sure, but someone still has to decide who gets the grants. :-) But it's not always the same person. > : I don't know if

Re: n-dim matrices

2000-09-01 Thread Karl Glazebrook
Jeremy Howard wrote: > > The RFCs I envisage are: > > - Overview of matrix RFCs > - Notation for declaring and creating matrices > - Notation for declaring sparse matrices > - Notation for indexing matrices with a LOL as an index > - ';' for slicing matrices > - @#mat for getting the dimen

Re: n-dim matrices

2000-09-01 Thread Karl Glazebrook
Buddha Buck wrote: > > At 08:10 AM 9/1/00 +1200, Christian Soeller wrote: > > >No, at least 18. One more piece of semantics that would be appreciated > >is optional omission of trailing dimensions in slices, e.g. for a 3-dim > >@a: > > > > @a[0:1] == @a[0:1;] == @a[0:1;;] > > Would you go for

Re: Upcoming RFC's...

2000-09-01 Thread Karl Glazebrook
I would rather see one largeish RFC integrating all these. More RFCs are not necessarily better. "Advanced Perl Multi-dimensional notation". And n-dim things are not necessarily matrices. Karl Buddha Buck wrote: > > If I'm stepping on toes here, please tell me... > > Here are some suggestion

Re: the C JIT

2000-09-01 Thread John Porter
Ken Fox wrote: > Perl is more like lisp with a good syntax -- in other > words about as far from C as you can get. I agree 100%. -- John Porter

Re: the C JIT

2000-09-01 Thread John Porter
David L. Nicol wrote: > Ken Fox wrote: > > . The real problems of exception handling, closures, dynamic > > scoping, etc. are just not possible to solve using simple C code. > > > > - Ken > > I'm not talking about translating perl to C code, I'm talking about > translating perl to machine langua

Re: the C JIT

2000-09-01 Thread John Porter
Uri Guttman wrote: > > the best fit is the TIL (threaded inline code) model we have > discussed. Yes! -- John Porter

Re: A tentative list of vtable functions

2000-09-01 Thread Dan Sugalski
At 11:11 AM 9/1/00 -0400, Chaim Frenkel wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > >DS> Okay, here's a list of functions I think should go into variable vtables. >DS> Functions marked with a * will take an optional type offset so we can >DS> handle asking for various permuta

Re: A tentative list of vtable functions

2000-09-01 Thread Dan Sugalski
At 10:46 PM 8/31/00 +, David L. Nicol wrote: >Dan Sugalski wrote: > > > > Okay, here's a list of functions I think should go into variable vtables. > >All the math functions are in here. Can the entries that my type does >not use be replaced with other functions that my type does use? That's

Re: A tentative list of vtable functions

2000-09-01 Thread Dan Sugalski
At 01:44 AM 9/1/00 -0400, Bradley M. Kuhn wrote: >Dan Sugalski wrote: > > At 04:59 PM 8/31/00 -0400, Buddha Buck wrote: > > >At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote: > > >>Okay, here's a list of functions I think should go into variable > vtables. > > >>Functions marked with a * will take a

Re: A tentative list of vtable functions

2000-09-01 Thread Dan Sugalski
At 01:49 AM 9/1/00 -0400, Bradley M. Kuhn wrote: >Dan Sugalski wrote: > > > > get_value > > > > set_value > > > The get/set value functions are for when something knows what the SV (or > > whatever we call it) really is and can handle the raw data. For example, > > if my code knew a SV he

Re: A tentative list of vtable functions

2000-09-01 Thread Chaim Frenkel
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> Okay, here's a list of functions I think should go into variable vtables. DS> Functions marked with a * will take an optional type offset so we can DS> handle asking for various permutations of the basic type. DS> type DS> nam

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

2000-09-01 Thread Gael Pegliasco
John Porter wrote: > > Buddha Buck wrote: > > > > In a hash implementation, your hash keys -are- your set elements! > > > > my %set; > > > > # add elements to %set > > $set{'elem1','elem2'} = 1; > > > > # Compute union > > $union{keys %set1, keys %set2} = 1; > > Oh, yeah, using native hashes for

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

2000-09-01 Thread Tom Christiansen
>But, Do you really think that all these ingenuities, to not use another >term, are really natural and easy to understand to novice programmers ? Until you start thinking of terms of hashes, you aren't thinking in Perl. It serves no good to delay this epiphany. Also, remember that being a "novi

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

2000-09-01 Thread Gael Pegliasco
Tom Christiansen wrote: > Until you start thinking of terms of hashes, you aren't thinking > in Perl. It serves no good to delay this epiphany. Also, remember > that being a "novice" is a temporary and curable condition. Perl > is designed to for long-term ease of use, not short-term learn-fre

Re: RFC 175 (v1) Add C keyword to force list context (like C)

2000-09-01 Thread Bart Lateur
On Fri, 01 Sep 2000 07:30:54 -0600, Tom Christiansen wrote: > % man perldata > > List assignment in a scalar context returns the number of > elements produced by the expression on the right side of > the assignment: > > $x = (($foo,$bar) = (3,2,1)); # set $x to

Re: RFC 175 (v1) Add C keyword to force list context (like C)

2000-09-01 Thread Tom Christiansen
>To be consistent, "scalar list" should return the number of elements. Says who? $x = ("foo", "bar") produces "bar", not 2. It's all a big looney tune. "scalar list" makes negative sense. If you want a count function, write one, but don't pretend that "scalar list" is such a thing, nor that "s

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

2000-09-01 Thread John Porter
Buddha Buck wrote: > > In a hash implementation, your hash keys -are- your set elements! > > my %set; > > # add elements to %set > $set{'elem1','elem2'} = 1; > > # Compute union > $union{keys %set1, keys %set2} = 1; Oh, yeah, using native hashes for sets -- what could be simpler? (Hint: @s

Re: RFC 175 (v1) Add C keyword to force list context (like C)

2000-09-01 Thread Tom Christiansen
Bart, until you've read my long message, you're wasting my time. Please read it. --tom

Re: the C JIT

2000-09-01 Thread David L. Nicol
Nathan Wiger wrote: > > "David L. Nicol" wrote: > > > > my dog $spot; > > to > > dog spot; > > > > If we only allow this where enough info is available to allocate dog-sized > > pieces of memory directly, Perl can blaze through the code that deals with > > dogs. > > I don't see w

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

2000-09-01 Thread Tom Christiansen
>If it were possible to assign to the keys of a hash, we'd be >a lot closer to our ideal: > keys(%intersection) = map { exists $set1{$_} ? ( $_ => 1 ) : () } keys >but this is not currently legal perl. keys %HASH = LIST; is really @HASH{ LIST } = (); --tom

proto-RFC: keys(HASH) as lvalue (was Re: RFC 179 )

2000-09-01 Thread John Porter
Tom Christiansen wrote: > >If it were possible to assign to the keys of a hash, we'd be > >a lot closer to our ideal: > > > keys(%intersection) = map { exists $set1{$_} ? ( $_ => 1 ) : () } keys > > >but this is not currently legal perl. > > keys %HASH = LIST; > > is really > > @HAS

Re: proto-RFC: keys(HASH) as lvalue (was Re: RFC 179 )

2000-09-01 Thread Tom Christiansen
>> keys %HASH = LIST; >> is really >> @HASH{ LIST } = (); >Sure. Would you have any great objection to adding the alternative syntax? Nope. --tom

Re: perl6-language-regex summary for 20000831

2000-09-01 Thread Mark-Jason Dominus
> On Thu, Aug 31, 2000 at 12:34:05PM -0400, Mark-Jason Dominus wrote: > > > > perl6-language-regex > > > > Summary report 2831 > > > > RFC 72: The regexp engine should go backward as well as > > forward. (Peter Heslin) > > > > This topic did not attract much discussion until the v

Re: Proposed RFC for matrix indexing and slicing

2000-09-01 Thread David L. Nicol
Buddha Buck wrote: > > Boy, there are a lot of people on that CC: list... Anyone want off > this ride? > > How would you recommend the RFC breakdown? > > Use ";" for matrix index separator > Use named iterators for matrix indices > > anything else? Everyone else is way past brainstormin

Re: a syntax derived from constant-time hash-based n-dim matrices in perl 5

2000-09-01 Thread David L. Nicol
Nathan Wiger wrote: > Well, this is not bad, only it's not without its problems. Say you > wanted to get your indices implicitly: > > @a[getindices()]; > @a[$r->get_x, $r->get_y]; @a["@{\(getindices())}"]; @a[join $",$r->get_x, $r->get_y]; > Either of these could ret

Re: a syntax derived from constant-time hash-based n-dim matrices in perl 5

2000-09-01 Thread Nathan Wiger
"David L. Nicol" wrote: > > @a["@{\(getindices())}"]; > @a[join $",$r->get_x, $r->get_y]; My point exactly by these statements: > > Either of these could return an arrayref, but forcing quotes around them > > means you'll need inbetweener variables or the @{} construct, neither

Re: a syntax derived from constant-time hash-based n-dim matrices in perl 5

2000-09-01 Thread Karl Glazebrook
"David L. Nicol" wrote: > > Nathan Wiger wrote: > > > Well, this is not bad, only it's not without its problems. Say you > > wanted to get your indices implicitly: > > > > @a[getindices()]; > > @a[$r->get_x, $r->get_y]; > > @a["@{\(getindices())}"]; > @a[join $",$r->ge

Re: a syntax derived from constant-time hash-based n-dim matrices in perl 5

2000-09-01 Thread David L. Nicol
Nathan Wiger wrote: > I don't think array indices > are something that we should have to go to such lengths to get. I'd > rather have a somewhat-confusing ; or , based syntax than the above. If > anything that's *more* confusing and harder to read. > > -Nate you're right. What if they both wo

Re: the C JIT

2000-09-01 Thread David L. Nicol
Sam Tregar wrote: > > On Thu, 31 Aug 2000, David L. Nicol wrote: > > > We're talking about making a faster Perl. C's syntax requires enough > > clarity to compile to something quick. it is a very short hop from > > my dog $spot; > > to > > dog spot; > > What about the second versi

Re: proto-RFC: keys(HASH) as lvalue (was Re: RFC 179 )

2000-09-01 Thread Bart Lateur
On Fri, 1 Sep 2000 10:23:27 -0400, John Porter wrote: >> keys %HASH = LIST; >> >> is really >> >> @HASH{ LIST } = (); > >Sure. Would you have any great objection to adding the alternative syntax? I have some doubts. See perlfunc -f keys, from which I quote: If you say k

Re: proto-RFC: keys(HASH) as lvalue (was Re: RFC 179 )

2000-09-01 Thread John Porter
Bart Lateur wrote: > > If you say > > keys %hash = 200; > > then `%hash' will have at least 200 buckets allocated for > it--256 of them, in fact, since it rounds up to the next power > of two. This should go away, of course. -- John Porter

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

2000-09-01 Thread Eric Roode
I wonder if it might not be a good idea to implement a function to compute the intersection of two sets-as-hashes. Intersection is the only basic set function that's not trivially implementable with perl hashes. Sure, it's not hard to do, with a loop and a small bit of programming, but maybe it

Re: the C JIT

2000-09-01 Thread Nathan Wiger
"David L. Nicol" wrote: > > They gain us compliance with the whims of the people who like barewords > for variable names. You may or may not find that to be a good thing. It's not just that I don't think dropping $'s is a good idea, but that is the general consensus as well. I can't see dog

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

2000-09-01 Thread John Porter
Eric Roode wrote: > I wonder if it might not be a good idea to implement a function to > compute the intersection of two sets-as-hashes. > > Intersection is the only basic set function that's not trivially > implementable with perl hashes. Sure, it's not hard to do, with > a loop and a small bi

Re: RFC 175 (v1) Add C keyword to force list context (like C)

2000-09-01 Thread Steve Fink
> for reality here. That should be written more like: > > 1 while ; $burp = $.; > > or even: > > for ($burp = 0; my $line = ; $burp++) {} I'd go for my $burp = 0; $burp++ while ; > This proposal should be dropped. I read your message and agree. Not that I liked the

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

2000-09-01 Thread Michael Fowler
On Fri, Sep 01, 2000 at 11:58:20AM +0200, Bart Lateur wrote: > First: I don't like the idea of some user supplied code being called > whenever you declare a new variable, *unless* the author of the class > created a sub *especially written* for this purpose. And that's what the RFC states. If th

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

2000-09-01 Thread Michael Fowler
On Fri, Sep 01, 2000 at 12:20:34PM +0100, Hildo Biersma wrote: > Michael Fowler wrote: > > > > On Fri, Sep 01, 2000 at 08:31:17AM +0100, Hildo Biersma wrote: > > > My previous concerns have not been adressed: > > > - There may not be a default constructor > > > > If there is no implicit construc

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

2000-09-01 Thread Michael Fowler
On Fri, Sep 01, 2000 at 05:23:27PM +0200, Slaven Rezic wrote: > Often, there is the case that "my" is used before actually assigning a > value to it. For example: > > my Foo $foo; > if ($cond1) { > $foo = new Foo 1, 2, 3; > } else { > $foo = new Foo 2, 4, 6; > } > > I

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

2000-09-01 Thread Michael Fowler
On Fri, Sep 01, 2000 at 11:41:47AM -0700, David E. Wheeler wrote: > Michael Fowler wrote: > > > > my Dog $spot; # $spot is now a blessed Dog object > > $spot->name("Fido");# $spot->{'name'} eq "Fido" > > > > print ref $spot;# yes, "Dog" > > > > $spot = new

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

2000-09-01 Thread Michael Fowler
On Fri, Sep 01, 2000 at 10:58:36AM -0800, Michael Fowler wrote: > my $spot isa(Dog); This should be my $spot : isa(Dog); Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --

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

2000-09-01 Thread Michael Fowler
On Fri, Sep 01, 2000 at 09:09:15AM -0700, Nathan Wiger wrote: > First off, I think everyone is reading this RFC with the wrong mindset, >my Dog $spot; >print ref $spot;# 'Dog' >$spot = new Dalmation; > > No reason this wouldn't still work. The term 'constructor' here is > misleadi

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

2000-09-01 Thread Michael Fowler
On Fri, Sep 01, 2000 at 10:37:04AM -0800, Michael Fowler wrote: > I would appreciate you giving me the benefit of the doubt that I'm not > intentially misunderstanding you. intentionally > my $spot isa(Foo); This should be my $spot : isa(Foo). Man, these typos are going to be the death o

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

2000-09-01 Thread David E. Wheeler
Michael Fowler wrote: > > On Fri, Sep 01, 2000 at 11:41:47AM -0700, David E. Wheeler wrote: > > Michael Fowler wrote: > > > > > > my Dog $spot; # $spot is now a blessed Dog object > > > $spot->name("Fido");# $spot->{'name'} eq "Fido" > > > > > > print ref $spot;#

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

2000-09-01 Thread Michael Fowler
On Fri, Sep 01, 2000 at 12:35:24PM -0700, David E. Wheeler wrote: > Well then, that makes this example rather wasteful, doesn't it? It wasn't an example of how my Dog $spot should be used. I was explaining to Nate what his code was doing. > my Dog $spot; > if ($input eq 'Collie') { >

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

2000-09-01 Thread Michael Fowler
On Fri, Sep 01, 2000 at 10:46:50AM +0100, Piers Cawley wrote: > Are you wilfully misunderstanding me? I would appreciate you giving me the benefit of the doubt that I'm not intentially misunderstanding you. > Let's try another possible example to see if you get the point: > > print "What

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

2000-09-01 Thread David E. Wheeler
Michael Fowler wrote: > > my Dog $spot; # $spot is now a blessed Dog object > $spot->name("Fido");# $spot->{'name'} eq "Fido" > > print ref $spot;# yes, "Dog" > > $spot = new Dalmation; # now $spot is a Dalmation object Yes, but the Dalmation $spot will *

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

2000-09-01 Thread Michael Fowler
On Fri, Sep 01, 2000 at 10:22:49AM +0100, Piers Cawley wrote: > And then there's: > > - Makes factory methods impossible. my Dog $spot; my $pub = $spot->procreate; Sure looks like a factory method to me. Just because you don't get to say my Dog $pup for some optimization doesn't mean

Re: RFC 178 (v1) Lightweight Threads

2000-09-01 Thread Steven W McDougall
> KF> #!/my/path/to/perl > KF> sub foo_generator { my $a = shift; sub { print $a++ } } > KF> my $foo = foo_generator(1); > KF> $foo->(); > Thread-> new($foo); > KF> Is $a shared between threads or not? If $a is not shared, we've broken > KF> lexicals. > Not unless it is so declar

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

2000-09-01 Thread Chaim Frenkel
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: TC> Well, that depends. Often you must delay till run-time. When Perl TC> simply sees something like: TC> sub fn { return @blah } TC> it can't know whether you'll use that as: TC> $x = fn(); TC> or TC> @x = fn(); TC> or TC>

Re: RFC 178 (v1) Lightweight Threads

2000-09-01 Thread Chaim Frenkel
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes: KF> The more interesting case is this: KF> #!/my/path/to/perl KF> sub foo_generator { my $a = shift; sub { print $a++ } } KF> my $foo = foo_generator(1); KF> $foo->(); Thread-> new($foo); KF> Is $a shared between threads or not?

Re: RFC 185 (v1) Thread Programming Model

2000-09-01 Thread Steven W McDougall
> I'm not completely sure what you are trying to do with this RFC. This RFC describes the programming interface to Perl6 threads. It documents the function calls, operators, classes, methods, or whatever else the language provides for programming with threads. Perl5 has a thread interface, bu

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

2000-09-01 Thread Tom Christiansen
>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >TC> Well, that depends. Often you must delay till run-time. When Perl >TC> simply sees something like: >TC> sub fn { return @blah } >TC> it can't know whether you'll use that as: >TC> $x = fn(); >TC> or >TC> @x = fn(); >T

RFC 56 (v3) Optional 2nd argument to C and C

2000-09-01 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Optional 2nd argument to C and C =head1 VERSION Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]> Date: 7 Aug 2000 Last-Modified: 1 Sep 2000 Version: 3 Mailing List: [EMAIL PROTECTED] Number:

RFC 59 (v2) Proposal to utilize C<*> as the prefix to magic subroutines

2000-09-01 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Proposal to utilize C<*> as the prefix to magic subroutines =head1 VERSION Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]> Date: 7 Aug 2000 Last-Modified: 1 Sep 2000 Mailing List: [EMAIL PROTECT

RFC 74 (v3) Proposal to rename C and C

2000-09-01 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Proposal to rename C and C =head1 VERSION Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]> Date: 8 Aug 2000 Last-Modified: 1 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 3 Number: 74 S

Re: RFC 175 (v1) Add C keyword to force list context (like C)

2000-09-01 Thread Graham Barr
On Fri, Sep 01, 2000 at 11:23:16AM -0700, Steve Fink wrote: > I read your message and agree. Not that I liked the idea that much even > before considering the ramifications. But do you agree that even > seasoned perlers have trouble anticipating how a list/array is going to > be converted to a sca

RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Perl resource configuration =head1 VERSION Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]> Date: 16 Aug 2000 Last-Modified: 1 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 2 Number: 114

Re: the C JIT

2000-09-01 Thread David L. Nicol
Nathan Wiger wrote: > > "David L. Nicol" wrote: > > > > They gain us compliance with the whims of the people who like barewords > > for variable names. You may or may not find that to be a good thing. > > It's not just that I don't think dropping $'s is a good idea, but that > is the general co

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

2000-09-01 Thread Tom Christiansen
The thing is that so far, Perl has survived on extremely simple variable types: SCALAR: singular generic values ARRAY: ordered lists of SCALARs HASH: unordered association of SCALARs Sure, you have special-purpose accessors like the "%" operator or s/// or pop or exists or even v

Re: RFC 175 (v1) Add C keyword to force list context (like C)

2000-09-01 Thread Tom Christiansen
>I read your message and agree. Not that I liked the idea that much even >before considering the ramifications. But do you agree that even >seasoned perlers have trouble anticipating how a list/array is going to >be converted to a scalar? A list or array? No, I don't agree. How to predict what

Re: A tentative list of vtable functions

2000-09-01 Thread Dan Sugalski
At 11:49 AM 9/1/00 -0500, David L. Nicol wrote: >Dan Sugalski wrote: > > > We're shooting for speed here. Any common operation that could be affected > > by the type of the variable should be represented so a custom function can > > be called that does exactly what needs to be done. > > > >

Re: A tentative list of vtable functions

2000-09-01 Thread Chaim Frenkel
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes: NI> Dan Sugalski <[EMAIL PROTECTED]> writes: >> is_equal (true if this thing is equal to the parameter thing) >> is_same (True if this thing is the same thing as the parameter thing) NI> is_equal in what sense? (String, Number, ...) NI>

Re: A tentative list of vtable functions

2000-09-01 Thread Dan Sugalski
At 06:07 PM 9/1/00 +, Nick Ing-Simmons wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > >is_equal (true if this thing is equal to the parameter thing) > >is_same (True if this thing is the same thing as the parameter thing) > >is_equal in what sense? (String, Number, ...) I was thin

Re: A tentative list of vtable functions

2000-09-01 Thread Dan Sugalski
At 10:25 AM 9/1/00 -0700, Larry Wall wrote: >Dan Sugalski writes: >: Anyone got anything to add before I throw together the base vtable RFC? > >So how do you call a generic method? Generic vtable method? You'd have to look up the vtable in the stash that held it and vector in through there. If

Re: A tentative list of vtable functions

2000-09-01 Thread Dan Sugalski
At 10:23 AM 9/1/00 -0700, Larry Wall wrote: >Dan Sugalski writes: >: Type returns a magic cookie value of some sort (Not sure what sort yet), >: name returns a string with the name of the type of the variable. > >Why can't the type object just stringify to the name of the type? I'd figured that t

Re: n-dim matrices

2000-09-01 Thread Jeremy Howard
Karl Glazebrook wrote: > Can we not keep calling them matrices? They are just a special > case. > Normally I call them tensors, but this is only meaningful to a mathematics audience. I was using 'matrix' because both laypersons and mathematicians would know what the RFCs are referring to. This wo

Re: Upcoming RFC's...

2000-09-01 Thread Jeremy Howard
Karl Glazebrook wrote: > I would rather see one largeish RFC integrating all these. More RFCs > are not necessarily better. > The -language WG chair has requested that each RFC contain just one key proposal, and that multiple related RFCs be drawn together with an overview RFC.

Re: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Tom Christiansen
>On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote: >> > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >> >> i think an environment var might be a good way. if it is set, it is the >> >> file(s) to preload before running your code. >> >> TC> You've got PERL5OPT. >> >>

Re: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Tom Christiansen
>What I am thinking of is a file that, if present and sane (i.e. read-only >root), would be involked by the interpreter just before the users script was >parsed. Looking at your example of things in the config file, well some of >those are the things I would like to be able to get at in the new ve

Quantum computing

2000-09-01 Thread Steve Fink
Can't quite run perl yet. http://www.tomshardware.com/cpu/00q3/000901/index.html

Re: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Tom Christiansen
>it can be used for system specific @INC paths without >recompiling perl That's what PERL5LIB is for. enforcing strict/-w/-T on all scripts, etc. How are you going to enable -T from this file you're going to eval? How are you going to enable strict in an unrelated lexical scope? Why are you u

Re: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Uri Guttman
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: TC> How are you going to enable strict in an unrelated lexical scope? TC> Why are you using -w instead of use warnings, and can you just imagine the TC> howling? This would surely kill your system. like i said, i wasn't sure of

Re: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Tom Christiansen
>many systems allow for a global/local startup file for various >reasons. i see a potential use of this in perl but i don't see the >specific use yet. build it they will use it. But Perl is not an interactive shell! Can you imagine if a C compiler allowed arbitrary amounts of text to be pre-inc

Re: RFC 56 (v3) Optional 2nd argument to C and C

2000-09-01 Thread Michael G Schwern
On Sat, Sep 02, 2000 at 09:42:09AM +1100, Jeremy Howard wrote: > I'd like to see negative numbers work. Otherwise the programmer would have > to explicitly check whether an index into a string was positive or negative, > take the absolute value, and use pop() or shift() as appropriate. This has t

Re: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Uri Guttman
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >> i think an environment var might be a good way. if it is set, it is the >> file(s) to preload before running your code. TC> You've got PERL5OPT. but that is the user's to set. PERL_PRELOAD allows the admin to globally set (in t

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

2000-09-01 Thread Nathan Wiger
Tom Christiansen wrote: > > % man perlfunc > ... > When assigning to a list, if LIMIT is omitted, Perl supplies a > LIMIT one larger than the number of variables in the list, to > avoid unnecessary work. As usual I picked a bad example. And I did read the perlfunc manpage, bu

Re: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Michael G Schwern
On Fri, Sep 01, 2000 at 05:49:05PM -0600, Tom Christiansen wrote: > >On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote: > >Like any other environment variable which the admin wants to be > >everywhere, put it in /etc/profile. A well configured system will > >handle it from there. > > N

Re: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Michael G Schwern
On Fri, Sep 01, 2000 at 05:50:52PM -0600, Tom Christiansen wrote: > Why are you using -w instead of use warnings, and can you just imagine the > howling? This would surely kill your system. Okay, okay, okay. You're the nth person that brought that up. Yes, "use warnings" makes more sense than

RE: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Al
>I entreat you to explain to me *anything* that you'd want to tweak >with this that you already can't do right now. When I need to move Perl files from a default location to a new one. For example messing with @INC (and its like). THis could be used for example on a machine that has both develop

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

2000-09-01 Thread Tom Christiansen
>Let me shift gears and instead ask whether anyone thinks this: >> > $y = ($first, $second) = grep /$pat/, @data; >Returning "5" has any value? If you're going to do this, it seems like >you'd want the number that were really returned (since scalar grep >will give you the total number found an

Re: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Tom Christiansen
>>I entreat you to explain to me *anything* that you'd want to tweak >>with this that you already can't do right now. >When I need to move Perl files from a default location to a new one. For >example messing with @INC (and its like). THis could be used for example on >a machine that has both dev

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

2000-09-01 Thread Nathan Wiger
> >Let me shift gears and instead ask whether anyone thinks this: > > >> > $y = ($first, $second) = grep /$pat/, @data; > > >Returning "5" has any value? If you're going to do this, it seems like > >you'd want the number that were really returned (since scalar grep > >will give you the total n

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

2000-09-01 Thread Tom Christiansen
>Well, it only does this if it's not something like 'split', then! Yes, it does "do it" with split. split is defined to do what it does, how it does it. *This* is the kind of senseless harping that annoys me, Nathan. > So it's not 100% consistent. Wrong: It's 100% consistent with the docume

RE: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Al
>That's a fine answer, but a completely different concern. Sorry, you are correct. I looked up the RFC (there are getting to be so many I cannot trust memory any more). What I am thinking of is a file that, if present and sane (i.e. read-only root), would be involked by the interpreter just bef

Re: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Tom Christiansen
>but that is the user's to set. PERL_PRELOAD is there for the user to unset. >allows the admin to globally >set (in the system shell rc file) the rc files that perl will load. And what sorts of things might the admin care to globally set? --tom

Re: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Michael G Schwern
On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote: > > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: > >> i think an environment var might be a good way. if it is set, it is the > >> file(s) to preload before running your code. > > TC> You've got PERL5OPT. > > but that

  1   2   >