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
