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

2000-08-18 Thread Jarkko Hietaniemi
> The clue is "If a sub wants to return an lvalue, it must B an > lvalue". Therefore I propose a new keyword C that behaves > just like C, but returns the lvalue instead of the rvalue. After > returning, everything is exactly as if the argument to lreturn were > specified instead of the subroutine

Re: Vtable speed worry

2000-08-18 Thread Simon Cozens
On Fri, Aug 18, 2000 at 09:02:21AM +0100, Hildo Biersma wrote: > > sv->vtable->svpvx; > > > > Isn't this going to really, really hurt? > > Doing three C pointer lookups is going to be less expensive than > invoking a subroutine But you're doing that as well. vtables store function pointers.

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

2000-08-18 Thread dLux
/--- On Thu, Aug 17, 2000 at 06:17:51PM -0400, Chaim Frenkel wrote: | Though this is a tough problem especially in the face of threads. | Though versioned variables may be able to remove most of the | locking | issues and move it down into the commit phase. Yes, but you can give strange

Re: ANNOUNCE: Inline 0.23 (Mix Perl and C w/o XS)

2000-08-18 Thread Brian Ingerson
Hi all, This is Brian Ingerson (the Inline.pm author). My coworker, Colin Meyer, tipped me off to this thread. I thought I'd throw in a few tidbits to make sure everyone's on track. But first of all, make sure to RTFM. (Because I put a lot of effort in explaining it there) The latest copy is: ht

Re: Vtable speed worry

2000-08-18 Thread David L. Nicol
No, because each table lookup takes less time than comparing one letter of a text string. > sv->vtable->svpvx; > > Isn't this going to really, really hurt? -- David Nicol 816.235.1187 [EMAIL PROTECTED] Does despair.com sell a discordia

Re: Vtable speed worry

2000-08-18 Thread Hildo Biersma
Simon Cozens wrote: > > 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 the > data in "

Re: RFC 128 (v1) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments

2000-08-18 Thread Hildo Biersma
Chaim Frenkel wrote: > > DC> =head1 IMPLEMENTATION > > DC> Definitely S.E.P. > > What does that mean? Somebody Else's Problem. From one of the Douglas Adams novels.

Re: RFC 128 (v1) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments

2000-08-18 Thread Hildo Biersma
> =head1 ABSTRACT > > This RFC proposes that subroutine argument context specifiers be > extended in several ways, including allowing parameters to be typed and > named, and that a syntax be provided for binding arguments to named > parameters. I agree with most, if not all, of this RFC. > =h

Re: RFC 128 (v1) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments

2000-08-18 Thread Damian Conway
> > An argument would be associated with a named parameter by > > prefixing it with a standard Perl label (i.e. an identifier-colon > > sequence). For example: > > > > @mapped = doublemap(args: @list, mapsub: ^a+^b); > > I persoanlly would prefer '=>' to be used here

Re: RFC 128 (v1) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments

