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

> I'd agree to the contrapositive: if we have named placeholders, I don't see the > need for positional ones too. But I'm willing to be convinced. The below, with > positional only, is total gibberish, as Ken points out. To most, probably, but I say let the user decide. Like Jeremy points out:

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

Jeremy Howard wrote: > Damian Conway wrote: > > Personally, if we have positional placeholders I don't see the need > > for named ones too. But I'm willing to be convinced. I'd agree to the contrapositive: if we have named placeholders, I don't see the need for positional ones too. But I'm will

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

Damian Conway wrote: >> And there's no argument about having anonymous, positional, and named >> placeholders in the redraft...? > > There's *always* arguments! ;-) > Although arguments from the RFC author are generally more compelling ;-) > Personally, if we have positional placeholders

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

> And there's no argument about having anonymous, positional, and named > placeholders in the redraft...? There's *always* arguments! ;-) Personally, if we have positional placeholders I don't see the need for named ones too. But I'm willing to be convinced. Damian

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

>> We could undo the ambiguity like so: >> >>/^{foo}/; # like ${foo} and @{foo} and %{foo} >> >> In fact, this seems built-in if we follow the same var conventions. We >> can make ^ bind to {} as tightly as we need. > > That would be the right solution. And of course

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

> As for the regexp issue, just to clarify there's only one ambiguous case > we need to work out that I can see: > >/.*^foo/; # ok But:/.*^foo/m; #ambiguous > We could undo the ambiguity like so: > >/^{foo}/; # like ${foo} and @{foo} and %{foo} > >

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

> So is this a consensus?: > > It is proposed that Perl introduce a new prefix '^', which indicates a > placeholder. This can be used in any of the following ways: > - ^identifier: named placeholder > - ^_: anonymous placeholder > - ^0, ^1, ...: positional placeholder. I think this sounds go

Re: RFC: println()

Too special purpose. I assume you don't do print "foo\nbar\gasp\n"; very often. > "EM" == Ed Mills <[EMAIL PROTECTED]> writes: EM> I actually saw this in the newsgroups and thought it was a neat idea. What EM> about EM>println $textvar; EM> instead of EM>print "$tex

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

It shouldn't be a problem. *_ would then be a 'special' reserverd identifier. *_name could be a named placeholder. > "JH" == Jeremy Howard <[EMAIL PROTECTED]> writes: JH> John Porter wrote: >> Has anyone suggested '*'? Since its use for typeglobs is (repsumably) >> going away, it's avail

Re: RFC: println()

[Reply-To set to [EMAIL PROTECTED]] Ed Mills wrote: > > I actually saw this in the newsgroups and thought it was a neat idea. What > about > >println $textvar; > > instead of > >print "$textvar\n"; > > Ever so much easier to read and write, prints the arg and appends \n. You can cur

Re: RFC 20 (v1) Overloadable && and ||

> expr1 && expr2 > > ...and detects that the LJ is overloaded, it could replace it with: > > user_defined_and( sub { $expr1 }, sub { $expr2 } ) Along the same line it would be useful to be able to overload the "truth operator" (bad word, I'm sorry). It's great to be able to do:

RFC: println()

I actually saw this in the newsgroups and thought it was a neat idea. What about println $textvar; instead of print "$textvar\n"; Ever so much easier to read and write, prints the arg and appends \n. Thank-You for consideration, great ideas I'm seeing here! -Ed

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

On Mon, 07 Aug 2000, iain truskett wrote: > Who here has actually used something other than a constant '1' in a > package? > > If so, why? (Possibly cite the code.) I have. I've used 34. (Just 'cause I like the number.) I've also used the filename before. (I wanted to watch the order of var

Re: Safer OO inheritance

2000-08-07-19:22:59 Michael Fowler: > Is $CURRENT_PACKAGE any different, value-wise, than __PACKAGE__? I'm guessing no, unless I've misunderstood something from the preceeding discussion. > Is there a reason to prefer it? I suppose some folks who want to do a truly stunningly huge amount of thi

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

