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
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
> 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
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
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, 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
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
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
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
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
Robert Mathews wrote:
>
> > James Mastros wrote:
> > > [/f for fast DFA regexen]
> Jeremy Howard wrote:
> > The choice of algorithms is a great idea, but why do we need a modifier?
> > Isn't it a pretty straightforward set of rules that allow us to decide if a
> > DFA matcher will work? It woul
Damian Conway wrote:
>
> It was simply attempting to explain why I choose to ignore what are (to
> 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.
So perhaps you sho
Here's my RFC todo list which I am dropping like a good mensch
on the occasion of Friday Evening.
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-
Steve Fink writes:
> True. Would anyone mourn @$scalar_containing_variable_name if it died?
> I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't
> notice $x="var"; print @$x either -- it'll complain if you mention @var
> once.
These are symbolic references. You can forbid them
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
Nathan Wiger wrote:
> Damian Conway wrote:
> >
> > You're error is in assuming I have time *now*.
> >
> > With 30+ RFCs still to write, I've been seriously contemplating
> > just abandoning the Perl 6 effort, because added to the demands
> > of my full-time job, my O'Reilly and other tutorial comm
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
Robert Mathews wrote:
>
> > James Mastros wrote:
> > > [/f for fast DFA regexen]
> Jeremy Howard wrote:
> > The choice of algorithms is a great idea, but why do we need a modifier?
> > Isn't it a pretty straightforward set of rules that allow us to decide if a
> > DFA matcher will work? It would
Peter Scott wrote:
>
> At 05:12 AM 8/19/00 +1000, Damian Conway wrote:
> >> The main downside of accessors is that you can't (currently) say
> >>
> >> local $obj->attribute = 2;
> >
> >Even if C returns an lvalue???
>
> If it does, how do you localize it? What would that mean?
Nathan Torkington wrote:
>
> Don't forget that the rationale behind the infix dereferencing is
> this:
>
> @variable_name
> @{variable_name}
> @$scalar_containing_variable_name @$scalar_containing_value_ref
> @{ code evaluating to variable name } @{ code giving value ref }
True. Wou
> James Mastros wrote:
> > [/f for fast DFA regexen]
Jeremy Howard wrote:
> The choice of algorithms is a great idea, but why do we need a modifier?
> Isn't it a pretty straightforward set of rules that allow us to decide if a
> DFA matcher will work? It would be a lot nicer if Perl could just not
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
James Mastros wrote:
> On Fri, Aug 18, 2000 at 08:46:17PM +0100, Richard Proctor wrote:
> > There is one significant area of perl that has very little attention
here
> > (other than one of my RFCs) that is regexs.
> >
> > Perl has very powerfull regexs - but what other features might be
desirable?
"Casey R. Tweten" wrote:
>
> This looks counter intuitive, my brain says to dereference the reference at the
> begining, just like you make the reference, in other words, keep it all the
> same:
>
> $hashref->{key}->@ # Deref
> $hashref->{key}->$ # Deref
> $hashref->{key}->% # Deref
> $hashref->
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
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.
-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
Nathan Torkington wrote:
>
> Steve Fink writes:
> > We are NOT here to construct a radically better language. We are here to
> > design the underpinnings of one.
>
> Perhaps. And by "perhaps", I mean "no".
>
> We're here to say what we'd like to see in the next version of Perl.
> These can be
[Apologies for following-up my own post]
I wrote:
> You're error is in assuming I have time *now*.
>
> With 30+ RFCs still to write, I've been seriously contemplating
> just abandoning the Perl 6 effort, because added to the demands
> of my full-time job, my O'Reilly and other tu
On Fri, Aug 18, 2000 at 08:46:17PM +0100, Richard Proctor wrote:
> There is one significant area of perl that has very little attention here
> (other than one of my RFCs) that is regexs.
>
> Perl has very powerfull regexs - but what other features might be desirable?
Well, one thing that has aca
Glenn Linderman wrote:
>
> If a curried subroutine is truly generated because of seeing an
> expression containing placeholders, then that expression contains some
> finite number of placeholders. Each placeholder turns into a parameter
> of the generated subroutine. The generated subroutine has,
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
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
Glenn Linderman wrote:
>
> Nathan, thanks for zeroing in on this paragraph from RFC 23. It raises a
> question in my mind about the meaning of the RFC, and whether the paragraph is
> even necessary, which could answer your question about implementation.
>
> If a curried subroutine is truly gene
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
On Sat, Aug 19, 2000 at 06:35:55AM +1000, Damian Conway wrote:
> You're error is in assuming I have time *now*.
>
> With 30+ RFCs still to write, I've been seriously contemplating
> just abandoning the Perl 6 effort, because added to the demands
> of my full-time job, my O'Reilly and other tutori
Jarkko Hietaniemi wrote:
> > $item:n would be the position $item had in the last container it was in
>
> $item:i, you surely meant? $item:n would be the size of the list...
The size of the list would be something like $#{$item:contained_in}
the size of the list is not a property of the item, s
Damian Conway wrote:
>
> You're error is in assuming I have time *now*.
>
> With 30+ RFCs still to write, I've been seriously contemplating
> just abandoning the Perl 6 effort, because added to the demands
> of my full-time job, my O'Reilly and other tutorial commitments,
> my modules, and my poo
> > The subroutines generated by a placeholder are not exactly like
> > the equivalent subroutines shown above. If they are called with
> > fewer than the required number of arguments, they return another
> > higher order function, which now has the specified arguments
> > bound as
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
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
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
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
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
Nathan, thanks for zeroing in on this paragraph from RFC 23. It raises a
question in my mind about the meaning of the RFC, and whether the paragraph is
even necessary, which could answer your question about implementation.
If a curried subroutine is truly generated because of seeing an expressio
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
Damian Conway writes:
>> * Using the pattern returned from some function as part of a regex
>
> /pattern returned from ${\some_function} as part of a regex/
(??{ some_function() }) more generally
>> * Using an array of "words" as an alternate list as part of a regex
> /match any of (${\
"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
> Here is a few throw away thoughts - they don't constitute RFC
> material yet, I am not sure if they would be that useful and have
> not yet thought of any syntax, but any others? All of these can be
> done today but are not necessarily "easy".
>
> * Embeded patterns that do no
> 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
Hi,
There is one significant area of perl that has very little attention here
(other than one of my RFCs) that is regexs.
Perl has very powerfull regexs - but what other features might be desirable?
I had one long term good idea on assignment and submitted that, but there
may be other things peo
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
> 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 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
> 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
> 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
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
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 05:12 AM 8/19/00 +1000, Damian Conway wrote:
>> The main downside of accessors is that you can't (currently) say
>>
>> local $obj->attribute = 2;
>
>Even if C returns an lvalue???
If it does, how do you localize it? What would that mean?
--
Peter Scott
Pacific Systems Design
[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,
Don't forget that the rationale behind the infix dereferencing is
this:
@variable_name
@{variable_name}
@$scalar_containing_variable_name @$scalar_containing_value_ref
@{ code evaluating to variable name } @{ code giving value ref }
Nat
> > 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
[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
Jonathan Scott Duff wrote:
>
> Does the presence of an ordering subroutine cause perl to generate a
> linked list of all the elements of the %hash in the proper sequence
> prior to iteration (and somehow attach it to the iterator)? Seems
> like everytime we did that it would generate a new oper
> The main downside of accessors is that you can't (currently) say
>
> local $obj->attribute = 2;
Even if C returns an lvalue???
Damian
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
> What if the hash keys we want to use are not valid scalar names? For example,
> I've had keys like "total - female" as keys, but using the ^ syntax
> would fail on this...
^{"total - female"}, just like $ variables.
Damian
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,
> > 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
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; #
Today around 2:47pm, Jerrad Pierce hammered out this masterpiece:
: That's pretty damn nifty, too problems though:
Thanks :-)
: print SCALAR $hashref->{key}, "\n";
: is bogus, SCALAR eats the newline as an argument.
: Granted this could be fixed with parens, but somehwat disap
> > 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 (
Nathan Torkington writes:
: Steve Fink writes:
: > We are NOT here to construct a radically better language. We are here to
: > design the underpinnings of one.
:
: Perhaps. And by "perhaps", I mean "no".
:
: We're here to say what we'd like to see in the next version of Perl.
: These can be bi
In reply to your message from the not too distant future: next Friday 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 14:47:44 EDT
From: Jerrad Pierce
That's p
"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
Perl6 RFC Librarian writes:
> =head2 Re-currying deferred expressions
>
> The subroutines generated by a placeholder are not exactly like the
> equivalent subroutines shown above. If they are called with fewer than the
> required number of arguments, they return another higher order function,
> w
This had bugged me too. But the solution I had arrived at is slightly
different. What do you think?
($retval, $scalar) = chomp $scalar;
or
($retval, @list) = chomp @list;
In list mode chomp returns a list whose first element is the return value,
the remainder being the modified value(s).
In cur
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
Steve Fink writes:
> We are NOT here to construct a radically better language. We are here to
> design the underpinnings of one.
Perhaps. And by "perhaps", I mean "no".
We're here to say what we'd like to see in the next version of Perl.
These can be big things (currying) or small (hashes retur
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
Today around 2:04pm, Casey R. Tweten hammered out this masterpiece:
: Today around 10:45am, Steve Fink hammered out this masterpiece:
:
: : Ted Ashton wrote:
: : >
: : > > all
: : > > dereferencing can be done with ->.
: : >
: : > I
Today around 10:45am, Steve Fink hammered out this masterpiece:
: Ted Ashton wrote:
: >
: > > all
: > > dereferencing can be done with ->.
: >
: > Is that "can be done with" or "must be done with"?
: >
: > Either way, I like the ide
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
Ted Ashton wrote:
>
> > all
> > dereferencing can be done with ->.
>
> Is that "can be done with" or "must be done with"?
>
> Either way, I like the idea. To me it reads more smoothly, and as I seldom
> dare to use the double-punctu
Damien Neil wrote:
>
> On Thu, Aug 17, 2000 at 03:10:44PM -0700, Steve Fink wrote:
> > My proposal would be what I implemented for perl5 a while back (Sarathy
> > didn't dislike it, but wasn't convinced enough to put it in): all
> > dereferencing can be done with ->.
> >
> > $x->@ is the same as
> "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;
}
Simon Cozens writes:
: 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
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
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
[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
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
"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
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
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
On 8/18/00 11:56 AM, Larry Wall wrote:
> I'm not sure we have to throw out the orthogonality of OO to data
> structure to get what you want.
Do you mean orthogonality of syntax or implementation? Or both?
It seems like it might be both cleaner and easier to allow "Perl 5 o-o" to
live on largely
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
> "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
> $hour = 0 .. 24
Did you mean 0 .. 23?
> $wday = 1 .. 7 # 1 == Sunday, 7 == Saturday
> I'm still a little uneasy about C<$wday> starting with 1 == Sunday, just
> because Monday seems like the first day of the week to me. But I'm not
> the one writing the calendars, and it
(Damn these CC's!)
On Fri, Aug 18, 2000 at 09:19:55AM -0700, Larry Wall wrote:
> 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.
That's right.
> I'm inclined to think the polymorphic solution w
1 - 100 of 155 matches
Mail list logo