2000-08-18 Thread Graham Barr
On Fri, Aug 18, 2000 at 06:04:55PM +1000, Damian Conway wrote: >> > An argument would be associated with a named parameter by >> > prefixing it with a standard Perl label (i.e. an identifier-colon >> > sequence). For example: >> > >> > @mapped = doublemap(args: @list,

Re: Subroutines: Extend subroutine contexts to include name parameters and lazy arguments

2000-08-18 Thread Johan Vromans
> If the C modifier is used for a particular parameter, that parameter > is lazily evaluated. This means that it is only evaluated when the > corresponding named parameter (see below) -- or the corresponding element > of @_ -- is accessed in some way. Passing the parameter to another > subroutine

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

2000-08-18 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE subroutines should be able to return an lvalue =head1 VERSION Maintainer: Johan Vromans <[EMAIL PROTECTED]> Date: Aug 18, 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 132 =head1 ABSTRA

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-18 Thread Ted Ashton
Thus it was written in the epistle of Steve Fink, > > Which has next to nothing to do with any particular issue. And it's too > hard to argue when we agree. :-). > If I asked you which variable $x[4] is accessing, I bet you'd say @x. > Which is one source of the confusion -- in one case, you us

Re: McNamara's C<$#> as a property of any array element

2000-08-18 Thread Jarkko Hietaniemi
On Fri, Aug 18, 2000 at 03:46:10AM -0500, David L. Nicol wrote: > Mike Pastore wrote: > > > > Any thoughts on this? Yes, please, the idea, that is: I've wanted such a variable oftentimes. What I'm not certain about is reusing the $#. Reusing obsoleted stuff is Dangerous. > Attributes. > > ($

Re: RFC 124 (v1) Sort order for any hash

2000-08-18 Thread Jonathan Scott Duff
On Fri, Aug 18, 2000 at 09:31:44AM +0100, Hildo Biersma wrote: > Ah, syntax - I have no idea. Well, syntax aside, how would this work? > One thing we could do, theoretically: > > %hash = ('James' => 'Gibbon', > 'Dave' => 'Mallon', > 'Pete' => 'Munro'); > > while (my ($key,

Re: ANNOUNCE: Inline 0.23 (Mix Perl and C w/o XS)

2000-08-18 Thread Jarkko Hietaniemi
On Thu, Aug 17, 2000 at 07:01:59PM -0700, Brian Ingerson wrote: > Hi all, > > This is Brian Ingerson (the Inline.pm author). My coworker, Colin Meyer, > tipped me off to this thread. I thought I'd throw in a few tidbits to > make sure everyone's on track. But first of all, make sure to RTFM. > (B

RFC 131 (v1) Internal String Storage to be Opaque

2000-08-18 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Internal String Storage to be Opaque =head1 VERSION Maintainer: Simon Cozens <[EMAIL PROTECTED]> Date: Aug 18 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Numb

Re: RFC 131 (v1) Internal String Storage to be Opaque

2000-08-18 Thread Bradley M. Kuhn
> Internal String Storage to be Opaque > Number: 131 > =item Why a single internal encoding? FWIW, I would like to throw my support behind this proposal. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

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

2000-08-18 Thread Christopher J. Madsen
David L. Nicol writes: > Why not use an explicit perl5 counter? > > my $index; > foreach $item (@array){ $index++; > print $item, " is at index ", $index, "\n"; > } Well, one reason is that your example doesn't work (it starts the index at 1 instead of 0). You'd need

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

2000-08-18 Thread Jonathan Scott Duff
On Fri, Aug 18, 2000 at 09:07:31AM -0500, Christopher J. Madsen wrote: [ Very Good examples elided ] > With the explicit counter, > > foreach $item $index (@array) { ... } > > $index could (and should) be a read-only variable (like $i is in > "foreach $i (1,2,3,4)"). This would make sure

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

2000-08-18 Thread Christopher J. Madsen
Jonathan Scott Duff writes: > Excellent summary of why an explicit index is a Good Thing as compared > to the programmer doing it himself. I think the syntax would need to > be different though, how do you use implicit $_ and an index? (Don't > Do That is not an answer because people will wa

Re: filehandle objects et al. OR: Perl's not the glue, it's the borg of languages

2000-08-18 Thread Jerrad Pierce
In reply to your message from the not too distant future: next Thursday AD Reply-to: [EMAIL PROTECTED] Return-receipt-to: [EMAIL PROTECTED] Organization: a) Discordia b) none c) what's that? Content-Typo: gibberish, charset=ascii-art Date: Fri, 18 Aug 2000 10:07:04 EDT From: Jerrad Pierce > Perl

Re: Line disciplines (was Re: RFC 69 (v3) Standardize input record separator)

2000-08-18 Thread James Mastros
On Thu, Aug 17, 2000 at 04:05:13PM -0700, Dave Storrs wrote: > However, I think that if we're going to write this DFA at all, then the > user SHOULD have the choice of using it for normal regex matchs, by > specifying a specific flag (my choice was 'd'). Alternatively, the person > should be able

Re: filehandle objects et al. OR: Perl's not the glue, it's the borg of languages

2000-08-18 Thread Jonathan Scott Duff
On Fri, Aug 18, 2000 at 10:07:06AM -0400, Jerrad Pierce wrote: > >Also, your examples don't cover this: > > $web = open "http://www.yahoo.com", GET; > >Remember, additional args for the proposed open handler can follow the > >filename. > Never saw it. How many additional arg's? As many as it ta

Re: RFC 131 (v1) Internal String Storage to be Opaque

2000-08-18 Thread Simon Cozens
On Fri, Aug 18, 2000 at 09:57:59AM -0700, Larry Wall wrote: > Because we don't lose much efficiency to polymorphism, since we need it > anyway to support generic scalars, and we gain some efficiency whenever > we procrastinate conversions out of existence. Surely we do, because we have to add in

Re: RFC 131 (v1) Internal String Storage to be Opaque

2000-08-18 Thread Jarkko Hietaniemi
> That's the thing. It doesn't matter. It B matter. Keep it > pluggable; you could have everything in Latin1, in UTF8, in UTF16, or > who knows what, but the core developer shouldn't have to care. One good > way to achieve this is to have the string presented in the variable as > an array of wchar

Re: RFC 131 (v1) Internal String Storage to be Opaque

2000-08-18 Thread Simon Cozens
On Fri, Aug 18, 2000 at 10:22:13AM -0500, Jarkko Hietaniemi wrote: > Danger! Only the implementer(s) of this pluggable data storage and > its interface should care about details like "an array of wchars". > All other people, even other core people, should use just the > interface, not do things l

Re: RFC 131 (v1) Internal String Storage to be Opaque

2000-08-18 Thread Larry Wall
[EMAIL PROTECTED] writes: : A single internal encoding which is opaque to the programmer Would Be Nice. We seem to be asking for contradictory things here. If it's truly opaque, the programmer shouldn't care whether it's polymorphic or monomorphic. I'm inclined to think the polymorphic solution

Re: ANNOUNCE: Inline 0.23 (Mix Perl and C w/o XS)

2000-08-18 Thread Brian Ingerson
Oops, In my haste to upload version 0.23 (which supports MSWin32) I introduced a bug which will cause "make test" to fail *only* if the user is installing Inline.pm for the first time. Of course, everyone (except me) caught this right away. So I hastlily uploaded v0.24 :-) Please use that one i

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

2000-08-18 Thread Christopher J. Madsen
Jonathan Scott Duff writes: > On Fri, Aug 18, 2000 at 10:12:02AM -0500, Christopher J. Madsen wrote: > > foreach $_ $index (@array) { ... } > > > > It's only 3 characters, and it makes for a nice consistant syntax. > > Yep, but it might also be a source of confusion too. There's no wa

Re: Do threads support SMP?

2000-08-18 Thread Christopher J. Madsen
Steven W McDougall writes: > Does Perl6 support Symmetric MultiProcessing (SMP)? > 1 No > 1.2 Cons > We don't get SMP. SMP is a nyah, nyah issue. Without SMP, Perl will > have trouble outgrowing its toy/scripting language reputation. You left out the biggest con of not having preemptive th

Re: Thread usage cases

2000-08-18 Thread Christopher J. Madsen
Steven W McDougall writes: > 4. Regular expressions > It seems like an RE match should be atomic, because it hard to imagine > it executing sensibly if the target string changes during the match. > But then we have > > Thread1 Thread2 > $a =~ s/.../.../e; $a

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

2000-08-18 Thread Jonathan Scott Duff
On Fri, Aug 18, 2000 at 10:12:02AM -0500, Christopher J. Madsen wrote: > I would say you can't use implicit $_ with an index; you use explicit > $_ instead. Sounds like "Don't Do That" to me :-) > > foreach $_ $index (@array) { ... } > > It's only 3 characters, and it makes for a nice cons

Do threads support SMP?

2000-08-18 Thread Steven W McDougall
Does Perl6 support Symmetric MultiProcessing (SMP)? This is a *huge* issue. It affects everything else that we do with threads. 1 No If Perl6 doesn't support SMP, then the interpreter can be implemented with cooperative threads. It calls yield() internally to switch threads, and by design, it o

Thread programming model

2000-08-18 Thread Steven W McDougall
I've spent the last 3 years programming WindowsNT threads in MSVC++, and I *really* like it. I want similar capabilities in Perl6. 1 The C++ thread model Here is the thread model that I have in C++. It is a starting point for thinking about what I want in Perl. Every thread sees - the same code

Thread usage cases

2000-08-18 Thread Steven W McDougall
1. Scalars Thread1 Thread2 $a = 1; $a = 2; $a is set to 1 and then 2, or 2 and then 1. It just depends which thread gets there first. 2. Arrays Thread1 Thread2 push @a, (1, 2, 3); push @a, (4, 5, 6); The interesting question

RE: RFC 124 (v1) Sort order for any hash

2000-08-18 Thread Brust, Corwin
-Original Message- From: David L. Nicol [mailto:[EMAIL PROTECTED]] How about %students : ( sort = $$students{^1}{GPA} <=> $$students{^0}{GPA} }); O, this is cool. -Original Message- my %students : sorted( $ME{^1}{GPA} <=> $ME{^0}{GPA} ); And th

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

