Re: partial assignment using lvalue?

Kenneth Lee <[EMAIL PROTECTED]> writes: > dear all, > > it seems all the "lvalue sub" RFCs haven't mentioned this. > currently we can do > > $str = "foo bar"; > substr($str, 4, 0) = "baz "; > > and $str will become "foo baz bar". should we be able to do > this with lvalue-subs? how can on

Re: RFC 159 (v1) True Polymorphic Objects

Damian Conway <[EMAIL PROTECTED]> writes: > > >BTW, this is not just theoretical yearnings. I have written three modules >in the past year that do not work as well as they could, simply because it >is not possible to overload && and ||. > >Damian I have one too. -- Nick Ing-Simmons <[EMAIL PRO

Re: RFC 168 (v2) Built-in functions should be functions

> Date: 27 Aug 2000 > Last Modified: 28 Aug 2000 > Mailing List: [EMAIL PROTECTED] > Version: 2 > Number: 168 > Status: Developing My understanding is that each version of an RFC after the first must have a CHANGES section. This requirement seems to have not been well enforced. --

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

Nathan Wiger <[EMAIL PROTECTED]> writes: >$cgi->param($var) = @val; >$cgi->param($var, @val); You can do that easily: sub param { my ($self, @rest) = @_; $self->{aval} = @rest if @rest; # See note lreturn $self->{aval}; } Note that no assignment in line "# See note"

Re: RFC 165 (v1) Allow Varibles in tr///

On Wed, 30 Aug 2000 00:31:24 -0400, Stephen P. Potter wrote: >For every tr/// in a program, >256 bytes have to be allocated? Even if I only do something like tr/a/A/? >Is this really the optimal solution for this Speedwise, it is. You don't have to do any tests on the bytes. All you have to do

Re: RFC 165: Allow variables in a tr///

"Stephen P. Potter" <[EMAIL PROTECTED]> writes: > Lightning flashed, thunder crashed and Tom Christiansen <[EMAIL PROTECTED] > m> whispered: > | >The // tend to confuse people and make them expect tr to operate as a > | >regular expression. > | > | So what? q/.../ is not a "regex function" eith

Re: RFC 165: Allow variables in a tr///

On Wed, 30 Aug 2000 00:08:46 -0400, Stephen P. Potter wrote: >Personally, I would say that q/.../ and friends were a bad idea. A lot of >non-gurus see /.../ (whatever comes before it) and their first impression >is that it has something to do with regex. I would suggest that anything >that isn'

Re: RFC 110 (v3) counting matches

On Tue, 29 Aug 2000, Mark-Jason Dominus wrote: > OK, I think this discussion should be closed. I think the bit about "having a special array containing all captured matches" might well still live on. The "counting" bit _per se_ is probably fairly closed, though. Cheers, Philip -- Philip Newton

Re: RFC 170 (v1) Generalize =~ to a special-purpose assignment operator

On 30 Aug 2000 02:07:24 -, Perl6 RFC Librarian wrote: >Generalize =~ to a special-purpose assignment operator Personally, I think of it as the "apply to" operator, as opposed to the "assign to" operator: = assign the RHS to the LHS =~ apply the RHS to the LHS pe

Re: Optional Separate Programs for Interpreter Passes

Dan Sugalski wrote: > At 12:58 PM 8/29/00 -0500, Fisher Mark wrote: > >Although Perl interpretation is divided into several passes (parser/lexer, > >optimizer, tree/bytecode runner), all these passes are grouped together in > >one binary. Under some memory-constrained conditions, it could be bett

how small is small? (was Re: RFC 146 (v1) Remove socket functions from core)

Fisher Mark wrote: > How small do we really need to go? Are we looking at implementing Perl for > microcontrollers, or are we only worrying about Perl for PDAs? > On the other hand, microcontrollers still don't have a lot of RAM, at least > as compared to PDAs. I heard that a major mobile te

Re: Removing stuff to shareable thingies

Dan Sugalski wrote: > 2) Having a mechanism to automagically load in chunks of executable code > only when needed would be nice I would take this one a bit further: 2a) It should be possible, at compile-time, to detect what chunks will be needed and perhaps warn the user that they have go

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

