Re: RFC 204 (v2) Arrays: Use list reference for multidimensional array access

2000-09-21 Thread Bart Lateur
On 20 Sep 2000 04:06:02 -, Perl6 RFC Librarian wrote: Ilya Zakharevich brought up the issue of a potential problem with objects which use blessed list references as their internal structure, and their use as indices. Given a Bignum class, which stores its (external) value internally as a

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-21 Thread Karl Glazebrook
Ilya Zakharevich wrote: As shipped: no. But if this is made a primitive (which I would not like), then the only change which is needed is to make the tie::multi::range() token to be followed by 3 numbers. [Aside: Why not make ternary-range operator into 10 :: 20 :: 2 ?] That would work.

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-21 Thread Buddha Buck
At 03:26 PM 9/21/00 -0400, Karl Glazebrook wrote: Finally as an overload expert what do you think about the proposals to make arrays overloadable objects so one can say things like: @x = 3 * @y; I can see that allowing expressions on @x would require considerable changes to perl

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-21 Thread Buddha Buck
At 03:35 PM 9/21/00 -0400, Buddha Buck wrote: At 03:26 PM 9/21/00 -0400, Karl Glazebrook wrote: Finally as an overload expert what do you think about the proposals to make arrays overloadable objects so one can say things like: @x = 3 * @y; What do you think of: $x[|i] = 3 *

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes andslices

2000-09-21 Thread Christian Soeller
Karl Glazebrook wrote: Buddha Buck wrote: @x = 3 * $y[|i]; It's not as clean as @x = 3 * @y, but it is cleaner context-wise. And one could argue that: @x = map 3*^_, @y; is cleaner yet... PDL already allows $x = 3*$y why step backwards? Exactly. Those other

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes andslices

2000-09-21 Thread Jeremy Howard
Christian Soeller wrote: Karl Glazebrook wrote: Buddha Buck wrote: @x = 3 * $y[|i]; It's not as clean as @x = 3 * @y, but it is cleaner context-wise. And one could argue that: @x = map 3*^_, @y; is cleaner yet... PDL already allows $x = 3*$y why

Re: RFC 204 (v2) Arrays: Use list reference for multidimensional array access

2000-09-21 Thread Jeremy Howard
Bart Lateur wrote: Hmm... the problem is, I think, that array references and ordinary scalars are both scalars. That's true, but they're scalars with different interfaces. In particular, an array ref can be dereferenced and provides an array in doing so. If an index can do this, then it's a

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-21 Thread Ilya Zakharevich
On Thu, Sep 21, 2000 at 03:26:39PM -0400, Karl Glazebrook wrote: [Aside: Why not make ternary-range operator into 10 :: 20 :: 2 ?] That would work. My point is that having a stride is a fundamental feature in other array languages (IDL, Matlab, PDL) and would be useful in the perl core.

RFC 81 (v4) Lazily evaluated list generation functions

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Lazily evaluated list generation functions =head1 VERSION Maintainer: Jeremy Howard [EMAIL PROTECTED] Date: 10 Aug 2000 Last Modified: 22 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 81

RFC 272 (v1) Arrays: transpose()

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: transpose() =head1 VERSION Maintainer: Jeremy Howard [EMAIL PROTECTED] Date: 22 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 272 Version: 1 Status: Developing =head1 ABSTRACT It

RFC 90 (v4) Arrays: merge() and unmerge()

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: merge() and unmerge() =head1 VERSION Maintainer: Jeremy Howard [EMAIL PROTECTED] Date: 10 Aug 2000 Last Modified: 21 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 90 Version: 4

RFC 91 (v4) Arrays: part and flatten

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: part and flatten =head1 VERSION Maintainer: Jeremy Howard [EMAIL PROTECTED] Date: 10 Aug 2000 Last Modified: 21 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 91 Version: 4 Status:

RFC 148 (v3) Arrays: Add reshape() for multi-dimensional array reshaping

2000-09-21 Thread Perl6 RFC Librarian
=head1 VERSION Reply-To: [EMAIL PROTECTED] This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: Add reshape() for multi-dimensional array reshaping =head1 VERSION Maintainer: Jeremy Howard [EMAIL PROTECTED] Date: 24 Aug 2000

