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

On Sun, Aug 06, 2000 at 01:10:23PM -0700, Nathan Wiger wrote: > So you see why we need a persistent format() function. However, I think > your real issue is a one-time call that just changes the format > temporarily: > > print $date->strftime('%H:%M'); # print the time > print "$date";

Re: RFC: Rename local() operator

Buddha Buck <[EMAIL PROTECTED]> writes: > > > What about C ? > > > > Here's yet another one - how about "here"? > > > >{ > > here $/ = "\n"; # what it is in here > > > >} > > > > Not really any confusion on this - $/ is "\n" 'in here', but maybe > > something else outside. > >

Re: Treating filehandles like strings

On Mon, Aug 07, 2000 at 12:16:22AM -0400, Michael Mathews wrote: > Here's a thought. Wouldn't this be cool (see below)? The idea is that in > Perl 6 you should be able to read from a file handle one character or one > line at a time (just like you can in Perl 5) BUT if you just go ahead and > use

Re: Treating filehandles like strings

...and as for matching regexen against streams, I have a more general proposal for matching against subroutines that should allow for that as a special case. Damian

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

Damian Conway sent the following bits through the ether: > Rather than continue to argue the details, why don't people post some > examples of code where they feel these lazy lists might be useful, and > let's see if there aren't already good alternatives. It should be noted that "infinite" lazi

Re: RFC 52 (v1) List context return from filesystem func

Perl6 RFC Librarian sent the following bits through the ether: > affected files. I suggest that in a list context, they return the I > of the I affected files. This seems the wrong way around to me. Surely it should instead return the name of the successfully affected files? Hm. Leon --

Re: Safer OO inheritance

Bart Lateur <[EMAIL PROTECTED]> writes: > The problem is that you can't safely subclass a class, without examining > it's source, just to make sure that your instance fields don't clash > with any private fields of the mother class. Well...let's think twice. What has the reputatin of being a bug

Re: RFC 50 (v1) BiDirectional Support in PERL

On Sun, Aug 06, 2000 at 09:36:12PM -0400, Ken Fox wrote: > Perl6 RFC Librarian wrote: > > BiDirectional Support in PERL > > I know nothing about bi-directional output. It doesn't seem > like Perl has any assumption of left-to-right at all. What's > the difference between right-to-left support in

Re: RFC 49 (v1) Objects should have builtin string SCALA

On Sun, 6 Aug 2000 18:28:29 -0800, Michael Fowler wrote: >>print $pw; >>print scalar $pw; > >These resulting in a $pw->STRINGIFY or $pw->TO_STRING call is also >confusing; neither are being used as strings. Oh yes they are. $^W = 1; my $x; print $x; This compl

Re: RFC 22 (v1) Builtin switch statement

On Sat, Aug 05, 2000 at 04:10:20AM +1000, Damian Conway wrote: >> If a switch is considered like a loop then next would be the same >> as 'break' in C, as would last and redo would repeat the switch. > > But a switch is not a loop. True, but in perl any block is considered to be a loop t

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

On Sun, 06 Aug 2000 13:10:23 -0700, Nathan Wiger wrote: >With the new date function you'll never need >> to call >> >> sprintf("%02d/%02d/%04d", $tm[3], $tm[4]+1, $tm[5]+1900); >> >> since you can do >> >> date(undef,"%d/%m/%Y") > >True, but notice that you have to specify a format.

Re: Deep copy

Dan Sugalski <[EMAIL PROTECTED]> writes: > At 05:31 AM 8/7/00 +1000, Damian Conway wrote: > >> >Another one for my wish list: deep copying support built in. A devil > >> >inside me thinks this should be a new assignment > >> >operator. Damian? Sounds like this is up your alley. I

Re: Deep copy

Lisp, which you might expect would have a 'deep copy' operator, doesn't have one. The Lisp folks have apparently thought about this very carefully, and decided that the semantics are unclear, and that the obvious options are all wrong; I've read a number of articles about this in the past. I

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

On Mon, Aug 07, 2000 at 01:44:28AM -0500, Jonathan Scott Duff wrote: > On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote: > > Basically, you don't want to go anywhere near this mess; it eats people. > > I agree. > > > I see two reasonable options to go with instead. One is to just us

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