* Peter Scott ([EMAIL PROTECTED]) [08 Aug 2000 07:14]: [...] > If the only realistic case you want to catch is an empty file, why not > just check for that and issue an error? Easier than everyone in the > world having to stick 1; at the end of their .pm (who's forgotten it, > now? Hands up...)

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

On Mon, 07 Aug 2000, Damian Conway wrote: > > > $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

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

From: Peter Scott [mailto:[EMAIL PROTECTED]] >At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: >>On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: >>Check the docs again. [snip] >> Four special subroutines act as package constructors and >> destructors. These are the `BEGIN', `CHECK', `IN

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

> On Tue, 8 Aug 2000 06:44:00 +1000 (EST), Damian Conway wrote: > > > > A true value indicates that the file is indeed valid Perl. > > > >So is an empty file! :-) > > That is precisely the problem. You won't get a syntax error if this > happens. > > Now, bringing

Re: Safer OO inheritance

On Mon, Aug 07, 2000 at 01:57:14PM +0200, Jean-Louis Leroy wrote: > package Foo; > > sub new > { > bless { "${CURRENT_PACKAGE}name" => 'Simpson' ... > } > > ...where $CURRENT_PACKAGE is a special variable automatically set > to...guess what? ;-) Is $CURRENT_PACKAGE any different, value-

Re: Safer OO inheritance

On Tue, Aug 08, 2000 at 06:22:03AM +1000, Damian Conway wrote: >> 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. [snip] > See the Tie::Securehash module for a variation on this theme. > Also

Re: RFC 54 (v1) Operators: Polymorphic comparisons

On Mon, Aug 07, 2000 at 02:27:34PM -, Perl6 RFC Librarian wrote: > This RFC proposes that numeric comparison operators default to stringwise > comparison when both arguments are non-numeric strings. > > =head1 DESCRIPTION > > Currently the expression: > > "cat" == "dog" > > returns t

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

At 08:19 AM 8/8/00 +1000, Jeremy Howard wrote: >John Porter wrote: > > 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". > > >Yes, it's been suggested, but we mi

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

John Porter wrote: > 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". > Yes, it's been suggested, but we might be too late on that one--another RFC suggests reserving

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

At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: >On Mon, 07 Aug 2000 10:56:40 -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. > >Check the docs

Re: RFC 58 (v1) C changes.

Thus it was written in the epistle of Bart Lateur, > On 7 Aug 2000 16:06:44 -, Perl6 RFC Librarian wrote: > > >This RFC contains two proposed changes. First, as it is common to want to > >removed newlines upon reading a file, > > > > while (chomp()) { > >. . . > > } > > > >should bec

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

On Mon, 07 Aug 2000 10:56:40 -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. Check the docs again. Although not the habit, it IS allowed to use:

Re: RFC 58 (v1) C changes.

On 7 Aug 2000 16:06:44 -, Perl6 RFC Librarian wrote: >This RFC contains two proposed changes. First, as it is common to want to >removed newlines upon reading a file, > > while (chomp()) { >. . . > } > >should become the equivalent of > > while () { >chomp; >. . . > } ...

Re: RFC 50 (v1) BiDirectional Support in PERL

On 07 Aug 2000 17:27:55 -0400, Chaim Frenkel wrote: >He mentioned two different encodings. Logical and Visual. I'm not clear >which is which. One orders the characters so that the first char is >first. The other reorders the characters to correctly display on a >device that can not understand rtl

Re: RFC 50 (v1) BiDirectional Support in PERL

You missed part of his missive. He mentioned two different encodings. Logical and Visual. I'm not clear which is which. One orders the characters so that the first char is first. The other reorders the characters to correctly display on a device that can not understand rtl text. > "BL" ==

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

Bart Lateur wrote: > > 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 happen. > > A true value indicates that the file is indeed valid Perl. That is a "lie", of the sort that Randal might tell you in day 1 of h

Re: RFC 22 (v1) Builtin switch statement

