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

On Sat, Aug 19, 2000 at 09:23:03AM -0400, Ken Fox wrote: > "Christopher J. Madsen" wrote: > > foreach $item $index (@array) { > > print $item, " is at index ", $index, "\n"; > > } > > That's useful syntax, but I'd rather it mean stepping > pair-wise through @array. Then we could scan

Re: RFC 88: What does catch "Foo" { } do?

On Fri, Aug 18, 2000 at 11:04:03PM -0600, Tony Olekshy wrote: > As currently promulgated, catch "Foo" {} will always catch, > because "Foo" is true. Will this cause confusion for developers > who meant to say catch Foo {}? And what happens when someone > says catch "Foo", "Bar" {}? > > We can't

Re: Maximum length input line

On Sun, 20 Aug 2000, Peter Scott wrote: > I read that before I made my posting; it looked to me that :block was > specifying a fixed-length read independent of line terminators, i.e., same > behavior as $/ = \1024. Stand-alone, I guess it would be. But I would think that combining it with, sa

Re: RFC 132 (v1) subroutines should be able to return an lvalue

[Quoting Chaim Frenkel, on August 20 2000, 00:54, in "Re: RFC 132 (v1) sub"] > Why do you mind having an attribute? An attribute would - require the sub to be consequent in what it returns; - require the sub to be predeclared before it can be used; - make it unfeasable for methods. -- Joh

Re: epoch for time

At 15:02 -1000 2000.08.19, Tim Jenness wrote: >I'm of the camp that feels perl should have a fixed epoch rather than the >epoch of the underlining OS. Furthermore, I can understand that the OS >epoch can also be important when looking outside of perl. Thinking this >over for a while it occurred to

Re: RFC for $ME class variable (was Re: RFC 124 (v1) Sort order for any hash)

On Sat, Aug 19, 2000 at 09:32:50AM -0700, Randal L. Schwartz wrote: > > "John" == John Siracusa <[EMAIL PROTECTED]> writes: > > John> I don't like $ME either, but my alternative is probably even more > John> blasphemous: use $self. "It usurps a variable name that has been legal for > John> c

Re: RFC 88: What does catch "Foo" { } do?