2000-08-18 Thread Johan Vromans
"Syloke Soong" <[EMAIL PROTECTED]> writes: > func(args) = ... > func(args) += ... > func(args) =~ s/// > > Such functions have been modeled in object models that accept > arg-list+operator (head+operator) polymorphic signatures. It would be > up to the programmer of func() to dictate

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

2000-08-18 Thread Johan Vromans
[EMAIL PROTECTED] (Randal L. Schwartz) writes: > How do you indicate to the compiler at the time of compiling: > > lvsub() = FOO > > that FOO should be evaluated in list context? Or scalar context? In all cases but one the context is scalar anyway. The only case when the context could

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

2000-08-18 Thread Randal L. Schwartz
> "Johan" == Johan Vromans <[EMAIL PROTECTED]> writes: Johan> Why not? I couldn't find in the Camel that the right side must be Johan> evaluated first (at least not where the assignment operator = is Johan> discussed according to the index). Shouldn't: sub magicguy { lreturn @a; }

RFC 63

2000-08-18 Thread Peter Scott
I am willing to withdraw RFC 63 if the following parts are included somewhere in RFC 88 in this or equivalent language: "Note that C is a keyword, not a function. This is solely so that a C<;> is not needed at the end of the last block, since so many people are bound to think it shouldn't be th