RFC 203 (v2) Arrays: Notation for declaring and creating arrays

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: Notation for declaring and creating arrays =head1 VERSION Maintainer: Jeremy Howard [EMAIL PROTECTED] Date: 8 Sep 2000 Last Modified: 21 Sep 2000 Mailing List: [EMAIL PROTECTED] Number:

RFC 82 (v4) Arrays: Apply operators element-wise in a list context

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: Apply operators element-wise in a list context =head1 VERSION Maintainer: Jeremy Howard [EMAIL PROTECTED] Date: 10 Aug 2000 Last Modified: 21 Sep 2000 Mailing List: [EMAIL PROTECTED]

RFC 207 (v2) Arrays: Efficient Array Loops

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: Efficient Array Loops =head1 VERSION Maintainer: Buddha Buck [EMAIL PROTECTED] Date: 8 Sep 2000 Last Modified: 21 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 207 Version: 2

Re: RFC 265 (v1) Interface polymorphism considered lovely

2000-09-21 Thread Piers Cawley
Nathan Wiger [EMAIL PROTECTED] writes: * The new Cinterface keyword would be unnecessary if *package specifications* could take attributes: interface Fetcher; would then become: package Fetcher : interface; I'm not

Re: RFC 265 (v1) Interface polymorphism considered lovely

2000-09-21 Thread Piers Cawley
Nathan Wiger [EMAIL PROTECTED] writes: By specifying "use interface" explicitly, you can make sure that your class follows the interface spec. Otherwise, you rely on other classes in the hierarchy above you doing so, and then you indirectly inheriting from that interface. So "use interface"

Re: RFC 110 (v6) counting matches

2000-09-21 Thread Bart Lateur
On 20 Sep 2000 21:37:03 -, Perl6 RFC Librarian wrote: Bart Lateur: '()=' is not perfect. It is also butt ugly. It is a "dirty hack". Please don't hold this against me! I was arguing for a cleaner looking generic alternative for "()=", the now defunct list() operator. I do think that just

Re: RFC 23 (v5) Higher order functions

2000-09-21 Thread Chaim Frenkel
"AG" == Alan Gutierrez [EMAIL PROTECTED] writes: AG Just like the the regex match placeholders, positional placeholders begin AG with ^1 so that ^1 == $_[0]. If this doesn't make sense to it is AG probably because you are new to Perl and are not familiar with regular AG expressions, but we did

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Russ Allbery wrote: Glenn Linderman [EMAIL PROTECTED] writes: undef has the following semantics: 1) all otherwise uninitialized variables are set to undef And as the RFC says, quite a few times, for database code you often want all your variables to start as the null value. The RFC

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
By your "reasoning", we can just add infinitely more things that take twice a few pages to explain. You took that to an illogical extreme conclusion. Clearly you can't add everything to the language. However, it is clear by the set of currently submitted RFCs that more people think

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Tom Christiansen wrote: That's an empty string. In any case, if you really want to call it a null string, that's fine, just a little more likely to be misinterpreted. In Perl, this is the null string:"" In Perl, this is the null character: "\0" In Perl, this is the null list: ()

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Tom Christiansen wrote: I'm not happy with your use of "coerce". There's no mutation. It simply *is* those things. Fine. So, in particular, it _isn't_ null. Of course it's null. That's why it has length zero. Stop speaking SQL at me. I'm speaking Perl. No, in that wonderfully

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Peter Scott wrote: At 12:38 PM 9/20/00 -0700, Glenn Linderman wrote: OK, scalar variables. But I see code in the XML modules that check defined (@array) Then they should be fixed. That doesn't do anything useful right now. I tried to fix it according to the suggested fix in the warning

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
John Porter wrote: $a = null; $b = ($a == 42); print defined($b)? "defined" : "not defined"; would print "not defined", maybe? defined() is the wrong operator to be using there. Rather, The tri-state logic deals with "true", "false", and "unknown" (not NULL). To quote

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Paris Sinclair wrote: If you need additional semantics than provided by undef, why not make a module? This might be workable. There are some thoughts on that. Personally, I haven't used that much overloading in Perl to know whether it can be made to work well enough to completely conform

Re: RFC 241 (v1) Pseudo-hashes must die!

