> 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 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
[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;
}
> > 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
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
[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
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 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
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
What about?
sub foo { lreturn ($one, $two, $three); }
foo = (0..10);
or
foo = &bar;
The compiler needs to know what foo is returning. The attribute tells
perl evaluate foo to determine the context (i.e. where to put the
dirty laundry) and the goes ahead and does the re
Perhaps foo should be lazily evaluated.
Then the want would return the correct usage. Though once the value
is returned, it should stay that way on all subsequent usages until
the call stack is unwound.
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> > Besides, context can't always
> If you do it as scalar only. You lose a lot of useful possiblities.
This is indisputable.
> Why do you mind having an attribute?
The problem would seem to be that an lvalue subroutine might return
either an array or a scalar, depending on its arguments. That *can't*
be resolved at compi
[Quoting Chaim Frenkel, on August 20 2000, 00:54, in "Re: RFC 132 (v1) sub"]
> Why do you mind having an attribute?
An attribute would
- require the sub to be consequent in what it returns;
- require the sub to be predeclared before it can be used;
- make it unfeasable for methods.
-- Joh
> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes:
JV> An attribute would
JV> - require the sub to be consequent in what it returns;
I can't parse that line.
JV> - require the sub to be predeclared before it can be used;
lvalueness seems to be appropropriate.
These two should have
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> JV> An attribute would
>
> JV> - require the sub to be consequent in what it returns;
>
> I can't parse that line.
With an lvalue atttribute, a sub is assumed to always return an
lvalue. The lreturn proposal makes it possible for a sub to determin
> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes:
>> These two should have different actions.
>>
>> $foo = &foo;
>> &foo = $foo;
>>
>> Perl needs a value for one, and a reference for the other.
JV> I'm not sure I understand what you trying to say here. Please explain.
The difference be
Perl6 RFC Librarian wrote:
>
> As a thought guide: think of C returning a reference to its
> argument, and the call to lvsub() performing a dereference.
Thought guide? Given a macro language and reference reasonablizing,
this looks like you've just compeltely defined lreturn!
macrod
>From rfc 98:
> =head2 acceptable coercions
>
> When resolving which method C to call in a context CTXT, and there
> is no method C defined for the context CTXT, Perl will examine
> the types listed in C<@CTXT::ISA{OVERLOAD_CONTEXTS}> for a list
> of other contexts
> to see if C can produc
[Quoting David L. Nicol, on August 21 2000, 23:06, in "Re: RFC 132 (v1) sub"]
> Looks like a case for automatic dereferencing!
Which Perl has always stated it would _never_ do.
Well, this could be the time of changes.
-- Johan
>[Quoting David L. Nicol, on August 21 2000, 23:06, in "Re: RFC 132 (v1) sub"]
>> Looks like a case for automatic dereferencing!
>Which Perl has always stated it would _never_ do.
Kinda.
To be honest, Perl does do autoderef in at least two places.
1.
$fh = *FH;
$fh = \*FH
can be us
30 matches
Mail list logo