RE: warn (was: yoda 2)

2000-08-18 Thread Peter Scott
At 10:33 AM 8/18/00 -0500, Brust, Corwin wrote: >Hmm this gets me thinking: >In the context of a catch block, if could @_ contain the exception stack, >starting with the current exception, could C be modified to act of @_ >if called in void context with no arguments? I like the idea of passing th

Re: Draft 1 of RFC 88 version 2.

2000-08-18 Thread Peter Scott
At 11:02 PM 8/17/00 -0600, Tony Olekshy wrote: > > Note: I used to favor $_[0] for the exception, but I'm being > > won over to $@. As long as it doesn't cause problems with > > external interfaces. Might mention the $_[0] idea in a > > footnote. > >Done. Um, see last message. There's a lot to

Re: Draft 2 of RFC 88 version 2.

2000-08-18 Thread Peter Scott
At 06:04 AM 8/18/00 -0600, Tony Olekshy wrote: > exception 'Error::DB::Foo'; > > Makes Error::DB::Foo into a class that inherits from the built-in > Exception class. > > If the given name matches /::/, something like this happens: > > @Error::DB::Foo::ISA = 'Error::DB'; Hmm,

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

2000-08-18 Thread Nathan Torkington
Perl6 RFC Librarian writes: > foreach $item (@array) { > print $item, " is at index ", $#, "\n"; > } > > > The variable C<$#> currently holds the output format for printed > numbers. This would slow down all foreach loops, even those that didn't need to know $#. It's a similar

Re: explicit boolean accessor

2000-08-18 Thread Nathan Torkington
Nathan Wiger writes: > > This works in Perl5. > > Right, a lot of this stuff (like STRING and BOOLEAN) can be accomplished > through overloading. However, having a standard builtin method similar > to tie and import makes things easier and more consistent I think. If we > make "everything an obje

Re: explicit boolean accessor

2000-08-18 Thread Nathan Wiger
Nathan Torkington wrote: > > Nathan Wiger writes: > > > This works in Perl5. > > > > Right, a lot of this stuff (like STRING and BOOLEAN) can be accomplished > > through overloading. However, having a standard builtin method similar > > to tie and import makes things easier and more consistent I

Re: explicit boolean accessor

2000-08-18 Thread Damian Conway
> So what you want is for overloading to become easier, probably via > predefined methods? Excellent topic for an RFC. I'm already writing it (and exactly that way, too). Damian

Re: RFC 124 (v1) Sort order for any hash

2000-08-18 Thread David L. Nicol
And not only is it less to write, as a programmer, but you can abstract a general "sort these records by GPA" routine and everything can use the same one, fewer memory pages to dirty. Damian Conway wrote: > >> > my %students : sorted( $ME{^1}{GPA} <=> $ME{^0}{GPA} ); >> > >> Y

Re: explicit boolean accessor

2000-08-18 Thread David L. Nicol
Exactly. The :bool attribute becomes a shorthand for that. Nathan Torkington wrote: > > David L. Nicol writes: > > What if perl6 kept it as the default, but allowed any class > > to override the object->BOOLEAN accessor which will return > > um, a special TRUE and FALSE which only make sens

Re: RFC 124 (v1) Sort order for any hash as an example of attributes in action

2000-08-18 Thread David L. Nicol
"Brust, Corwin" wrote: > > > -Original Message- > From: David L. Nicol [mailto:[EMAIL PROTECTED]] > How about > > %students : ( sort = $$students{^1}{GPA} <=> $$students{^0}{GPA} }); > > > > O, this is cool. > > > -Original Message- > my %students : sort