2000-09-21 Thread Glenn Linderman
Peter Scott wrote: $employee{$empno}{SAlARY} -= 10_000; # IPO failure $employee{$empno}{FAX} = '888-555-1212'; First one got the wrong key when my finger slipped on the shift key, second one got it when I misremembered FAX instead of FACSIMILE. But in neither case

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Damien Neil wrote: I suggest that you read up on the difference between "use strrict" and "use warnings"/-w. Thanks, yes, I figured out the "no warnings" issue afterwards. Furthermore, you may wish to take the five seconds necessary to understand WHY it prints that message when you print a

Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines

2000-09-21 Thread Michael G Schwern
CAPS LOCK KEY STUCK STOP CANNOT PROGRAM PERL REVERTING TO BASIC STOP SEND HELP QUICK STOP -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse When faced with desperate circumstances, we

Re: RFC 266 (v1) Any scalar can be a hash key

2000-09-21 Thread Michael G Schwern
On Thu, Sep 21, 2000 at 03:54:27AM -, Perl6 RFC Librarian wrote: =head1 IMPLEMENTATION Dunno. With my vague understanding of the existing code and hash tables in general: I believe the main reason why hash keys can't be references is because they're not really scalars. Internally

Re: RFC 267 (v1) Eliminate dump() function

2000-09-21 Thread Michael G Schwern
On Thu, Sep 21, 2000 at 03:55:21AM -, Perl6 RFC Librarian wrote: Eliminate dump() function I didn't even know it existed. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Any

Re: RFC 264 (v1) Provide a standard module to simplify the creation of source filters

2000-09-21 Thread Michael G Schwern
On Wed, Sep 20, 2000 at 04:12:17AM -, Perl6 RFC Librarian wrote: Given this level of complexity, it's perhaps not surprising that source code filtering is not commonly used. The both times I've attempted to use Filter::Util::Call, I've wound up reverting to Filter::Util::Exec and doing

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Tom Christiansen
No, in that wonderfully consistent Perl documentation, it's "undef" not SNIP is only used to refer to (as you pointed out in another post) the null string the null character the null list Those use null as an adjective. This RFC proposes an addition to Perl tSNIP the null This

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Tom Christiansen
In Perl, this is the null string:"" In Perl, this is the null character: "\0" In Perl, this is the null list: () In RFC 263, this is the null: null That's a different word for a different concept. No conflict, if you learn the way the RFC speaks. Wrong. Just plain wrong. It's

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Tom Christiansen
By your "reasoning", we can just add infinitely more things that take twice a few pages to explain. You took that to an illogical extreme conclusion. Clearly you can't add everything to the language. However, it is clear by the set of currently submitted RFCs that more people think

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Tom Christiansen wrote: A null is a null byte, or a null character. Period. ASCII, a standard that long predates Perl, defines the term NUL, not NULL, to refer to a null byte or null character. You are not correct, period or otherwise. You are completely out of your mind if you expect to

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Paris Sinclair
On Thu, 21 Sep 2000, Tom Christiansen wrote: A null is a null byte, or a null character. Period. You are completely out of your mind if you expect to co-opt an extant term for this screwed up notion of yours. I place my faith in Larry not to fuck up the language with your insanity.

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Philip Newton
On 20 Sep 2000, Russ Allbery wrote: About the only piece of code of mine that this would affect are places where I use ++ on an undef value, and that's not a bad thing to avoid as a matter of style anyway (usually I'm just setting a flag and = 1 would work just as well; either that, or it's

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Thanks, Paris, for your intervention, although I fear it was too late. Well, since Tom claims to have put me in his kill file, he may never see this. But for the record... Tom Christiansen wrote: Can't we all just play nice? Apparently not. Several of us attempted to explain why this

Re: RFC 259 (v2) Builtins : Make use of hashref context for garrulous builtins

2000-09-21 Thread Bryan C . Warnock
On Wed, 20 Sep 2000, Damian Conway wrote: This RFC proposes the builtin functions that return a large number of values in an array context should also detect hashref contexts (see RFC 21) and return their data in a kinder, gentler format. You may want to add a reference to the various

Re: Beefier prototypes (was Re: Multiple for loop variables)

2000-09-21 Thread Tom Christiansen
Could the prototype people please report whether Tim Bunce's issues with prototypes have been intentionally/adequately addressed? I'm not a prototype person (in fact RFC 128 makes it a hanging offence to use that confusing word in connection with parameter lists! ;-) Could someone