On 4 Aug 2000 14:59:06 -, Perl6 RFC Librarian wrote: > %special = ( woohoo => 1, d'oh => 1 ); > >while (<>) { >switch ($_) { > >case (%special) { print "homer\n"; last } # if >$special{$_} Hold it. Is that if($special{$_}

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

At 11:09 PM 8/7/00 +0200, Bart Lateur wrote: >On Tue, 8 Aug 2000 06:44:00 +1000 (EST), Damian Conway wrote: > > > > A true value indicates that the file is indeed valid Perl. > > > >So is an empty file! :-) > >That is precisely the problem. You won't get a syntax error if this >happens. > >Now,

Re: RFC 54 (v1) Operators: Polymorphic comparisons

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: >> 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. DC> I would claim that the failure mode is not obvious: "dog"=="cat" is true Sure it is. I

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

On Tue, 8 Aug 2000 06:44:00 +1000 (EST), Damian Conway wrote: > > A true value indicates that the file is indeed valid Perl. > >So is an empty file! :-) That is precisely the problem. You won't get a syntax error if this happens. Now, bringing in the million monkeys typing, again: the chances

Re: DRAFT RFC: Enhanced Pack/Unpack

On Mon, 7 Aug 2000 13:52:09 -0400, John Porter wrote: >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?) Right. Why you people don't call it "Intel" vs. "Motorola", like the rest of the civilised w

RFC 17 (v2) Organization and Rationalization of Perl

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Organization and Rationalization of Perl State Variables =head1 VERSION Maintainer: Steve Simmons <[EMAIL PROTECTED]> Date: 3 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Number: 17 CVSID

RFC: Safe Signals

=head1 TITLE Safe Signals =head1 VERSION Maintainer: Uri Guttman <[EMAIL PROTECTED]> Date: 07 Aug 2000 Version: 1 Mailing List: perl6-language-flow Number: TBD =head1 ABSTRACT This RFC describes how Perl6 can support safe signals with multiple techniques. =head1 DESCRIPT

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

> 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 happen. > > A true value indicates that the file is indeed valid Perl. So is an empty file! :-) Damian

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

Aaron J Mackey <[EMAIL PROTECTED]> writes: > proposed: > > @b = pop @a, $n; That will change the behaviour of this perl5 code: foo(pop @a, "bar") If we do this then the code above need to be fixed by the perl5->perl6 filter. Regards, Gisle

Re: RFC 54 (v1) Operators: Polymorphic comparisons

Damian Conway wrote: > I often need a generic comparison test (typically for equality of less-than), > and to get it one has to jump through hoops: > > sub generic_eq { > my $failed; > local SIG{__WARN__} = { $failed = 1 }; > return $_[0] eq

exception and error RFCs

i have not seen any posted (on dev.perl.org) rfc's on exception handling or errors. i would like someone to take one or both on and post it to flow. there was some discussion in language on those subjects but the threads have petered out (or have been drowned :-). so let's see some proposals f

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 >

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: 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 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: 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: 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: Recording what we decided *not* to do, and why

John Porter wrote: > 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

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

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

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

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

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

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

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

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 48 (v1) Replace localtime() and gmtime() with da

On Mon, 7 Aug 2000, Tim Jenness wrote: > Is localtime() used often enough to justify being part of > the language? You're kidding, right? We wouldn't have had all those script kiddies complaining about year 19100 bugs and month-being-off-by-one errors if localtime() wasn't being used all of the

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

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 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: Treating filehandles like strings

[Reply to perl6-language-io as this is an I/O related.] 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 g

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 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 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? > > We wouldn't have had all those script kiddies complaining about year 19100 > bugs and month-being-o

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

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

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

On Mon, 7 Aug 2000, Nathan Wiger 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? > > Exactly. In fact, I'm going to chop a lot of the original proposal out. > It's too bloated

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

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

A plea to RFC authors

When writing RFCs that talk about the inclusion of "interesting" new features--things like coroutines, matrix math, bizarre regex theory (yes, I know that's redundant), curried (or garlic'd, or peppered) subs, for example--it would be helpful if there was a good reference in the references sec

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

  1   2   >