/--- On Tue, Aug 29, 2000 at 06:33:41PM -0400, John Porter wrote: | $x = 0; | | sub side { | $x = 1; | } | | trans { | local $x; | side(); | print "x=$x\n"; # should print 1 | die; | } | | print "x=$x\n"; # should print 0 | | Personally, I'd rather see transaction-ena

Re: RFC format

[EMAIL PROTECTED] wrote: > The most common format I've seen in the field so far is to have "Status: > foo" up with the maintainer and version info, where it's easily seen. > Can we do this instead of a separate section? Yes, my original patch made it a separate section, and then we all came to a

Re: Proposal for IMPLEMENTATION sections

On Tue, 29 Aug 2000 17:54:17 -0400, Mark-Jason Dominus wrote: >The IMPLEMENTATION section of the RFC is supposed to be mandatory, but >there have been an awful lot of RFCs posted that have missing or >evasive IMPLEMENTATION sections. I found more than 39% of all RFCs >have a missing or incomplet

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

You are now biting off quite a bit. This is the generic problem that all database systems have to do to handle transactions. I believe that this will increase the deadlock possibilities. Without a transaction, it might have been possible to get in and out of a subroutine without holding the lock

Re: RFC 90 (v2) Builtins: merge() and demerge()

On 30 Aug 2000 01:22:40 -, Perl6 RFC Librarian wrote: >Builtins: merge() and demerge() ??? >It is proposed that two new functions, C, and C, be added >to Perl. C would return a list that >interleaved its arguments. C would reverse >this operation. Ah, now I understand. I did read the previ

Re: Overlapping RFCs 135 138 164

> TC> ($foo += 3) *= 2; >that is way too many assignment ops. better is the normalized > $foo = ($foo + 3) * 2; > TC> $n = select($rout=$rin, $wout=$win, $eout=$ein, 2.5); >who uses select directly anymore? use a module! :) I see the smiley, but one must be exceedingly careful

Re: RFC 165 (v1) Allow Varibles in tr///

On Wed, 30 Aug 2000 11:05:41 +0200, Bart Lateur wrote: >Some processors, >like Intel's x86, even have a special machine instruction to do that: >XLAT. In the meantime, I found an x86 instruction set reference on the web. Here is the description for XLAT:

Re: Proposal for IMPLEMENTATION sections

On Tue, 29 Aug 2000, Mark-Jason Dominus wrote: > Not everyone knows enough about Perl's internal design or about > programming design generally to be able to consider the issues. I > suggest that these people should write to the approrpriate working > group chair and ask to be put in touch with

Re: RFC 165: Allow variables in a tr///

>Personally, I would say that q/.../ and friends were a bad idea. That's one opinion. As Piers points out, it's hardly universal. Go read what I just wrote Uri. >A lot of >non-gurus So what? see /.../ (whatever comes before it) and their first impression >is that it has something to do wit

Re: RFC 165: Allow variables in a tr///

Stephen Potter wrote: >Personally, I would say that q/.../ and friends were a bad idea. A lot of >non-gurus see /.../ (whatever comes before it) and their first impression >is that it has something to do with regex. I would suggest that anything >that isn't a regex should not use /.../. Make q,

Re: RFC 110 (v3) counting matches

> On Tue, 29 Aug 2000, Mark-Jason Dominus wrote: > > > OK, I think this discussion should be closed. > > I think the bit about "having a special array containing all captured > matches" might well still live on. The "counting" bit _per se_ is probably > fairly closed, though. I didn't mean to

Re: RFC 165 (v1) Allow Varibles in tr///

>Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED] >pered: >| > > The way tr/// works is that a 256-byte table is constructed at compile >| > > time that say for each input character what output character is >| > >| > Speaking of which, what's going to happen when there

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