Re: RFC 95 (v2) Object Classes

2000-08-18 Thread David L. Nicol
John Siracusa wrote: > Object attributes should be accessed through accessors that look and behave > like accessors: > > $name = $mage->name; and Object qualifiers should be accessed through accessors that look like qualifiers: $mage : (HASHTYPE = 'packed_static') > I'd like to

Re: RFC 124 (v1) Sort order for any hash

2000-08-18 Thread Damian Conway
> How about > >%students : ( sort = $$students{^1}{GPA} <=> $$students{^0}{GPA} }); Weeird! :-) Since you've strayed so close, why not go all the way and make it an attribute: my %students : sorted( $ME{^1}{GPA} <=> $ME{^0}{GPA} ); Where the C attribute takes a blo

Re: RFC 95 (v2) Object Classes

2000-08-18 Thread Hildo Biersma
I disagree with this in so many places that I don't really know where to start... First, I do agree with the view perl should have better support for classes. Also, should the author want to, protection features from C++ (or other B&D languages) should be supported optionally. > NOTE: these and

Re: RFC 124 (v1) Sort order for any hash

2000-08-18 Thread Damian Conway
> > my %students : sorted( $ME{^1}{GPA} <=> $ME{^0}{GPA} ); > > > Yes, I was thinking the same thing. Except the '$ME' thing--what's that? (I > must have missed that discussion...) It's an idea that within a method call, the object reference would not be passed as the first argument (

Re: explicit boolean accessor

2000-08-18 Thread Nathan Torkington
David L. Nicol writes: > What if perl6 kept it as the default, but allowed any class > to override the object->BOOLEAN accessor which will return > um, a special TRUE and FALSE which only make sens in boolean > contexts? Like: use overload 'bool' => \&my_truth; sub my_truth { 1; #

Re: explicit boolean accessor

2000-08-18 Thread Nathan Wiger
> Like: > > use overload > 'bool' => \&my_truth; > > sub my_truth { > 1; # objects of this class are always true > } > > This works in Perl5. Right, a lot of this stuff (like STRING and BOOLEAN) can be accomplished through overloading. However, having a standard builtin method s

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

2000-08-18 Thread Damian Conway
[EMAIL PROTECTED] (Randal L. Schwartz) writes: > So is that something we've agreed, that lvalue subs are *always* > scalars? That'd mean we can move on to the various implementation > details. :) Err, I for one would like to see *any* data types lreturn-able. If a subroutine can return a list,

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

2000-08-18 Thread Nathan Torkington
Johan Vromans writes: > I think scalars play a super-normal role already. E.g., hashes and > arrays can hold only scalar values. The restriction to scalars may be > a small one, especially when it makes the whole idea of lvalued > subroutines feasible. Without the need for zillions of operator > o

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

2000-08-18 Thread Nathan Wiger
> want() obviously needs an additional parameter: how deep to go > back in the call stack. Which begs also for a way to find out how > deep is the call stack. How about recursive calls to want(), similar to multiple $$$'s? if (want(want(want))) eq 'HASH' ) -Nate

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

2000-08-18 Thread Damian Conway
> How about recursive calls to want(), similar to multiple $$$'s? > >if (want(want(want))) eq 'HASH' ) No, that's heading in the wrong direction (both figuratively and literally :-) C with no arguments returns a list of valid contexts. C with arguments expects a list of contexts a

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

2000-08-18 Thread Johan Vromans
Nathan Torkington <[EMAIL PROTECTED]> writes: > ... the PDL folks who were the drivers for the current lvalue sub > implementation ... I assume they are on this list, then. -- Johan

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

2000-08-18 Thread Damian Conway
> > But why introduce a new keyword "lreturn"? What about something like > > this? > > > > sub foo { > > my $lvalue : lvalue; > > ... > > return $lvalue if want('LVALUE'); > > } > > Error proneness? (Is that a word?) It is now :-) Besides, conte

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

2000-08-18 Thread Johan Vromans
Damian Conway <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Randal L. Schwartz) writes: > > > So is that something we've agreed, that lvalue subs are *always* > > scalars? That'd mean we can move on to the various implementation > > details. :) > > Err, I for one would like to see *any* dat

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

