Copy-restore on parameters? (was Re: Autovivi)
On Wed, 14 Aug 2002, Luke Palmer wrote:
Why? We could make arglists exactly equivilent to the way they're done in
Perl 5, which is a good way.
sub foo($a, $b, *@c) {...}
Would be exactly equivilent to Perl 5's
sub foo { my ($a, $b, c) = _; ... }
I've got another idea. How about using a copy-restore technique?
First, assume all arguments are pass-by-reference, whether constant or not.
Second, allow is ro as a modifier to force constant semantics -- in this
case, don't make a copy, just use the reference and refuse to modify it.
Third, allow is rw as a modifier to enable copy-restore, and to make the
reference modifiable.
Fourth, copy all named parameters into local variables from the passed
reference (except for is ro parameters, which should be aliased) -- and
then keep _ with the actual references, as in Perl 5. (Unlike Perl 5, the
is ro parameters would not be modifiable even via _.)
Finally, for is rw parameters, copy the modified local variable back to
the referenced parameter (the original one, even if _ was shifted!), but
ONLY for a normal subroutine exit.
This would allow pass-by-value semantics by default for convenience, easily
forced read-only parameters, pass-by-reference semantics when desired, but
with a twist -- if the function aborts (throws an exception), no parameters
have been changed, which offers hassle-free transaction-like atomicity.
If a function really wants to modify its parameter, despite throwing an
exception, it could do so via _ directly. Or, we could also allow another
modifier is ref to use simple (modifiable) pass-by-reference semantics,
but default to copy-restore for is rw...
This seems like it could be the best of all worlds -- what do people think?
Deven
Re: Copy-restore on parameters? (was Re: Autovivi)
On Thu, 15 Aug 2002, Deven T. Corzine wrote: : I've got another idea. How about using a copy-restore technique? I suspect that would make Perl 6's sub calls even slower than Perl 5's. Larry
Re: Copy-restore on parameters? (was Re: Autovivi)
On Thu, 15 Aug 2002, Larry Wall wrote: On Thu, 15 Aug 2002, Deven T. Corzine wrote: : I've got another idea. How about using a copy-restore technique? I suspect that would make Perl 6's sub calls even slower than Perl 5's. Yes and no. For the normal case (pass-by-value semantics), it should be about the same speed as Perl 5, since it would be doing the same thing: making a copy of a value that was passed by reference. For the is ro or is ref case, it should be FASTER, since it could avoid the copy by aliasing the reference. Only the is rw case would be slower, since it would involve two copies rather than one. However, it would offer a benefit of rolling back any changes to the parameters in case of an abnormal exit from the function. This seems like a valuable feature that could often be useful -- and anyone who wants to avoid the speed penalty could stick with is ref, assuming that option is also allowed... Deven
Re: Copy-restore on parameters? (was Re: Autovivi)
On Thu, 15 Aug 2002, Deven T. Corzine wrote:
On Thu, 15 Aug 2002, Larry Wall wrote:
On Thu, 15 Aug 2002, Deven T. Corzine wrote:
: I've got another idea. How about using a copy-restore technique?
I suspect that would make Perl 6's sub calls even slower than Perl 5's.
Yes and no.
For the normal case (pass-by-value semantics), it should be about the same
speed as Perl 5, since it would be doing the same thing: making a copy of a
value that was passed by reference.
For the is ro or is ref case, it should be FASTER, since it could avoid
the copy by aliasing the reference.
Only the is rw case would be slower, since it would involve two copies
rather than one. However, it would offer a benefit of rolling back any
changes to the parameters in case of an abnormal exit from the function.
This seems like a valuable feature that could often be useful -- and anyone
who wants to avoid the speed penalty could stick with is ref, assuming
that option is also allowed...
You're talking about exception safety. First of all, to have a
language feature automatically enforce exception safety is too
inefficient. The fastest way to do it is problem-specific. Stroustrup
wrote big papers discussing this.
The first issue: Methods. Even though your routines are safe to the
parameters, they still wouldn't be safe to attributes of the object, which
is often the kind of safety that's important anyway.
The second issue: Awful, awful speed. Take for example this sub:
sub randinc(ar is rw) {
ar[ int rand ar ]++;
}
Where ar has 5000 elements. You don't really want to copy that whole
array twice just to increment one element (There might be some internals
stuff going on that would make this normal). Note that this function is
already exception safe even without your copy-restore semantics.
I think I see where Larry's going with the read-only reference. Perl 5
sub calls are notoriously slow, so people are sometimes afraid to use them
a lot. So it's making them faster. That and there's well defined, easy
semantics; i.e. every time a copy is being made, it's explicit. I can see
the advantages of this.
But back to exception safety. Perl needs some way to handle exception
safety if it's going to be as powerful as we say. As far as large data
structures: will this run in constant time?
(a, b) = (b, a)
If so (and the same holds for hashes), then there's probably no need to
build in anything else besides CATCH blocks, etc.
That was a digression and a half. Sorry. :)
Luke