Re: IDEA: my() extensions and attribute declarations

2000-09-21 Thread Bryan C . Warnock
On Wed, 20 Sep 2000, Nathan Wiger wrote: my int ($x, $y), char $z; # mix classes my int ($x, $y) :64bit, char $z :long; # and attrs nit my (int ($x, $y), char $z); my (int ($x, $y) :64bit, char $z :long); /nit -- Bryan C. Warnock ([EMAIL PROTECTED])

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Tom Christiansen
Russ: About the only piece of code of mine that this would affect are places where I use ++ on an undef value, and that's not a bad thing to avoid as a matter of style anyway (usually I'm just setting a flag and = 1 would work just as well; either that, or it's easy enough to explicitly

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Graham Barr
On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote: Russ Allbery wrote: Why on earth would you want to do this in real code? I wouldn't, of course. This is just a demonstration that I want both semantics available concurrently. If you are not going to use it, why implement

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Tom Christiansen
How can you convince anyoone if you say you would not use it. For any feature enhancement to perl, unless there is a strong case for how it makes the labguage easier and better it is just not going to happen. It's not as though Tim Bunce has been hollering for this, which is a bad sign. --tom

Re: IDEA: my() extensions and attribute declarations

2000-09-21 Thread Piers Cawley
Nathan Wiger [EMAIL PROTECTED] writes: It seems potentially useful to be able to say: my Dog, Cat $fluffy; As a way to say "$fluffy can be either a Dog or a Cat". Since variables are prefixed, anything comma-separated up to the variable is an alternate class for that variable: Eurgh.

Re: RFC 12 (v2) variable usage warnings

2000-09-21 Thread Bart Lateur
On Wed, 20 Sep 2000 12:30:26 -0600, Tom Christiansen wrote: $a = undef; You have initialized it to undef. Solution: Remove all references from the language to defined and undef. Quite the reverse. Simply assume that uninitialized variables in Perl simply don't exist, that all

PERL6STORM - tchrist's brainstorm list for perl6

2000-09-21 Thread Tom Christiansen
=head1 NAME perl6storm - tchrist's brainstorm list for perl6 =head1 DESCRIPTION I'm going away for a long, long time, way past the RFC deadline. Here is my file of notions I've brainstormed over the last few weeks. Some have been covered in other RFCs. Many haven't. Most could use some

Re: PERL6STORM - tchrist's brainstorm list for perl6

2000-09-21 Thread Tom Christiansen
=item perl6storm #0106 Safe "signals"! (not syssigs,really)

Re: RFC 168 267 regarding builtins...

2000-09-21 Thread Webmaster
Both RFC 168 267 complain about the inability to override builtins. What if p6 simply require all user defined functions to be called using the func syntax, and that builtins require the bareword syntax? This way any builtin could be overridden and it would be immediately recognizable as an

scalars vis-a-vis non-scalars

2000-09-21 Thread Ed Mills
These would be perlish, nice, terse, succint, and economical: my ($a, $b, $c) = 0; @h(@colours)='red'; ($i, $i, $k) += 2; @nums = 10 * @nums; . . . Ed _ Get Your Private,

Re: scalars vis-a-vis non-scalars

2000-09-21 Thread Jeremy Howard
Ed Mills wrote: These would be perlish, nice, terse, succint, and economical: ... ($i, $i, $k) += 2; @nums = 10 * @nums; These are both covered by RFC 82.

Re: RFC 267 (v1) Eliminate dump() function

2000-09-21 Thread Randal L. Schwartz
"Michael" == Michael G Schwern [EMAIL PROTECTED] writes: Michael On Thu, Sep 21, 2000 at 03:55:21AM -, Perl6 RFC Librarian wrote: Eliminate dump() function Michael I didn't even know it existed. I do, every time I forget to hit the shift key around certain invocations of Data::Dumper and

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread John Porter
Glenn Linderman wrote: If they are the same, then you can't tell the different between a variable that is yet uninitialized, and one that has been read in from the database, containing a NULL. In my mind, that is horribly confusing. Since this is a theoretical argument -- as evidenced by

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread John Porter
Glenn Linderman wrote: ASCII, a standard that long predates Perl, defines the term NUL, not NULL, to refer to a null byte or null character. Now, that's not accurate either. "NUL" is simply a normalized form of "null", because all the ASCII special characters have three upper-case letter

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Tom Christiansen
Now, that's not accurate either. "NUL" is simply a normalized form of "null", because all the ASCII special characters have three upper-case letter names. There is no doubt that the ASCII guys meant "null" by this. All other matters aside, kindly consider this simple one: If ever you thought