2000-08-18 Thread Jarkko Hietaniemi
On Sat, Aug 19, 2000 at 05:07:15AM +1000, Damian Conway wrote: >> > But why introduce a new keyword "lreturn"? What about something like >> > this? >> > >> >sub foo { >> >my $lvalue : lvalue; >> >... >> >return $lvalue if wa

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

2000-08-18 Thread Johan Vromans
[EMAIL PROTECTED] (Randal L. Schwartz) writes: > So is that something we've agreed, that lvalue subs are *always* > scalars? That'd mean we can move on to the various implementation > details. :) I think scalars play a super-normal role already. E.g., hashes and arrays can hold only scalar valu

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

2000-08-18 Thread Damian Conway
> > Besides, context can't always tell: > > > > bar ( foo ); > > > > Should foo return a copy or an alias? > > want() obviously needs an additional parameter: how deep to go > back in the call stack. Which begs also for a way to find out how > deep is the call stack

TAI time

2000-08-18 Thread Mark-Jason Dominus
TAI is an international time standard. It has a number of technical advantages over UTC. One of these advantages is that it doesn't have any silly truck with leap seconds. Dan Bernstein has defined a time format called TAI64 which is based on TAI. The format is very simple. TAI64 is almost c

Re: TAI time

2000-08-18 Thread David E. Wheeler
Mark-Jason Dominus wrote: > > TAI is an international time standard. It has a number of technical > advantages over UTC. One of these advantages is that it doesn't have > any silly truck with leap seconds. ... Why, this sounds perfect, Mr. D! When will you write the RFC? David

Re: TAI time

2000-08-18 Thread Russ Allbery
Mark-Jason Dominus <[EMAIL PROTECTED]> writes: > TAI is an international time standard. It has a number of technical > advantages over UTC. One of these advantages is that it doesn't have > any silly truck with leap seconds. One point to be aware of with TAI, however, is that Unix system clock

Re: TAI time

2000-08-18 Thread Tim Jenness
On 18 Aug 2000, Russ Allbery wrote: > Mark-Jason Dominus <[EMAIL PROTECTED]> writes: > > > TAI is an international time standard. It has a number of technical > > advantages over UTC. One of these advantages is that it doesn't have > > any silly truck with leap seconds. > libtai looks like a

PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-like "with" or "express"

2000-08-18 Thread David L. Nicol
Dave Storrs wrote: > The following words could also be overloaded for this purpose: > map, use I think I like use %record{ is a macro that expands to {my \%_ = \%record; even better than the same thing without the key word.

Re: RFC 124 (v1) Sort order for any hash

2000-08-18 Thread Jeremy Howard
Damian Conway wrote: >> How about >> >> %students : ( sort = $$students{^1}{GPA} <=> $$students{^0}{GPA} }); > > Weeird! :-) > > Since you've strayed so close, why not go all the way and make it an attribute: > > my %students : sorted( $ME{^1}{GPA} <=> $ME{^0}{GPA} ); > > Where the

Re: RFC 106 (v1) Yet another lexical variable proposal: lexical variables made default

2000-08-18 Thread Nathan Torkington
J. David Blackstone writes: > I agree with you. However, I am unable to find a case in which a > package global could not be replaced with a lexical defined in the > module's .pm file and an accessor method for it. Even if you are > extending a class, you can still provide this. A lexical plu

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

2000-08-18 Thread Chaim Frenkel
I don't think you should even attempt to version/transaction protect a tied variable. Anything that leaves the memory or could leave the memory (e.g. socket write) should probably not be versioned. Unless the tied variable somehow is able to tie itself into the transaction manager. It is up for

Re: RFC 131 (v1) Internal String Storage to be Opaque

2000-08-18 Thread Bryan C . Warnock
On Fri, 18 Aug 2000, Simon Cozens <[EMAIL PROTECTED]> wrote: > RFC 131 {snipped} Having pondered this (unsuccesfully) for a couple weeks, I will certainly concede that this is the simplest way of handling this problem. A couple counter-points. 1. I believe your extrapolation from 'one strin

Re: RFC 39 (v2) Perl should have a print operator