Graham Barr wrote: > > I am of the opinion that only a class name should follow catch. > If someone wants to catch based on an expression they should use > > catch { > if () { > } > else { > # rethrow the error > } > } Then you will be glad to know that RFC 88, in the n

Re: RFC 88: What does catch "Foo" { } do?

At 10:14 AM 8/20/00 -0600, Tony Olekshy wrote: >Graham Barr wrote: > > > > I am of the opinion that only a class name should follow catch. > > If someone wants to catch based on an expression they should use > > > > catch { > > if () { > > } > > else { > > # rethrow the error >

Re: RFC 88: What does catch "Foo" { } do?

Peter Scott wrote: > > Tony Olekshy wrote: > > > > Graham Barr wrote: > > > > > > I am of the opinion that only a class name should follow catch. > > > If someone wants to catch based on an expression they should use > > > > > > catch { > > > if () { > > > } > > > else { > > >

RFC 88: Possible problem with shared lexical scope.

Non-shared: my ($p, $q); try { $p = P->new; $q = Q->new; ... } finally { $p and $p->Done; } finally { $q and $q->Done; } Shared: try { my $p = P->new; my $q = Q->new; ... } finally { $p and $p->Done; } finally { $q and $q->Done; } If P->new throws, then the second f

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

At 08:19 AM 8/20/00 +0100, Graham Barr wrote: >Yes. I thought someone else would have done an RFC for this by >now, but I was going to propose that a for loop can >have any number of variables > > for my($a,$b,$c) (@array) { ... } > >steps three at a time, > > for my($key,$val) = (%hash) { ...

Re: Maximum length input line

At 10:06 AM 8/20/00 -0400, Bryan C. Warnock wrote: >On Sun, 20 Aug 2000, Peter Scott wrote: > > > I read that before I made my posting; it looked to me that :block was > > specifying a fixed-length read independent of line terminators, i.e., same > > behavior as $/ = \1024. > >Stand-alone, I guess

Re: Maximum length input line

On Sun, 20 Aug 2000, Peter Scott wrote: > Well you guys are way ahead of me on your line discipline modes, so I > didn't want to hazard a syntax; just wanted to make my desires known. I wouldn't say that we are (well, at least me) way ahead. I'm just throwing ideas out nyself, except that I was

Re: epoch for time

On Sun, 20 Aug 2000, Chris Nandor wrote: > At 15:02 -1000 2000.08.19, Tim Jenness wrote: > >I'm of the camp that feels perl should have a fixed epoch rather than the > >epoch of the underlining OS. Furthermore, I can understand that the OS > >epoch can also be important when looking outside of pe

Re: RFC 132 (v1) subroutines should be able to return an lvalue

Chaim Frenkel <[EMAIL PROTECTED]> writes: > JV> An attribute would > > JV> - require the sub to be consequent in what it returns; > > I can't parse that line. With an lvalue atttribute, a sub is assumed to always return an lvalue. The lreturn proposal makes it possible for a sub to determin

Re: RFC 132 (v1) subroutines should be able to return an lvalue

> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes: JV> An attribute would JV> - require the sub to be consequent in what it returns; I can't parse that line. JV> - require the sub to be predeclared before it can be used; lvalueness seems to be appropropriate. These two should have

Re: Vtable speed worry

Simon Cozens <[EMAIL PROTECTED]> writes: >I'm obviously missing something about vtables. It'll be obvious when someone >corrects me, but... > >Currently, SvPVX(foo) requires one lookup; with a vtable, it would necessitate >two, (One to find the functino in "foo", and then the functino must find th

Re: Vtable speed worry

David L . Nicol <[EMAIL PROTECTED]> writes: >No, because each table lookup takes less time than comparing one >letter of a text string. Er, I don't think so. A lookup takes serveral cycles on a RISC machine due to memory latency even to the cache. A pipelined string compare takes less than a c

Re: Do threads support SMP?

On 20 Aug 2000, Chaim Frenkel wrote: > SWM> Does Perl6 support Symmetric MultiProcessing (SMP)? Perl5 does - see 'fork'. I'm guessing that Perl6 will have at least that much support. > SWM> This is a *huge* issue. It affects everything else that we do with > SWM> threads. Most operating syst

RFC 23 (v4) Higher order functions

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Higher order functions =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 4 August 2000 Last Modified: 20 August 2000 Version: 4 Mailing List: [EMAIL PROTECTED] Number: 23 =head

RFC 136 (v1) Implementation of hash iterators

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Implementation of hash iterators =head1 VERSION Maintainer: Tom Hughes <[EMAIL PROTECTED]> Date: 20 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 136 =head1 ABSTRACT Perl 5 makes v

RFC 133 (v1) Alternate Syntax for variable names

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Alternate Syntax for variable names =head1 VERSION Maintainer: David Corbin <[EMAIL PROTECTED]> Date: 20 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 133 =head1 ABSTRACT Many new

RFC 134 (v1) Alternative array and hash slicing

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Alternative array and hash slicing =head1 VERSION Maintainer: Mike Pastore <[EMAIL PROTECTED]> Date: 20 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 134 =head1 ABSTRACT This RFC a

RFC 135 (v1) Require explicit m on matches, even with ?? and // as delimiters.

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Require explicit m on matches, even with ?? and // as delimiters. =head1 VERSION Maintainer: Nathan Torkington <[EMAIL PROTECTED]> Date: August 20, 2000 Version: 1 Mailing List: [EMAIL PROTECTED]

RFC 130 (v3) Transaction-enabled variables for Perl6

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Transaction-enabled variables for Perl6 =head1 VERSION Maintainer: Szabó, Balázs <[EMAIL PROTECTED]> Date: 17 Aug 2000 Last Modified: 19 Aug 2000 Version: 3 Mailing List: [EMAIL PROTECTED] Numbe

RFC 130 (v2) Transaction-enabled variables for Perl6

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Transaction-enabled variables for Perl6 =head1 VERSION Maintainer: Szabó, Balázs <[EMAIL PROTECTED]> Date: 17 Aug 2000 Last Modified: 18 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Numbe

Do we really need eq?

Is eq needed? Can't == be used for either context? $a == 'cat' is readily distinguishable from $a == 2; so the compiler should be able to determine context. Get Your Private, Free E-mail from MSN Hotmail at http://

Re: Do we really need eq?

Ed Mills writes: > Is eq needed? Can't == be used for either context? >$a == 'cat' > is readily distinguishable from >$a == 2; > so the compiler should be able to determine context. if ($a == $b) Is that string comparison or numeric comparison? Nat

Re: Do we really need eq?

On Sun, 20 Aug 2000 17:50:20 -0600 (MDT), Nathan Torkington wrote (in part): Nat> Ed Mills writes: >> Is eq needed? Can't == be used for either context? $a == >> 'cat' is readily distinguishable from $a == 2; so the compiler >> should be able to determine context. Nat> if ($a == $b) Nat> Is th

Re: Do we really need eq?

> "Ed" == Ed Mills <[EMAIL PROTECTED]> writes: Ed> Is eq needed? Can't == be used for either context? Ed>$a == 'cat' Ed> is readily distinguishable from Ed>$a == 2; Ed> so the compiler should be able to determine context. Yes, but what about: $a = '3.14'; # from reading a

RFC 88 v2 draft 5 is available via http.

This version will be published after Peter Scott gets a chance to review the last days' changes (he's co-author now), and I make any adjustments necessitated by your reviews, dear reader ;-) Formatted: http://www.avrasoft.com/perl/rfc/rfc88v2d5.htm POD as text: http://www.avrasoft.com/perl/rfc/

Re: RFC 88: Possible problem with shared lexical scope.

On Sun, 20 Aug 2000, Tony Olekshy wrote: > Shared: > > try { my $p = P->new; my $q = Q->new; ... } > finally { $p and $p->Done; } > finally { $q and $q->Done; } > > If P->new throws, then the second finally is going to test > $q, but it's not "in scope" yet (its my hasn't been seen)

Re: RFC 88: Possible problem with shared lexical scope.

Dave Rolsky wrote: > > On Sun, 20 Aug 2000, Tony Olekshy wrote: > > > try { my $p = P->new; my $q = Q->new; ... } > > finally { $p and $p->Done; } > > finally { $q and $q->Done; } > > > > If P->new throws, then the second finally is going to test > > $q, but it's not "in scope" yet (

Re: RFC 88: Possible problem with shared lexical scope.

On Sun, 20 Aug 2000, Tony Olekshy wrote: > That would be nice. But does this mean that in the following > case: > > try { fragile(); } > catch { my $caught = 1; } > finally { $caught and ... } > > storage for $caught is allocated and initialized to undef at the > beginning of

Re: RFC 88: Possible problem with shared lexical scope.

Dave Rolsky wrote: > > Tony Olekshy wrote: > > > try { fragile(); } > > catch { my $caught = 1; } > > finally { $caught and ... } > > If all those pieces were in the same scope I think it would still > work like this (in Perl5-ish code): > > { > try { fragile(); # It must be

Re: RFC 88: Possible problem with shared lexical scope.

Tony Olekshy wrote: > Non-shared: > > my ($p, $q); > try { $p = P->new; $q = Q->new; ... } > finally { $p and $p->Done; } > finally { $q and $q->Done; } > > Shared: > > try { my $p = P->new; my $q = Q->new; ... } > finally { $p and $p->Done; } > finally { $q and $q->Do

Re: RFC 132 (v1) subroutines should be able to return an lvalue

> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes: >> These two should have different actions. >> >> $foo = &foo; >> &foo = $foo; >> >> Perl needs a value for one, and a reference for the other. JV> I'm not sure I understand what you trying to say here. Please explain. The difference be

Re: RFC 23 (v4) Higher order functions

To Damian and all other RFC authors. Please add a CHANGES section. Would you be kind to us lost souls that are trying to read these things. > "DC" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: DC> This and other RFCs are available on the web at DC> http://dev.perl.org/rfc/ DC> =

Pre-RFC: Require a warning on spaces after here-document "terminator"

I was asked to debug a weird Perl5 problem yesterday. The code in question looked roughly like this (indented 4 spaces, but otherwise unchanged): #!perl -w use strict; print

Re: RFC 88: Possible problem with shared lexical scope.

At 06:48 PM 8/20/00 -0600, Tony Olekshy wrote: >Dave Rolsky wrote: > > > > Tony Olekshy wrote: > > > > > try { fragile(); } > > > catch { my $caught = 1; } > > > finally { $caught and ... } > > > > If all those pieces were in the same scope I think it would still > > work like th

Re: RFC 88: Possible problem with shared lexical scope.

Peter Scott wrote: > > > > Tony Olekshy wrote: > > > > > > > try { fragile(); } > > > > catch { my $caught = 1; } > > > > finally { $caught and ... } > > > > > It should work as though each pair of } ... { in between try { and > the end of the last finally or catch block isn't th