Re: RFC 128 (v1) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
=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.
=head3 Named arguments
It is further proposed that arguments may be passed by name, and that
named arguments may be passed in any order.
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 instead of ':', which
makes it look more like the current CGI and Tk modules, but can live
with ':'.
A few questions:
- Do we envisage something similar for method calls?
This would, of course, shift a large part of the burden of this scheme
to run-time.
- Do we support creating a named parameter list at run-time?
Right now I am a heavy user of the hash-like notation and I've got quite
a few subroutines with variable named arguments. My subroutines now
have to do the validity checking themselves. If we have this nice new
scheme, I'd be very happy for it to support dynamically created, but
still checked, named arguments.
Once again, this shifts a portion of the work to run-time.
- Would we also want to support this one step deeper?
For instance, with the DBI 'connect' call, you can specify options like
this:
$dbh = DBI-connect('dbi:Sybase:server=foo', 'name', 'pwd',
{ RaiseError = 1, AutoCommit = 0 });
It might be nice (but maybe also unwise) to check the options in the
fourth argument...
Hildo
Re: Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
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 or returning it as an lvalue does not count as an access.
Can this be used to implement a Jensen device:
sub work($i,?$j) {
for $i ( 1..10 ) {
print "$i: $j\n";
}
}
my $foo;
work($foo, $foo*$foo);# prints 1 4 9 16 ...
-- Johan
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
RFC 132: subroutines should be able to return an lvalue
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 be the pseudo-code (nothing to do with perl) that
simulates the operator as another argument.
overloadfunc...
func (operator:args){...}
func (+:args){...}
func (=:args){...}
func (+=:args){...}
func (=~:args){...}
func (args)
Which allows the following invocation:
a = func(args);
a = b + func(args);
a = func(args) + func(argt);
func(args) = a;
func(args) = func(argt) + func(argu);
However such an invocation is problematic:
func(argt) + func(argu) = anything else;
For such, I recommend that, for each LHS function create a thread. All LHS
threads would then have to cooperate to come to their individual resolution.
That would require multi-threading stability in Perl.
It is recommended to read the RFC in the perspective of object modeling in Perl.
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