On Tue, Aug 29, 2000 at 05:51:44PM -0500, David L. Nicol wrote: > I'd like to see a last-container-key attribute included as > a possibilty; and that attribute called ":n" to match the > argument of integer functions in introductory algebra. This > approach gives us > > for $a @some_list {

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

>Interesting. I must have missed this. I'm not wild about the syntax, >but I like the idea. If everything become objects under-the-hood, >then we could have: > for $a (@array) { print "$a is at $a->index\n"; } >No, I'm not wild about that either, but it's an idea. I don't perceive why

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

On Wed, Aug 30, 2000 at 08:18:08AM -0600, Tom Christiansen wrote: > I don't perceive why this is so common a need as to require special > magic. And for those cases, a three-part for(;;) loop handles it, > since that tells you the index number directly. Could someone > explain why they need this

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

John McNamara <[EMAIL PROTECTED]> writes: > As far as I can see the current consensus is as follows: > 1. Implicit variable: nice but not really worth the trouble. > 2. Explicit variable between foreach and the array: might conflict > with other proposals. > 3. Explicit cou

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

Michael Fowler wrote: > > Regarding the STORE call, if RFC 159 gets adopted, sure, why not. I'll > mention that alternative in the RFC's next version. Cool. > I need to mention the: > > my int $x; > my int $i = 4; > my int ($x, $y, $z) = (4, 5, 6); > > syntax in the RFC. It des

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

Hildo Biersma wrote: > > I feel this discussion confuses multiple things: > - Is a scalar an object or a reference to an object? The current thinking on this list is that a scalar == an object. That's where this discussion is getting confusing, because people aren't clarifying that this: my

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

Piers Cawley wrote: > > Eeeeww. Most of the time I use 'my Dog $spot' is along the lines > of: > > my Dog $spot = Dog::Dalmation->new(name => 'Spot'); > $spot->bark; No problem, that still works, according to the RFC... >sub bark { >my Dog $self = shift; >print

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

> What, then, happens to the following code: > > my Dog $spot; > if ($age > 12) { > $spot = new Doberman(); > } else { > $spot = new Corgi(); > } This is a tricky case that deserves a lot of attention, but not exactly as written. Imagine this code block: my int ($x, $y, $z) = (4, 5,

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

On Tue, Aug 29, 2000 at 11:04:26PM -0400, Michael Maraist wrote: > First greatly stylistic compatibilty. An inexperienced programmer would > see: > my Dog $spot = "Spot"; > > And become confused. It's totally unintuitive (at least so far as other > mainstream OO languages go). It looks like Do

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

Jonathan Scott Duff wrote: > > On Tue, Aug 29, 2000 at 11:04:26PM -0400, Michael Maraist wrote: > > First greatly stylistic compatibilty. An inexperienced programmer would > > see: > > my Dog $spot = "Spot"; > > > > And become confused. It's totally unintuitive (at least so far as other > > mai

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

Hildo Biersma <[EMAIL PROTECTED]> writes: > Many people see even this as a bad choice, saying that 'explicit' should > be the default, and that C++ constructors should be marked 'implicit' > for this behavior to be allowed. Hmmm... having 'explicit' be implicit and vice versa? I think my head may

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

> Why would the programmer become confused? In C++ (a mainstream OO > language), if a Dog constructor was defined that took a string as an > argument, the string would be auto-converted to a Dog. Yes, C++ implicitly treats single argument constructors as conversion constructors. They convert th

RFC 34 (v3) Angle brackets should not be used for file globbing

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Angle brackets should not be used for file globbing =head1 VERSION Maintainer: Jon Ericson <[EMAIL PROTECTED]> Date: 4 August 2000 Last-Modified: 30 August 2000 Mailing List: [EMAIL PROTECTED] Ver

RFC 39 (v3) Perl should have a print operator

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Perl should have a print operator =head1 VERSION Maintainer: Jon Ericson <[EMAIL PROTECTED]> Date: 5 August 2000 Last-Modified: 30 August 2000 Mailing List: [EMAIL PROTECTED] Version: 3 Number:

RFC 178 (v1) Lightweight Threads

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Lightweight Threads =head1 VERSION Maintainer: Steven McDougall <[EMAIL PROTECTED]> Date: 30 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 178 =head1 ABSTRACT A lightweight thread

RFC 180 (v1) Object Class hooks into C

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Object Class hooks into C =head1 VERSION Maintainer: Mark Biggar <[EMAIL PROTECTED]> Date: 30 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 180 =head1 ABSTRACT There needs to be a

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

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Formats out of core / New format syntax =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 30 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 181 Status: Develop

Re: RFC 172 (v1) Precompiled Perl scripts.

At 11:13 PM 8/29/00 -0400, Michael Maraist wrote: Most of what this RFC (and reply) addresses is sort of up in the air, but I wanted to address one point here. >The way python works is that in the library tree, it looks for any of the >following: >.py, pyc, and .so. > >You can probably guess wh

RE: how small is small? (was Re: RFC 146 (v1) Remove socket funct ions from core)

At 08:05 AM 8/30/00 -0500, Garrett Goebel wrote: >How small? > >I'd like to get barebones Perl and Linux on a 1.44MB floppy... That, I think, is unlikely to happen. Heck, you're hard-pressed to get linux alone on a 1.44M floppy these days... CD? Sure. Zip disk? Yeah, works. Maybe (just maybe) o

Re: RFC 172 (v1) Precompiled Perl scripts.

> For security reasons, I'd much rather the compiled version of anything that > goes into the perl tree be done only at module install time with perhaps > some mechanism to explicitly build (or rebuild) a bytecompiled version. > > Automagically dropping things into places that should be secure

Re: Removing stuff to shareable thingies

At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn wrote: >Dan Sugalski wrote: > > > 2) Having a mechanism to automagically load in chunks of executable code > > only when needed would be nice > >I would take this one a bit further: > > 2a) It should be possible, at compile-time, to detect what chunks wi