RE: PERL6STORM - tchrist's brainstorm list for perl6

2000-09-21 Thread Fisher Mark
=item perl6storm #0064 Do something about microsoft's CRLF abomination. I think for the case of Microsoft C++ used for the Win32 port, everyone would be happy if Perl's sysopen, sysread, etc. did not require binmode. Unfortunately, Microsoft made the decision very early on in its C/C++

Re: RFC 12 (v2) variable usage warnings

2000-09-21 Thread Dave Storrs
On Wed, 20 Sep 2000, Steve Fink wrote: 1 my ($x, $y, $z); 2 $z = 1; 3 my $logfile = "/tmp/log"; 4 $x = 1 if cond(); 5 print $x+$y; 6 undef $z; 7 print $z; -- use of uninitialized variable $y in line 5 (compile time) -- possible use of uninitialized variable $x in line 5 (compile

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Buddha Buck
At 02:39 AM 9/21/00 -0700, Glenn Linderman wrote: Thanks, Paris, for your intervention, although I fear it was too late. Well, since Tom claims to have put me in his kill file, he may never see this. But for the record... Tom Christiansen wrote: Can't we all just play nice? Apparently

Re: RFC 12 (v2) variable usage warnings

2000-09-21 Thread Dave Storrs
On Wed, 20 Sep 2000, Eric Roode wrote: foo(); print $x; Generate a warning, or not? Which one? Remember, foo() may initialize $x. My suggest (FWIW) would be that, if there is no execution path which leads to $x being defined in the second line, then a "Use of uninit'd

Re: RFC 168 267 regarding builtins...

2000-09-21 Thread John Porter
Webmaster wrote: Both RFC 168 267 complain about the inability to override builtins. What if p6 simply require all user defined functions to be called using the func syntax, and that builtins require the bareword syntax? Uh, how does that result in overridability? Sounds to me more like a

Re: RFC 12 (v3) variable usage warnings

2000-09-21 Thread Eric Roode
Steve Fink, via the Perl6 Librarian, wrote: =head2 EXAMPLE 1 my ($x, $y, $z, $r); 2 $z = 1; 3 f(\$r); 4 my $logfile = "/tmp/log"; 5 $x = 1 if cond(); 6 print $x+$y; 7 undef $z; 8 print $z; [...] No warning is issued for C$r because any variable whose reference is

Re: RFC 12 (v3) variable usage warnings

2000-09-21 Thread Steve Fink
Eric Roode wrote: Steve Fink, via the Perl6 Librarian, wrote: =head2 EXAMPLE 1 my ($x, $y, $z, $r); 2 $z = 1; 3 f(\$r); 4 my $logfile = "/tmp/log"; 5 $x = 1 if cond(); 6 print $x+$y; 7 undef $z; 8 print $z; [...] No warning is issued for C$r

Re: RFC 267 (v1) Eliminate dump() function

2000-09-21 Thread Bart Lateur
On 21 Sep 2000 03:55:21 -, Perl6 RFC Librarian wrote: Eliminate dump() function Get rid of it completely. I think that, for the rare occasions people want this functionality, one of the many O (B) modules should offer it, at least in spirit. -- Bart.

Re: RFC 12 (v3) variable usage warnings

2000-09-21 Thread Steve Fink
Michael Fowler wrote: Ok, at this point I'm trying to clear up misunderstandings. I believe you know where I stand with relation to your RFC. Thanks, you caught several of my mistakes. On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote: Michael Fowler wrote: Except for

Re: PERL6STORM - tchrist's brainstorm list for perl6

2000-09-21 Thread Charles Lane
Tom Christiansen [EMAIL PROTECTED] wrote: =item perl6storm #0016 object as scope/namespace? see python. it's danged clean there in that you can now implement safe trivially. don't have to keep inventing crazy overloads. Yes, this would be great! =item perl6storm #0025 Make -T the default

Re: RFC 267 (v1) Eliminate dump() function

2000-09-21 Thread Uri Guttman
"BL" == Bart Lateur [EMAIL PROTECTED] writes: BL On 21 Sep 2000 03:55:21 -, Perl6 RFC Librarian wrote: Eliminate dump() function Get rid of it completely. BL I think that, for the rare occasions people want this functionality, one BL of the many O (B) modules should offer it,

Re: RFC 208 (v2) crypt() default salt

2000-09-21 Thread Andy Dougherty
On Thu, 21 Sep 2000, Mark-Jason Dominus wrote: And the problem you describe is not really a problem. There has never been any guarantee that a program would produce the same sequence of random numbers after a change to the Perl binary. random numbers after a change to the Perl binary. More

Re: RFC 12 (v2) variable usage warnings

2000-09-21 Thread Steve Fink
Dave Storrs wrote: On Wed, 20 Sep 2000, Eric Roode wrote: foo(); print $x; Generate a warning, or not? Which one? Remember, foo() may initialize $x. My suggest (FWIW) would be that, if there is no execution path which leads to $x being defined in the second line,

Re: RFC 12 (v2) variable usage warnings

2000-09-21 Thread Eric Roode
Allow me to throw another log on the fire: my $x; if (something) { $x = 1; } my $y = $x; This would give a compile-time warning under your RFC, warning the user of a possibly uninitialized $x. Okay. Next: my $x; if (something) { $x = 1; }

Re: RFC 208 (v2) crypt() default salt

2000-09-21 Thread Bart Lateur
On Thu, 21 Sep 2000 15:37:36 -0400 (EDT), Andy Dougherty wrote: Still, even for me, I have never encountered a case where I wanted to maintain the same rand() sequence and also use a one-arg crypt(). I will add a note aboput this to the RFC. If there are no other comments, I will freeze it

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Philip Newton wrote: Having $seen{$word}++ turn $seen{$word} to undef is bad, if (undef)++ assumes NULL semantics everywhere, hence "one more than unknown" = "still unknown". Right. Applying NULL semantics to undef would be bad. The counterproposals to RFC 263, along the lines of "use

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Graham Barr wrote: On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote: Russ Allbery wrote: Why on earth would you want to do this in real code? I wouldn't, of course. This is just a demonstration that I want both semantics available concurrently. If you are not

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
John Porter wrote: Glenn Linderman wrote: If they are the same, then you can't tell the different between a variable that is yet uninitialized, and one that has been read in from the database, containing a NULL. In my mind, that is horribly confusing. Since this is a theoretical

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Buddha Buck wrote: Ok, let's see if I can make some sense of this... Thanks for trying. I think you have. You want a singleton scalar datatype in addition to the exising scalar datatypes of strings, numbers, references, filehandles, and undef that represents an unknown value, similar in

Re: RFC 85 (v2) All perl generated errors should have a unique identifier

2000-09-21 Thread Chaim Frenkel
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: TC Ok, so you want message catalogues, and not solely on Perl but anything TC in the distribution. You should say that. No. That is independent of what I'm suggesting. What I'm suggesting is an enabler. I've seen code that actually looks at

Re: RFC 269 (v1) Perl should not abort when a required file yields a false value

2000-09-21 Thread Matthew Wickline
(offlist) If I had a qoute file for a raondom sig generator, this would surely be added. :) Some languages like to have the compiler emit annoying messages to announce you forgot to include some pointless code whose only purpose is to stop the compiler from emitting the annoying message.

