Re: RFC 132 (v1) subroutines should be able to return an lvalue
[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
Re: RFC 132 (v1) subroutines should be able to return an lvalue
[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 used equivalently, because a typeglob ref is autodereffed
as need be in I/O operations. (Not to mention *FH{IO}, even.)
2. bless doesn't bless the reference passed, but its underlying referent,
doing an autoderef to find the referent.
and maybe
3.
$glob = 'SYM';
$glob = *SYM;
are equivalent.
--tom
Re: RFC 132 (v1) subroutines should be able to return an lvalue
"JV" == Johan Vromans [EMAIL PROTECTED] writes: These two should have different actions. $foo = foo; foo = $foo; Perl needs a value for one, and a reference for the other. JV I'm not sure I understand what you trying to say here. Please explain. The difference between RHS and LHS. RHS, perl is manipulating values. With LHS perl is manipulating locations, storage areas. Where to put those values from the RHS. So RHS are values (even if a reference, it's meaning as a value is of interest) LHS are pointers. Where to save the value from RHS. So an lvalue sub on the RHS should be returning a _value_ an lvalue sub on the LHS should be tell Perl where to shove^w put the value. (Hey, perl, I want that dohickey put into my array at position 42.) JV - make it unfeasable for methods. Why? All methods for the same OO hierarchy should have the same signature. JV Assume class Foo has a method m that returns a scalar lvalue, and JV class Bar has a method m that returns an array lvalue. The following JV code is now perfectly legal (though weird): JV my $o = $some_condition ? Foo::-new() : Bar::-new(); JV $o-m = another_sub(); JV 'another_sub' calls wantarray. What should it return? That's the point. Perl has to examine $o-m 's return to determine what is going on. So $o- has to be called first. And the resulting reference queried about it's type. And then the want() will return the correct context. In the another_sub( lvalue_sub ), lvalue_sub has to be defered until the first time it is called. (Unless Damian thinks that reaccessing it each time will make more sense.) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 132 (v1) subroutines should be able to return an lvalue
The clue is "If a sub wants to return an lvalue, it must Bbe an lvalue". Therefore I propose a new keyword Clreturn that behaves just like Creturn, 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 call. The :lvalue property is no longer needed and should be removed sine it only causes confusion. A subroutine Bis not an lvalue thing, it Breturns an lvalue if it wants to. Amen. (Tagging a sub to _always_ be an lvalue runs very counter to the flexible context concept of Perl, witness the want()). -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 132 (v1) subroutines should be able to return an lvalue
[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 be list context is with lvsub() = ( ...listy thingy... ); So always enforce scalar context would not cause real pain. Or do you imagine invoking your subroutine before evaluating the right side of the code (so it can return a scalar/list flag of some kind), thereby breaking the normal model of assignment where the right side gets run first? Why not? I couldn't find in the Camel that the right side must be evaluated first (at least not where the assignment operator = is discussed according to the index). -- Johan
Re: RFC 132 (v1) subroutines should be able to return an lvalue
"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;
}
magicguy() = reverse @a;
work the same as:
@a = reverse @a;
So we must evaluate the right code before we start modifying the left.
Oh wait, I'm hosed here. Duh. We can still run the code on the left
to return the lvalue!
In any event, your comment that it should always be scalar is cool,
but would prevent the code I'm giving right here from running.
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. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC 132 (v1) subroutines should be able to return an lvalue
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 :-) Cwant with no arguments returns a list of valid contexts. Cwant with arguments expects a list of contexts and returns true if they're valid. So: want(want) is always true (in fact that's a good conformance test for Cwant). Thus: want(want(want)) is: want($some_positive_integer) which is (almost certainly) false, so: want(want(want(want))) is (almost certainly) false too, etc., etc. Damian