On Sun, 06 Aug 2000 17:35:17 -0700, Nathan Wiger wrote: >I >think the concept's great, just that the notation is really hard to >read, and doesn't necessarily scream "function" to me (especially since >_ is from stat already). I don't see why you can't simply use _. From the context, you clearly

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

On Sun, 06 Aug 2000 21:54:47 -0700, Nathan Wiger wrote: >Seems to me that a leading _ is worse for this than ^ Whatever prefix you choose, it should NEVER EVER be a \w character. And the general rule, until now at least, is that only characters from the ASCII repertoire are acceptable for proga

Re: Recording what we decided *not* to do, and why

Glenn Linderman wrote: > > When using an inline comment, I want to spend my character budget mostly > on the comment, and just enough on the delimiters to see it > effectively. #< magic here ># would do quite nicely > > When reading a script, I'd like to be able to quickly distinguish the > com

Re: RFC 15 (v1) Stronger typing through tie.

Nick Ing-Simmons wrote: > John Porter <[EMAIL PROTECTED]> writes: > >> my integer $quux = 4; > > > >I believe that would have to be > > > > integer my $quux = 4; > > > >at least in perl5... > > Well Larry has been using > > my Dog $spot; > > for a while. O.k., I see that now; I wa

Re: RFC: Rename local() operator

Buddha Buck wrote: > > But it isn't "here" that's the problem. If we just wanted to change > the value "here", we could use my(). The problem is that local() > changes the value for somewhere else as well as here. Well, as has been pointed out, special^Wlocalized variables are scoped in ti

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

On Mon, 7 Aug 2000, Johan Vromans wrote: > strftime sounds like a real Unixism to me. 'set_format' and 'format' looks > more neutral and at least as effective. strftime is and will likely continue to be available through the POSIX module (or its successor). I see no point in re-inventing strfti

Re: RFC: Rename local() operator

Nick Ing-Simmons wrote: > > > In PostScript, [gsave] allows you to save the current state of > > the graphics output device, on a stack, but it doesn't modify it. > > Neither does local - it is the = "\n" that does the modifying. Oh, not really. Because you get modification *regardless* of wh

MLC has its own sublist: WAS: Re: Recording what we decided *not* to do, and why

Please post further MLC remarks to the MLC sublist: [EMAIL PROTECTED] I can't guarentee that any MLC comments posted under a different subject, and on a different list will make it into the final Multiline Comments RFC! Not to mention that this specific argument is already addressed in the curre

Re: RFC: Filehandle type-defining punctuation

Thus it was written in the epistle of Bart Lateur, > On Fri, 4 Aug 2000 10:03:28 -0400, Ted Ashton wrote: > > >If we've decided that chomp isn't going to return the clippings, would it not > >seem prudent to make > > while (chomp()) > > > >work like > > while () > > You mean, like, the -l com

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

> Whatever you do, don't use those timezone names. Is EST Eastern US time > or Eastern Standard Time in Australia? The same abbreviation is used in > both places. > > Naming of time zones is a *huge* rathole that you probably just don't want > to crawl into. The short abbreviations are *not* s

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