2000-08-18 Thread Nathan Torkington
Jon Ericson writes: > First repeat 10 times - "It's not a replacement, it's a shortcut." Gotta say that I think it's (a) a nasty punctuation mess (don't we have *enough* of those already?) (b) unnecessary (I don't get grumpy at typing `print') (c) opening up more problems than it's solving G

Draft 2 of RFC 88 version 2.

2000-08-18 Thread Tony Olekshy
=head1 TITLE Structured Exception Handling Mechanism =head1 VERSION Maintainer: Tony Olekshy <[EMAIL PROTECTED]> Date: 18 Aug 2000 Version: 2 (Draft 2) Mailing List: [EMAIL PROTECTED] Number: 88 =head1 DRAFT STATUS Areas of development of this document which are not ye

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

2000-08-18 Thread Jonathan Scott Duff
On Fri, Aug 18, 2000 at 10:09:22AM -0500, Jarkko Hietaniemi wrote: > > The clue is "If a sub wants to return an lvalue, it must B an > > lvalue". Therefore I propose a new keyword C that behaves > > just like C, but returns the lvalue instead of the rvalue. After > > returning, everything is exact

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

2000-08-18 Thread Jarkko Hietaniemi
On Fri, Aug 18, 2000 at 10:30:32AM -0500, Jonathan Scott Duff wrote: > On Fri, Aug 18, 2000 at 10:09:22AM -0500, Jarkko Hietaniemi wrote: > > > The clue is "If a sub wants to return an lvalue, it must B an > > > lvalue". Therefore I propose a new keyword C that behaves > > > just like C, but retur

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

2000-08-18 Thread Jonathan Scott Duff
On Fri, Aug 18, 2000 at 10:27:27AM -0500, Jarkko Hietaniemi wrote: > Error proneness? (Is that a word?) Looks like a word to me :-) > sub foo { > my $lvalue; > ... > return $lvalue if want('LVALUE'); > } Hrm. You're right. sub foo {

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

