> 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
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.
/--- 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
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
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
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 "
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.
> =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
> > 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
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,
> 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
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
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
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.
>
> ($
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,
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
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
> 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
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
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
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
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
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
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
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
> 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
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
[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
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
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
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
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
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
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
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
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
-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
"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
[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
> "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;
}
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
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
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
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,
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
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
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
> 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
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
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
"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
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
> 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
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
> > 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 (
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; #
> 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
[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,
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
> 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
> 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
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
> > 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
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
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
[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
> > 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 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
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
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
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
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.
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
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
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
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
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
=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
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
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
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 {
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;
> > ..
> "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
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
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
"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
"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
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
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
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
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
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
> 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
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
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
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
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
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
-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
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 - 100 of 155 matches
Mail list logo