Re: RFC 268 (v1) Keyed arrays

2000-09-21 Thread Michael Maraist
my/our @array :hashsyntax; would hide the definition of %array in the same way that my/our %array would hide a prior definition of %array. And references to %array would thenceforth actually be references to the keyed array @array. I can see massive confusion from this.

Re: RFC 12 (v2) variable usage warnings

2000-09-21 Thread Steve Fink
Eric Roode wrote: Allow me to throw another log on the fire: my $x; if (something) { $x = 1; } my $y = $x; This would give a compile-time warning under your RFC, warning the user of a possibly uninitialized $x. Okay. Next: Yes. my $x; if

RE: RFC 83 (v3) Make constants look like variables

2000-09-21 Thread Greg Boug
Apologies if these comments have already been noted... my $PI : constant = 3.1415926; my @FIB : constant = (1,1,2,3,5,8,13,21); my %ENG_ERRORS : constant = (E_UNDEF='undefined', E_FAILED='failed'); Constants can be lexically or globally scoped (or any other new scoping level yet

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Russ Allbery
Glenn Linderman [EMAIL PROTECTED] writes: Philip Newton wrote: Having $seen{$word}++ turn $seen{$word} to undef is bad, It doesn't "turn it to undef"; if you're using tristate semantics, it leaves it as undef, because those are the semantics you've selected for undefined values. if

Re: RFC 83 (v3) Make constants look like variables

2000-09-21 Thread Jeremy Howard
Greg Boug wrote: Apologies if these comments have already been noted... my $PI : constant = 3.1415926; my @FIB : constant = (1,1,2,3,5,8,13,21); my %ENG_ERRORS : constant = (E_UNDEF='undefined', E_FAILED='failed'); Constants can be lexically or globally scoped (or any other new

Re: async I/O (was Re: PERL6STORM - tchrist's brainstorm list for perl6)

2000-09-21 Thread Uri Guttman
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 05:35 PM 9/21/00 -0400, Uri Guttman wrote: i proposed some of that in my rfc47 (universal async i/o). at the perl level you need a delivery interface as with events. DS I'm not really worried about the perl level for this. I'm more

Re: RFC 270 (v1) Replace XS with the CInline module as the standard way to extend Perl.

2000-09-21 Thread Matthew Cline
On Thu, 21 Sep 2000, you wrote: This one-liner is a complete perl extension: perl -e 'print add(2,2);use Inline C="int add(int x,int y){return x+y;}"' I haven't written any XS myself, but I was under the impression that one problem with it is that what you write an extension in (XS)

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Glenn Linderman
Russ Allbery wrote: I'm not overlooking it; I just don't agree with you. There *is* a difference. You are certainly welcome to not agree with me. And if you didn't overlook it, that is fine. In my opinion, which you probably will also not agree with, attempting to toggle between the

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Russ Allbery
Glenn Linderman [EMAIL PROTECTED] writes: In my opinion, which you probably will also not agree with, attempting to toggle between the current undef semantics and tristate semantics is like trying to stuff three values into one bit. I do understand the argument. I just see confusion either

Re: RFC 268 (v1) Keyed arrays

2000-09-21 Thread Glenn Linderman
Michael Maraist wrote: my/our @array :hashsyntax; would hide the definition of %array in the same way that my/our %array would hide a prior definition of %array. And references to %array would thenceforth actually be references to the keyed array @array. I can see

RFC 83 (v3) Make constants look like variables

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Make constants look like variables =head1 VERSION Maintainer: Jeremy Howard [EMAIL PROTECTED] Date: 10 Aug 2000 Last Modified: 21 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 83 Version: 3

Re: RFC 271 (v1) Subroutines : Pre- and post- handlers for subroutines

2000-09-21 Thread Uri Guttman
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL If a handler changes one of the original arguments through the PRL aliases in its @_ array, those changes a passed on to subsequent PRL handlers and to the primary itself. For example: PRL pre tax_payable_on { PRL

RFC 269 (v1) Perl should not abort when a required file yields a false value

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Perl should not abort when a required file yields a false value =head1 VERSION Maintainer: Dominus [EMAIL PROTECTED] Date: 21 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 269 Version: 1

RFC 208 (v3) crypt() default salt

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE crypt() default salt =head1 VERSION Maintainer: Mark Dominus [EMAIL PROTECTED] Date: 11 Sep 2000 Last Modified: 21 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 208 Version: 3 Status:

RFC 270 (v1) Replace XS with the CInline module as the standard way to extend Perl.

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace XS with the CInline module as the standard way to extend Perl. =head1 VERSION Maintainer: Brian Ingerson [EMAIL PROTECTED] Date: 21 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 270

RFC 271 (v1) Subroutines : Pre- and post- handlers for subroutines

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Subroutines : Pre- and post- handlers for subroutines =head1 VERSION Maintainer: Damian Conway [EMAIL PROTECTED] Date: 21 September 2000 Mailing List: [EMAIL PROTECTED] Number: 271 Version: 1