On Mon, Aug 07, 2000 at 02:53:17PM +0200, Bart Lateur wrote: > On Sun, 06 Aug 2000 17:35:17 -0700, Nathan Wiger wrote: > > >I > >think the concept's great, just that the notation is really hard to > >read, and doesn't necessarily scream "function" to me (especially since > >_ is from stat already

Re: RFC: Rename local() operator

>The C operator of Perl5 and earlier does not do what it claims >to and should be renamed. How about: override meaning: ignore the value you've seen so far, for now, you'll use my value. I can't say that any of the proposed new names actually "clicks". But "hide" and "save" are to much

Re: RFC 23 (v1) Higher order functions

Ken Fox wrote: > > I think we need a curry context and that all curries must be surrounded > by parens. > . > sub traverse ($_); > my $sum = 0; > $root->traverse(($sum += __)); I think parens may be problematic, since nested lists flatten. Maybe curlies could be overloaded yet again?

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

Jeremy Howard wrote: > Yes, I change my mind . I like the '^' prefix > too. The difficulty of reading __ would be a pain. But what happens here? /^__foo/ Or here? /^{__}foo/ Is the latter sufficiently unambiguous? -- John Porter

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

Nathan Wiger wrote: > > Yeah, I personally can read this much clearer. Peter also mentions that > __ is hard to distinguish from _, unless they're right next to each > other, and I think this is a very valid point. This biggest problem with '__', imho, is that '_' is a valid identifier character

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

Has anyone suggested '*'? Since its use for typeglobs is (repsumably) going away, it's available (right?). It the "wildcard" mnemonic value is consistent with "placeholder". -- John Porter

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

Jeremy Howard wrote: > Yes, they're not identical. What I mean of course is: > (..-1) == reverse(map -__ (1..)); WHAT? So the semantics of .. are magically different in the context of (..$n) so as to produce numbers in descending order? I don't think so. -- John Porter

Re: RFC 53 (v10) Built-ins: Merge and generalize C

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > =head1 DESCRIPTION > > At present C only returns the index of the first occurrence of a > specified substring. It is proposed that C take a fourth parameter > telling it which occurrence of a specified substring to locate: > > $first = in

Re: RFC 44 (v1) Bring Documentation Closer To Whatever I

> Consider this (upcoming) Perl6 code: > > sub foo { > "Snarf the frobnitzers if x > 0.1"; > my $x = shift; > # ... > } Have you guys totally missed the discussions on multi-line comments? I argued for qc//, as in sub foo { qc(Snarf the frobnitzers if x > 0.1); my $x = shift;

Re: RFC17

At 10:55 PM 8/6/00 -0400, Ken Fox wrote: >Dan Sugalski wrote: > > But, if we toss refcounts, and split GC cleanup and > > end of scope actions anyway, we need to have a mechanism to hoist things > > out of the current scope. > >Why say hoist when we can say return? I can think of several ways of >

Re: Different points of view, a little perspective.

John Porter said: > that long post contained nothing that anyone > reading perl6-language isn't already > fully conscious of. At least, IMHO. I admit I took artistic license with my point. I should have expected programers to prefer short, logical statements (preferably ending with semicolons).

Re: Different points of view, a little perspective.

At 11:40 AM 8/7/00 -0400, Michael Mathews wrote: >In the MLC discussion I have read many comments about how various "C-style" >features would be easier for people to learn, remember, and use. In fact the >MLC discussion itself was inspired by a desire to make Perl more C-like >(actually Java-like)

Re: RFC 55 (v1) Compilation: Remove requirement for fina

> Compilation: Remove requirement for final true value in require'd and do'ed files Do not. I use this feature. -- John Porter

RE: Deep copy

$want_deep_copy++; $want_deep_equal++; From: Mark-Jason Dominus [mailto:[EMAIL PROTECTED]] > > Lisp, which you might expect would have a 'deep copy' operator, > doesn't have one. The Lisp folks have apparently thought about this > very carefully, and decided that the semantics are unclear, an

Re: RFC 55 (v1) Compilation: Remove requirement for fina

John Porter writes: >> Compilation: Remove requirement for final true value in require'd and >> do'ed files > > Do not. I use this feature. Is there any reason you couldn't use "die" instead? Nat

Re: RFC: Rename local() operator

> > But it isn't "here" that's the problem. If we just wanted to change > > the value "here", we could use my(). The problem is that local() > > changes the value for somewhere else as well as here. > > Well, as has been pointed out, special^Wlocalized variables are > scoped in time, not space,

Re: RFC 37 (v1) Positional Return Lists Considered Harmf

Fixed hashes, such as the return from stat() can be handled in the compiler. (Ala perl5's pseudo hash.) This could possibly be combined with the proposed direct pack/unpack handling of structures. So that the stat buffer would be transformed into a hash refering to a structure buffer. $stat{ino

Re: RFC: Rename local() operator

Nathan Wiger <[EMAIL PROTECTED]> writes: > > > But it isn't "here" that's the problem. If we just wanted to change > > > the value "here", we could use my(). The problem is that local() > > > changes the value for somewhere else as well as here. > > > > Well, as has been pointed out, special^W

Re: RFC 55 (v1) Compilation: Remove requirement for fina

Nathan Torkington wrote: > John Porter writes: > >> Compilation: Remove requirement for final true value in require'd and > >> do'ed files > > > > Do not. I use this feature. > > Is there any reason you couldn't use "die" instead? ??? Throw an exception in order to return a (0|'')-but-true va

Re: Treating filehandles like strings

Just a quick tangential comment: it should be possible to specify the maximum number of characters that a readline() will do on a filehandle. I couldn't find this in IO::Handle which seems to be where the user-defined line disciplines are inheriting their methods? Anyway, obvious application

Re: RFC: Rename local() operator

On 07 Aug 2000 17:26:14 +0100, Piers Cawley wrote: >$/ = "\n" now; $/ = "\n" for now; Very English-like. OTOH, now() sounds like a synonym for the built-in time(). -- Bart.

Re: RFC 55 (v1) Compilation: Remove requirement for fina

John Porter writes: > > >> Compilation: Remove requirement for final true value in require'd and > > >> do'ed files > ??? > Throw an exception in order to return a (0|'')-but-true value? If you want to indicate that there was an error in the code, why not die()? What am I missing? Nat

Re: RFC 53 (v10) Built-ins: Merge and generalize C

I don't see the point. What makes you want to do this? And if you are changing it, why not make it return the list of matches in a list context? $last = (index $string, $substring)[-1] (These type of translations/idioms might be candidates for optimization.) > "PRL" == Perl6 RFC

RE: Deep copy

There are a wide range of tricky problems associated with deep copy and deep compare. I like the idea, but circular references can make this problematic even without external things (filehandles, dirhandles, objects from non-perl sources) are thrown in. That needs to be taken into account when

Re: RFC 54 (v1) Operators: Polymorphic comparisons

This seems to be adding a special case. (I.e. only if _both_ are non-numeric will it switch to a cmp operation.) I currently fail to switch to 'eq' many times when I should, but the failure mode is obvious. Her the failure mode will be really strange. (And how does one tell if the string is nume

Re: RFC 55 (v1) Compilation: Remove requirement for fina

Nathan Torkington <[EMAIL PROTECTED]> writes: > John Porter writes: > >> Compilation: Remove requirement for final true value in require'd and > >> do'ed files > > > > Do not. I use this feature. > > Is there any reason you couldn't use "die" instead? Is there any reason that both couldn't be

Re: RFC 56 (v1) Optional 2nd argument to pop() and shift

PRL>3) C would then act as C and C would PRL> act as C I'll take door #3, Jonathan. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote: > sub *BEGIN { ... } > sub *END{ ... } > sub *INIT { ... } > sub *AUTOLOAD { ... } > sub *TIESCALAR { ... } > sub *FETCH { ... } Only half of those are subs. -- Peter S

RE: Deep copy

At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote: >There are a wide range of tricky problems associated with deep copy and >deep compare. I like the idea, but circular references can make this >problematic even without external things (filehandles, dirhandles, objects >from non-perl sources) are th

Re: RFC 54 (v1) Operators: Polymorphic comparisons

At 02:27 PM 8/7/00 +, you wrote: >This RFC proposes that numeric comparison operators default to stringwise >comparison when both arguments are non-numeric strings. What happens when one is a string that can't be numerified and the other is a number? Why don't you convert the number to a st

RE: Deep copy

At 10:07 AM 8/7/00 -0700, Peter Scott wrote: >At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote: >>There are a wide range of tricky problems associated with deep copy and >>deep compare. I like the idea, but circular references can make this >>problematic even without external things (filehandles, di

Re: RFC 55 (v1) Compilation: Remove requirement for fina

Nathan Torkington wrote: > John Porter writes: > > Throw an exception in order to return a (0|'')-but-true value? > > If you want to indicate that there was an error in the code, why not > die()? What am I missing? I'm talking about the case where the require should "succeed" but the return val

Re: DRAFT RFC: Enhanced Pack/Unpack

Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > Edwin Wiles <[EMAIL PROTECTED]> wrote: > > > Endianness: > > > > /d - default, whatever your system uses normally > > /n - network > > /b - big > > /l - little > > /v - vax > > > > (??vax is sufficiently different to require it's own?

Re: Deep copy

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> At 10:07 AM 8/7/00 -0700, Peter Scott wrote: >> At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote: >>> There are a wide range of tricky problems associated with deep copy and >>> deep compare. I like the idea, but circular references

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

> With the proliferation of special subroutine names (BEGIN, END, INIT, > CHECK, etc.) the all capital subroutine names available to the > programmer has steadily shrunk. Rather than stealing subroutines from > the programmer, we should create a space just for Perl. > > sub *BEGIN { >

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

Me too, and I'm _not_ an astronomer. Tim Jenness wrote: > Also, I would vote for a method to return the Julian date (yes I am an > astronomer...) :-) -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne _NetZero

Re: RFC: Rename local() operator

On Mon, Aug 07, 2000 at 09:26:04AM -0700, Nathan Wiger wrote: > As for the "need a verb" argument, my() and our() aren't verbs either. They're also lexical rather than dynamic. Dynamic things need action words (verbs) IMHO. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

> If you're going to use a convention, rather than a syntax, then the current > convention of all CAPS reserved to Perl is easier to understand, more > pleasing to the eye, and backwards compatible. Good point. Maybe we're getting a little "fix-happy". :-) -Nate

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

At 10:29 AM 8/7/00 -0700, Nathan Wiger wrote: > > With the proliferation of special subroutine names (BEGIN, END, INIT, > > CHECK, etc.) the all capital subroutine names available to the > > programmer has steadily shrunk. Rather than stealing subroutines from > > the programmer, we should create

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

On Mon, Aug 07, 2000 at 10:04:15AM -0700, Peter Scott wrote: > At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote: > > sub *BEGIN { ... } > > sub *END{ ... } > > sub *INIT { ... } > > sub *AUTOLOAD { ... } > > sub *TIESCALAR { ... } >

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

On Mon, 7 Aug 2000, Glenn Linderman wrote: > Me too, and I'm _not_ an astronomer. > > Tim Jenness wrote: > > > Also, I would vote for a method to return the Julian date (yes I am an > > astronomer...) :-) But surely not as a part of the core language? -- Andy Dougherty [EMAI

Re: DRAFT RFC: Enhanced Pack/Unpack

> > VAX is either big or little. I can't remember which off the top > > of my head. Right, VAX is strictly little-endian. I.e. the address of a *word is the address of its least significant byte. (That's little-endian, isn't it?) -- John Porter

Re: RFC 55 (v1) Compilation: Remove requirement for fina

John Porter writes: > But I admit this could be regarded as an edge case. Yeah, you could easily make this part of the module's interface. Removing the eval-to-true requirement would be one less arbitrary thing for people writing modules to do, and I'm very in favour of that. Nat

Re: RFC: Rename local() operator

> > As for the "need a verb" argument, my() and our() aren't verbs either. > > They're also lexical rather than dynamic. Dynamic things need action > words (verbs) IMHO. A valid distinction. Though, "now" has an action-like ring to it, even though it's not truly a verb. "NOW this var is this v

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

> > > Also, I would vote for a method to return the Julian date (yes I am an > > > astronomer...) :-) > > But surely not as a part of the core language? Exactly. In fact, I'm going to chop a lot of the original proposal out. It's too bloated for core. There's a lot of cool time/date stuff, but

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

On Mon, Aug 07, 2000 at 10:56:40AM -0700, Peter Scott wrote: > I meant that BEGIN, END, and INIT aren't declared as subs at present but > named blocks. I was surprised to discover that they're put in the symbol > table anyway though. But they're definitely in a different class, > syntacticall

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

At 12:55 PM 8/7/00 -0500, Jonathan Scott Duff wrote: >On Mon, Aug 07, 2000 at 10:04:15AM -0700, Peter Scott wrote: > > At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote: > > > sub *BEGIN { ... } > > > sub *END{ ... } > > > sub *INIT { ... } > > >

Re: DRAFT RFC: Enhanced Pack/Unpack

In message <[EMAIL PROTECTED]> Glenn Linderman <[EMAIL PROTECTED]> wrote: > Tom Hughes wrote: > > > VAX is either big or little. I can't remember which off the top > > of my head. > > > > You may be getting confused here with the middle-endian system > > used by the PDP machines which g

RFC17 (v1) comments and responses

This is an omnibus response to those who've commented on RFC17 (v1). The version I'm about to submit to the librarian is now available as html at . General note -- please look over the abstract. Some folks have made really good suggestions to change th

Re: RFC 53 (v10) Built-ins: Merge and generalize C

> Can anyone come up with a good example when you'd want to use both these > parameters at the same time? Second "foo" after the last "bar": index $text, "foo", index($text,"bar",0,-1), 2); Damian

Re: RFC 54 (v1) Operators: Polymorphic comparisons

> > This RFC proposes that numeric comparison operators default to stringwise > > comparison when both arguments are non-numeric strings. > > > The problem with this, is that we're removing orthogonality from the > language. ROTFL. > Do we want to say: > $num1 == $num2 w

Re: RFC 54 (v1) Operators: Polymorphic comparisons

> This seems to be adding a special case. (I.e. only if _both_ are > non-numeric will it switch to a cmp operation.) Well, I'd prefer it to always switch, but I thought that might be argued against. Since, *this* is being argued against, maybe I'll extend my proposal :-) > I currently f

Re: RFC 52 (v1) List context return from filesystem func

Leon Brocard wrote: > > Perl6 RFC Librarian sent the following bits through the ether: > > > affected files. I suggest that in a list context, they return the I > > of the I affected files. > > This seems the wrong way around to me. Surely it should instead return > the name of the successfull

Re: RFC 53 (v10) Built-ins: Merge and generalize C

Perl6 RFC Librarian wrote: > > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Built-ins: Merge and generalize C and C > Sounds good - but having both the third and fourth arguments feel counter-intuitive to me. It certainly seems relatively

Re: RFC 54 (v1) Operators: Polymorphic comparisons

Perl6 RFC Librarian wrote: > > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Operators: Polymorphic comparisons > > =head1 VERSION > > Maintainer: Damian Conway <[EMAIL PROTECTED]> > Date: 7 August 2000 > Version: 1 > Mailing List: [

Re: RFC 56 (v1) Optional 2nd argument to pop() and shift

proposed: @b = pop @a, $n; should this be equivalent to: @b = splice @a, -$n; # no longer a LIFO queue or : @b = reverse splice @a, -$n; # still a LIFO queue I guess it all depends on what you then do with @b, but you get my drift. This should be addressed, one way or another. -Aaron

ISA number

Have often wanted a way to tell whether a scalar was a number, and rolling a regex each time seemed wasteful given that Perl knew what it was anyway. So a user-friendly way to get at the SvIOK and SvNOK results would be great. The pedestrian way would be a builtin: isnum() or similar. But we

Re: RFC 54 (v1) Operators: Polymorphic comparisons

Damian Conway wrote: >> > This RFC proposes that numeric comparison operators default to stringwise >> > comparison when both arguments are non-numeric strings. >> > >> The problem with this, is that we're removing orthogonality from the >> language. > > ROTFL. But it's true

Re: ISA number

Peter Scott wrote: > > Have often wanted a way to tell whether a scalar was a number, and rolling > a regex each time seemed wasteful given that Perl knew what it was > anyway. So a user-friendly way to get at the SvIOK and SvNOK results would > be great. > > The pedestrian way would be a built

Re: ISA number

Peter Scott wrote: > Have often wanted a way to tell whether a scalar was a number, ... > So a user-friendly way to get at the SvIOK and SvNOK results would > be great. This is one of those rare proposals which can safely be assumed to be proposed, discussed, and accepted without dissent -- befo

Re: ISA number

At 12:27 PM 8/7/00 -0700, Peter Scott wrote: >Have often wanted a way to tell whether a scalar was a number, and rolling >a regex each time seemed wasteful given that Perl knew what it was >anyway. So a user-friendly way to get at the SvIOK and SvNOK results >would be great. The Sv?OK macros

Re: ISA number

Hildo Biersma wrote: > Having said that, it doesn't need to live in the core - and even today > it should be relatively easy to write an XS module for this. It should no more NOT live in the core than, say, scalar() (or whatever scalar() might become in 6). -- John Porter

Re: ISA number

At 08:31 PM 8/7/00 +0100, Hildo Biersma wrote: >Peter Scott wrote: > > > > Have often wanted a way to tell whether a scalar was a number, and rolling > > a regex each time seemed wasteful given that Perl knew what it was > > anyway. So a user-friendly way to get at the SvIOK and SvNOK results wou

Re: Deep copy

At 01:27 PM 8/7/00 -0400, Uri Guttman wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > DS> At 10:07 AM 8/7/00 -0700, Peter Scott wrote: > >> At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote: > >>> There are a wide range of tricky problems associated with deep copy > and > >

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

On Mon, 7 Aug 2000, Philip Newton wrote: > On Mon, 7 Aug 2000, Tim Jenness wrote: > > > Is localtime() used often enough to justify being part of > > the language? > > You're kidding, right? No, not at all. > We wouldn't have had all those script kiddies complaining about year 19100 > bugs a

Re: Deep copy

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> Well, if we provide a primitive for this (a big if) I expect it DS> can be piggy-backed onto the GC code somehow, which needs to do DS> the same sorts of things. the tree/structure scanner could be shared. in fact since GC has to d

Wither scalar() (was Re: ISA number)

On Mon, Aug 07, 2000 at 03:35:25PM -0400, John Porter wrote: > Hildo Biersma wrote: > > Having said that, it doesn't need to live in the core - and even today > > it should be relatively easy to write an XS module for this. > > It should no more NOT live in the core than, say, scalar() (or whatev

RE: Deep copy

> >There are a wide range of tricky problems associated with deep > >copy and deep compare. I like the idea, but circular references > >can make this problematic even without external things > >(filehandles, dirhandles, objects from non-perl sources) are > >thrown in. That needs to

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

On Mon, Aug 07, 2000 at 03:52:07PM -0400, Andy Dougherty wrote: > That means that the equivalent > functionality needs to be provided somehow in the complete standard perl6 > distribution. It doesn't mean localtime() has to be a keyword with its > very own opcode that is part of the core language

Re: RFC 37 (v1) Positional Return Lists Considered Harmf

An excellant idea, in my opinion. It would be a very appropriate use of structure handling to address system APIs with structures as parameters or returns. Indeed, stat, localtime, and other firends could be handled via predefined structure definitions. This is not to say that we should elimina

Re: RFC: Rename local() operator

Bart Lateur wrote: > >The C operator of Perl5 and earlier does not do what it claims > >to and should be renamed. > > How about: > > override > > meaning: ignore the value you've seen so far, for now, you'll use my > value. This is the sort of thing I was looking for when I proposed "red

Re: RFC 50 (v1) BiDirectional Support in PERL

On Mon, 7 Aug 2000 12:04:11 +0300, Roman M . Parparov wrote: >I wrote a WWW mail program with hebrew support once. Pain in the ass to >invent and reinvent functions for printing Hebrew correctly. Moreover, a >lot of self-written reversing and replacing reduces the performance from >what it would

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

Andy Dougherty wrote: > On Mon, 7 Aug 2000, Glenn Linderman wrote: > > > Me too, and I'm _not_ an astronomer. > > > > Tim Jenness wrote: > > > > > Also, I would vote for a method to return the Julian date (yes I am an > > > astronomer...) :-) > > But surely not as a part of the core language? It

Re: Safer OO inheritance

> I'm more in favor of a mechanism that makes it easy to build field > names from the package name, for those rare cases where you want > scoped fields. There were discussions about this a couple of years ago > on p5p. For example: > > package Foo; > > sub new { bless { "

Re: RFC 55 (v1) Compilation: Remove requirement for fina

On 7 Aug 2000 14:28:03 -, Perl6 RFC Librarian wrote: >Compilation: Remove requirement for final true value in require'd and do'ed files Er... "do'ne" files? Anyway, There is at least one case where you need this true value: if the file accidently is empty (or equivalent). I've had that happ

Re: RFC 53 (v10) Built-ins: Merge and generalize C

> > $last = index $string, $substring, -1, -1; # last occurence > > Err... shouldn't that be > > $last = index $string, $substring, 0, -1 # last occurrence > $first = index $string, $substring, -1, -1 # first occurrence found >

  1   2   >