Re: how small is small? (was Re: RFC 146 (v1) Remove socket funct ions from core)

On Wed, Aug 30, 2000 at 12:33:53PM -0400, Dan Sugalski wrote: > At 08:05 AM 8/30/00 -0500, Garrett Goebel wrote: > >How small? > > > >I'd like to get barebones Perl and Linux on a 1.44MB floppy... > > That, I think, is unlikely to happen. Heck, you're hard-pressed to get > linux alone on a 1.44M

RE: Optional Separate Programs for Interpreter Passes

Bradley M. Kuhn wrote: > For the world of the JVM port, it's imperative that hooks be > provided so > that the front-end can be run independently, and a different > back-end can be > run (to emit bytecode of some sort). All this also dovetails nicely with the mass-market world of embedded devic

Re: RFC 155 - Remove geometric functions from core

At 07:37 PM 8/29/00 -0700, Russ Allbery wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > > On 29 Aug 2000, Russ Allbery wrote: > > >> I'd love to see Perl aggressively take advantage of new capabilities in > >> dynamic loaders, though. Among other things, I'll point out that > >> symbol version

Re: a garbage collection book

At 11:10 AM 8/30/00 -0500, Jarkko Hietaniemi wrote: >Something for the reference shelf: > > Garbage Collection > Algorithms for Automatic Dynamic Memory Management > Richard Jones & Raphael Lins > John Wiley and Sons, 1996 > ISBN-0-471-94148-4 > >Still haven

a garbage collection book

Something for the reference shelf: Garbage Collection Algorithms for Automatic Dynamic Memory Management Richard Jones & Raphael Lins John Wiley and Sons, 1996 ISBN-0-471-94148-4 Still haven't had time to delve into it but from a quick browse it looks real

Re: a garbage collection book

> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: JH> Introduction JH> The Classical Algorithms (refcounting, mark-and-sweep, copying) JH> Reference Counting (several variants) JH> Mark-Sweep (ditto) JH> Mark-Compact (ditto) JH> Copying (various strategies) JH>

Re: a garbage collection book

On Wed, Aug 30, 2000 at 12:19:35PM -0400, Uri Guttman wrote: > > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: > > JH> Introduction > JH> The Classical Algorithms (refcounting, mark-and-sweep, copying) > JH> Reference Counting (several variants) > JH>

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

> Right now, the default behavior of perl is that un-initialized variables > are automatically undef. It would be weird to have to do explicit > assignment of an variable to say so. You're right. And as another post mentioned, it's too much "magic". But It's hard to come up with a comfortable sy

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

Nathan Wiger wrote: [...] > RFC 164 v2 has a new syntax that lets you do the above or, if you want: > >$this = s/foo/bar/, $that; >@these = s/foo/bar/, @those; > > Consistent with split, join, splice, etc, etc. I often use the comma operator like this s/foo/bar/, $n++ if $x; If "s"

Re: Overlapping RFCs 135 138 164

Tom Christiansen wrote: > > >($foo = $bar) =~ s/x/y/; will never make much sense to me. > > What about these, which are much the same thing in that they all > use the lvaluability of assignment: > > chomp($line = ); > ($foo = $bar) += 10; > ($foo += 3) *= 2; > func($diddle_me =

Out-of-core format syntax (was Re: Globs, (brrr) scalar filehandles, prototypes.)

Peter Scott wrote: > > No-one AFAICT has yet brought up formats, and what would happen to them if > bareword filehandles go the way of the dodo. Here's some thoughts I've been tooling with. If we take advantage of the indirect object syntax, we can actually make format into a member function:

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

Johan Vromans wrote: > > Hi David, > > [Quoting David L. Nicol, on August 29 2000, 19:27, in "Re: RFC 132 (v3) Sub"] > > > With the enhanced C operator, subroutines can dynamically decide > > > what to return. > > > > With context-based polymorphism, the decision can be made staticly. > > Could

RE: RFC 168 (v1) Built-in functions should be functions

John Porter writes: > Ah, the old "If you want Tcl, you know where to find it" non-argument. > > "Closures?""No! This is Perl, not Lisp!" > "Objects?" "No! This is Perl, not Smalltalk!" > "Patterns?""No! This is Perl, not Snobol!" > "Subroutines?" "No! This is Perl, not Basic!" >

RE: Do we really need eq?

Al Lipscomb writes: >I was wondering about maybe being able to store these > attributes as > optional parts of the scalar. Something like this (please > don't get hung up > on the details, I am not much of a designer): > >my($amt,$hours,$total); >$amt->{TYPE} = "DOLLARS"; >$total->{

Re: RFC 52 (v2) List context return from filesystem functions

At 06:40 AM 8/30/00 -0600, Tom Christiansen wrote: > >>My worry is that it seems like this would return > >>an empty list on success, so: > >> > >> @foo = chmod 755, "bar", "baz", "quux" > >> or die "Whoops, died on success!"; > >> > >> > >>This seems to me to go contrary t

RE: RFC 176 (v1) subroutine / generic entity documentation

> #File: Foo.pm > sub foo : doc( In:scalar - int - foo identifier >Out:array - decomposed foo >Effects: Queries Foo DB >Exceptions: DBI, "bad foo id" > EOS > { This is an interesting and powerful idea, but I can't help thinking that it needs to be

Re: RFC 174 (v1) Parse C as C

Damian Conway wrote: > > On a cursory reading, I have no objections to it, if the indirect > object syntax is to be preserved. Thanks for the feedback, I appreciate it. Note, however, that the RFC doesn't just cover indirect object syntax, but also function syntax: $r = new(CGI, @args); # C

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

At 01:26 PM 8/30/00 -0500, David L. Nicol wrote: >Dan Sugalski wrote: > > > > > > >Oh, and then they will be unloaded if we need the space for something > > >else. I understand now, thanks. > > > > Well, probably not, though that could be reasonable for a particular > > platform. It's only releva

Re: RFC 155 - Remove geometric functions from core

On Tue, 29 Aug 2000, Russ Allbery wrote: > Not a big deal, and that's certainly doable. But it's possible to do more > than that if you really want to. The glibc folks have decided to comment > to nearly full binary compatibility for essentially forever; the theory is > that upgrading libc shou

Re: a garbage collection book

On Wed, Aug 30, 2000 at 01:15:39PM -0400, [EMAIL PROTECTED] wrote: > I didn't realize until I read through parts of this exactly how much time a > refcounting GC scheme took. Between that and perl 5's penchant for > flattening arrays and hashes (which creates a lot of garbage itself for > biggi

Re: RFC 155 - Remove geometric functions from core

On Wed, 30 Aug 2000, Andy Dougherty wrote: > On Tue, 29 Aug 2000, Russ Allbery wrote: > > > Not a big deal, and that's certainly doable. But it's possible to do more > > than that if you really want to. The glibc folks have decided to comment > > to nearly full binary compatibility for essenti

Re: a garbage collection book

On Wed, 30 Aug 2000, Joshua N Pritikin wrote: > On Wed, Aug 30, 2000 at 01:15:39PM -0400, [EMAIL PROTECTED] wrote: > > I didn't realize until I read through parts of this exactly how much time a > > refcounting GC scheme took. Between that and perl 5's penchant for > > flattening arrays and has

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

Nick Ing-Simmons wrote: > > David L . Nicol <[EMAIL PROTECTED]> writes: > >"overlay" is reminiscent of old IBM machines swapping parts of the > >program out because there isn't enough core. > > Which is exactly why I chose it - the places these things makes sense are > on little machines where

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

At 01:04 PM 8/30/00 -0500, David L. Nicol wrote: >Nick Ing-Simmons wrote: > > > > David L . Nicol <[EMAIL PROTECTED]> writes: > > > >"overlay" is reminiscent of old IBM machines swapping parts of the > > >program out because there isn't enough core. > > > > Which is exactly why I chose it - the pl

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

Dan Sugalski wrote: > > > >Oh, and then they will be unloaded if we need the space for something > >else. I understand now, thanks. > > Well, probably not, though that could be reasonable for a particular > platform. It's only relevant for a persistent interpreter anyway--for ones > fired up fr

Re: RFC 72 (v2) The regexp engine should go backward as well as forward.

I've been lurking a few days now, and RFC 72 piqued my interest. I see the motivation for a backwards-moving regexp engine, but am uncomfortable with the details. First worry is the syntax proposed. I cringe when I see the regexp being expressed such that "(?r)EDCB" matches "BCDE". That and th

Re: RFC 165 (v1) Allow Varibles in tr///

Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED]> whis pered: | I don't understand what this discussion has to do with this mailing | list, and I don't understand what your point is. tr/// has already This discussion doesn't have anything to do with this list. They w

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

On Wed, 30 Aug 2000, Nathan Wiger wrote: > RFC 164 v2 has a new syntax that lets you do the above or, if you want: > >$this = s/foo/bar/, $that; >@these = s/foo/bar/, @those; > > See RFC 164 v2, all this is supported, as well as this: > >@str =~ s/foo/bar/; > > Which has been a pi

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

Mike Lambert wrote: > > or even: > @a = s/a+/a/, @a; This is actually the native syntax from RFC 164. > Basically, the argument is that you could theoretically do @a =~ s/a+/a/ > with QS, along with many other things. So perhaps, imo, it would be best > to just let QS handle it. I'm fine with t

Re: RFC 165 (v1) Allow Varibles in tr///

On Wed, 30 Aug 2000 10:44:55 -0400, Stephen P. Potter wrote: >| Memory usage is irrelevant compared with speed. > >That's interesting. I could swear I've seen people make a tradeoff before, >rather than always just implementing the fastest solution. Nothing is >irrelevant (except resistance, if

Re: Proposal for IMPLEMENTATION sections

On Tue, Aug 29, 2000 at 07:34:10PM -0700, Nathan Wiger wrote: > Mark-Jason Dominus wrote: > > > > The IMPLEMENTATION section of the RFC is supposed to be mandatory, but > > there have been an awful lot of RFCs posted that have missing or > > evasive IMPLEMENTATION sections. > > Well, I have to c

Re: Proposal for IMPLEMENTATION sections

> Any requirements on how solid an implementation section should be > should be left to the working group chairs. Sorry, I don't understand this. What is the WGC's role here?

Re: Proposal for IMPLEMENTATION sections

On Wed, Aug 30, 2000 at 02:29:33PM -0400, Mark-Jason Dominus wrote: > > > Any requirements on how solid an implementation section should be > > should be left to the working group chairs. > > Sorry, I don't understand this. What is the WGC's role here? My english native language is? :-) I me

Re: Proposal for IMPLEMENTATION sections

> On Wed, Aug 30, 2000 at 02:29:33PM -0400, Mark-Jason Dominus wrote: > > > > > Any requirements on how solid an implementation section should be > > > should be left to the working group chairs. > > > > Sorry, I don't understand this. What is the WGC's role here? > > My english native langua

Re: Do we really need eq?

At 01:31 PM 8/30/00 -0500, David L. Nicol wrote: >Dynamic types-checking slows us down of course, but with both, the >dynmaic type will only be required when it isn;t clear, and that clarity >will keep perl6 instructors with full classrooms. I can guarantee you that keeping instructor's classroom

Re: Do we really need eq?

Fisher Mark wrote: > * Units of measure are optional; > * Units of measure are fast; and > * Implementing units of measure don't appreciably slow down computations > that don't use units of measure. enforced types without automatic conversions does all this, the matches are made once at compile-

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

In a discussion last year about why "foreach my Dog $spot (@Dogs) { ... }" didn't work, Larry brought up an interesting idea... http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-09/msg00962.html Seems reasonable to me. Especially since we might get tremendous compiler speedups

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

On Wed, Aug 30, 2000 at 03:17:59PM -0400, Michael G Schwern wrote: > Its not just objects and classes we're talking about, its types and > variables, too. Remember, Perl ain't all OO yet. Which is further > aggrivated if "my Class $obj" has magical meaning and calls a > constructor. > > Now, we

Re: RFC 174 (v1) Parse C as C

My first reaction to reading this was "Eww!" Upon thinking, its really not a reaction to the RFC, but to indirect object syntax. IMHO I'd really like to see indirect object methods eradicated in Perl 6. Too many precidence problems, too many special cases, too confusing to teach. Muddles up the

Re: New variable type: matrix

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> On Wed, 30 Aug 2000, Christian Soeller wrote: >> A second related question: would I be able to return a list of arrays >> from a function, e.g. >> >> (@fit,@corr) = fitit @x, @y; >> >> How could I find out if the user wants just one arr

Re: Access to the perl6 parser

>>http://www.csse.monash.edu.au/~damian/CPAN/Language-Pythonesque-beta.tar.gz > > How close to a complete Python implementation is it? I can see shipping it > as part of perl 5.8.0 if it's close. 6.0.0, too. (And yes, I'm serious) I'm afraid it isn't Python at all. It's Perl without

RE: how small is small? (was Re: RFC 146 (v1) Remove socket funct ions from core)

Garrett Goebel <[EMAIL PROTECTED]> writes: >How small? > >I'd like to get barebones Perl and Linux on a 1.44MB floppy... > >If it is currently possible, I was possible. At first Perl Conference there was a ZigZag app demoed which came as console-only linux + perl + app. on one floppy. -- Nick

Re: RFC 155 - Remove geometric functions from core

Dan Sugalski <[EMAIL PROTECTED]> writes: >At 07:32 PM 8/29/00 +, Nick Ing-Simmons wrote: >>David L . Nicol <[EMAIL PROTECTED]> writes: >> > >> >Did I not just describe how a .so or a DLL works currently? >> >>And behind the scenes that does something akin to: >> >>int fd = open("file_of_posn_i

Re: RFC 155 - Remove geometric functions from core

On Wed, 30 Aug 2000, Dan Sugalski wrote: > > I think we can pull this off if we're careful and draw really strict lines > about what is and isn't public stuff. It's not easy, and it will mean > we'll have to have some reference executables in a test suite for > verification, but I think we can man

Re: RFC 155 - Remove geometric functions from core

Andy Dougherty <[EMAIL PROTECTED]> writes: > I'm sure the glibc folks indeed work very hard at this and are largely > successful. I also know, however, that over the past couple of years or > so, I've had to recompile nearly all of my applications on several > occasions when I've upgraded glibc.

Re: Proposed RFC for matrix indexing and slicing

(moved to -meta) Karl Glazebrook writes: > > > Yes. And for the record I also think the current approach of lets > > > generate ten million RFCs and Uncle Larry knows best is nuts. > > > There are already too many RFCs on this topic alone to grasp coherently. > > Do you have a better suggestion?

Re: Proposal for IMPLEMENTATION sections

On Wed, Aug 30, 2000 at 04:04:03PM -0400, Mark-Jason Dominus wrote: > > Suppose a WGC establishes a requirement for the solidity of the > implementation section, and receives an RFC that does not meet the > requirements. What then? > If the WGC chair sets forth explicit requirements as to what

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

On Wed, Aug 30, 2000 at 08:22:11AM +0100, Hildo Biersma wrote: > > =head1 TITLE > > > > my Dog $spot should call a constructor implicitly > > > > What, then, happens to the following code: > > my Dog $spot; > if ($age > 12) { > $spot = new Doberman(); > } else { > $spot = new Corgi();

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

>Or if clearly make basic types look *very* different from user-defined >types: > my Dog $spot; > my *int $i; # types that start with * are "basic" Intrinsics (basic types) are in lower-case. User-defined types aren't. our num $Count; my Word @verbs; One wonde

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

At 04:20 PM 8/30/00 -0600, Tom Christiansen wrote: > >Or if clearly make basic types look *very* different from user-defined > >types: > > > my Dog $spot; > > my *int $i; # types that start with * are "basic" > >Intrinsics (basic types) are in lower-case. >User-defined type

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

>Do you really mean to suggest that $SPECIALVARS be (by convention) >uppercase but built in types be (by grammar) lowercase? Absolutely. That's how it's already worked. The pragmata are lowercase module names are reserved to the Core. The type name is the class name, which is the package nam

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

On Wed, Aug 30, 2000 at 05:06:16PM -0400, James Mastros wrote: > I don't see why this needs to be... either: > 1) We clearly define in the beginning that if "Dog" is a basic type, then > this has semi-magical properties. > 2) We clearly define that basic types will always m/^[A-Z]+$/. Or if clear

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

On Tue, Aug 29, 2000 at 12:57:07PM -0700, Matt Youell wrote: > So perhaps sometimes in Perl we could say: > > my Dog $spot = undef;# Automagically knows to be a Dog ref instead > of a Dog object because of the undef. > if ($age > 12) { > $spot = new Doberman(); > } else

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

Matt Youell wrote: > > So perhaps sometimes in Perl we could say: > > my Dog $spot = undef;# Automagically knows to be a Dog ref instead > of a Dog object because of the undef. > if ($age > 12) { > $spot = new Doberman(); > } else { > $spot = new Corgi(); >

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

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > my Dog $spot should call a constructor implicitly Eeeeww. Most of the time I use 'my Dog $spot' is along the lines of: package Dog;

  1   2   3   >