On Tue, 13 Aug 2002, Larry Wall wrote:

> On Tue, 13 Aug 2002, Deven T. Corzine wrote:
> : However, will the "func($x{1}{2}{3})" case cause an implementation problem?
> 
> This is why the new function type signatures will assume that
> parameters are constant.  If you want a modifiable parameter, you
> have to say "is rw".  Then it's considered an lvalue.  In Perl 5,
> all function args had to be considered potential lvalues.

That will certainly help.  What about the "is rw" case, though?  Will we be 
able to avoid autovivifying the parameter if it's never actually assigned, 
or do we assume this edge case isn't worth the hassle, and assume it will 
follow Perl 5's behavior for such variables?

> In essence, all Perl 5 functions have a signature of (*@_ is rw).
> Perhaps the translator can turn some of those into (*@_).  What'd
> really be cool is if it could pick up an initial
> 
>     my ($a, $b, $c) = @_;
> 
> and turn it into an appropriate signature.

That would be pretty cool.  It would also be nice to handle the common 
alternative form of using "shift" as well...

> Of course, there are issues here if the code modifies those variables, 
> since the issue of whether a variable is rw is really distinct from 
> whether it represents a pass by value or reference.  Slapping a 
> "constant" on it is a bald-faced attempt to get the speed of 
> pass-by-reference with the guarantees of pass-by-value.

The only accurate way to know if the code modifies the variables is to do 
some sort of dataflow analysis, and it can't be 100% accurate even then.  
(Suppose a "shift" may or may not happen, depending on the parameters, then 
$_[2] is modified?)  Of course, it should often be possible (at least in 
principle) to determine that it's impossible for a particular parameter to 
be modified, and play it safe by assuming "is rw" for undeterminable cases.

> Perhaps there should be a way to declare a parameter to be pass-by-value, 
> producing a modifiable variable that does not affect the caller's value.  
> But I'm not sure saving one assignment in the body is worth the extra 
> mental baggage.

I'd argue that it's worthwhile -- not because of the cost of that single 
assignment, but because you'd now have two variables to keep track of, the 
original parameter and the modifiable copy.  This seems like greater mental 
bagger (to me) than remembering another modifier.

How about "is copied" as a pass-by-value modifier?  (I was inclined to say 
"is a copy" but I didn't think a 3-word phrase would be desirable here...)

Deven

Reply via email to