2000-08-18 Thread Jarkko Hietaniemi
On Fri, Aug 18, 2000 at 10:47:54AM -0500, Jonathan Scott Duff wrote: > On Fri, Aug 18, 2000 at 10:27:27AM -0500, Jarkko Hietaniemi wrote: > > Error proneness? (Is that a word?) > > Looks like a word to me :-) -neness just looked funny... > > sub foo { > > my $lvalue; > > ..

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

2000-08-18 Thread Randal L. Schwartz
> "Perl6" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: Perl6> If a sub wants to return an lvalue, this lvalue must be a real lvalue Perl6> in all respects. In particular, all kinds of implicit and explicit Perl6> value changes must be supported. For example, Perl6> lvsub() = ... P

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

2000-08-18 Thread Johan Vromans
Jonathan Scott Duff <[EMAIL PROTECTED]> writes: > But why introduce a new keyword "lreturn"? What about something like > this? > > sub foo { > my $lvalue : lvalue; > ... > return $lvalue if want('LVALUE'); > } Because you cannot do this with my %has

RFC 132: subroutines should be able to return an lvalue

2000-08-18 Thread Syloke Soong
func(args) = ... func(args) += ... func(args) =~ s/// Such functions have been modeled in object models that accept arg-list+operator (head+operator) polymorphic signatures. It would be up to the programmer of func() to dictate what happens when func() is invoked. The following would

Re: RFC 106 (v1) Yet another lexical variable proposal: lexical variables made default

2000-08-18 Thread Ariel Scolnicov
"J. David Blackstone" <[EMAIL PROTECTED]> writes: [...] > I agree with you. However, I am unable to find a case in which a > package global could not be replaced with a lexical defined in the > module's .pm file and an accessor method for it. Even if you are > extending a class, you can stil

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

2000-08-18 Thread Ariel Scolnicov
"Christopher J. Madsen" <[EMAIL PROTECTED]> writes: > Jonathan Scott Duff writes: > > Excellent summary of why an explicit index is a Good Thing as compared > > to the programmer doing it himself. I think the syntax would need to > > be different though, how do you use implicit $_ and an inde

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

2000-08-18 Thread Mike Pastore
On 18 Aug 2000, Ariel Scolnicov wrote: > Actually, this suggests that C should return > C<(@array)> (a copy of the values), and C the list > C<(0..$#array)>. But those aren't very useful. I like the proposed syntax! I also think that C would be useful, I often use arrays as integer-based lookup

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

2000-08-18 Thread Buddha Buck
At 11:21 PM 8/18/00 +0300, Ariel Scolnicov wrote: >Actually, this suggests that C should return >C<(@array)> (a copy of the values), and C the list >C<(0..$#array)>. But those aren't very useful. I dunno... my @a :sparse; @a[1,5] = (1,1); @k = keys @a; print "@k";# prints "1,2,3,4,5" or "1

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

2000-08-18 Thread David L. Nicol
Mike Pastore wrote: > > On 18 Aug 2000, Ariel Scolnicov wrote: > > > Actually, this suggests that C should return > > C<(@array)> (a copy of the values), and C the list > > C<(0..$#array)>. But those aren't very useful. > > I like the proposed syntax! I also think that C would be > useful, I o

Re: Ideas that need RFCs?

2000-08-18 Thread Nathan Torkington
Stephen P. Potter writes: > * The match operator, C, is always required (bare C becomes a fatal > error). I could live with that. Damian's done some work trying to tokenize Perl and knows what the weird edge cases are. Damian, can you post your short list? > * Replace C, C, and C with equiva

Re: RFCs (Re: Ideas that need RFCs?)

2000-08-18 Thread Bryan C . Warnock
On Fri, 18 Aug 2000, David L. Nicol wrote: > There will Be No Perl7 Of course not. Odd numbers are the development releases. The next Perl after 6 will be 8. Seriously, while a worthwhile goal, this is rather short-sighted. The industry and the world will continue to change in spite (or beca

Re: RFCs (Re: Ideas that need RFCs?)

2000-08-18 Thread Jeremy Howard
> Steve Fink writes: > > And both those examples apply to the underpinnings. Ok, maybe I have an > > unusually broad definition of the word "underpinnings". Think "anything > > that can't be done with a pure perl module". > Say "anything that can't be done *fast*enough* with a pure perl module" an

Re: RFC 23 (v3) Higher order functions

2000-08-18 Thread Nathan Torkington
Damian Conway writes: > me, at least) trivial implementation issues, well documented in the > compiler literature. I choose to ignore them because I *have* to ignore > them or my brain is going to melt. The brief explanations you gave ("here's how it would be translated", and "walk each statement

Re: RFC 23 (v3) Higher order functions

2000-08-18 Thread Nathan Torkington
Damian Conway writes: > $add = ^a + ^b; > # a thousand lines later... > $incr = $add->(1); > # a thousand lines later... > $x = $incr->($x); I picture $add->(1) cloning add's optree, filling in the 1 where appropriate, then returning a reference to the new (cloned) o

Re: RFCs (Re: Ideas that need RFCs?)

2000-08-18 Thread Nathan Torkington
David L. Nicol writes: > RFC: Perl6 is Final. There will Be No Perl7 > > We declare that our framework willbe so flexiblke > that anything can be done with it and there will be no penalty > for something being in-core opposed to out-of-core and so on. Bad idea. You can't make anything

Re: RFCs (Re: Ideas that need RFCs?)

2000-08-18 Thread Nathan Torkington
Steve Fink writes: > And both those examples apply to the underpinnings. Ok, maybe I have an > unusually broad definition of the word "underpinnings". Think "anything > that can't be done with a pure perl module". I'm not wild about that metric, either. Exporter is pure Perl, but I'd love to see

Re: Draft 2 of RFC 88 version 2.

2000-08-18 Thread Glenn Linderman
Peter Scott wrote: > Technically, the only ones of these that impact the core are: message, and > link. The others might be better broken out into another RFC. One RFC for > throwing and handling exceptions; another one for what goes in the exceptions. So that was one thing I tried to do in RF

RE: Draft 1 of RFC 88 version 2.

2000-08-18 Thread Brust, Corwin
-Original Message- From: Peter Scott [mailto:[EMAIL PROTECTED]] or even the cooler throw Exception::MyDB "ABC.1234" => "Some message about what went wrong" O! I like that! I guess I might come to love C after all. I think it would be best to supply a reference. This

Re: RFC 127 (v1) Sane resolution to large function returns

2000-08-18 Thread Nathan Torkington
Perl6 RFC Librarian writes: > There has been a proposed new core function C. this seems > to be generally regarded as a good thing. Fine. If it is implemented > we should use it. Offending functions (See RFC 37) should use > C internally to determine what to return i.e; a list or a hash. This imp

  1   2   >