On Mon, Sep 17, 2012 at 10:14:28AM -0700, [email protected] via RT wrote: > On Mon Sep 17 09:34:45 2012, nicholas wrote: > > Yes, there is an ulterior motive to this bug report. I'm not confident > > that > > read only aliases are actually an optimiser win. You mustn't assume > > that the > > aliased value remains unchanged by any opaque action, such as a > > function > > call, else you break correctness. > > > > I'm not sure the point is optimisability so much as it is stopping > people changing the arguments and accidentally updating things in the > caller, unless that's specifically declared as being the intent (using > 'is rw' or the backslash parcel syntax).
Yes, this was what I was wondering. In which case, it would mean that a read-only copy would be just as effective (from the user point of view) at achieving this. From the implementation side, if efficient copy-on-write exists, then it doesn't make much difference, does it? > As for Rakudo's current semantics, it works by taking the argument from > its container - if it has one - and placing it into a readonly > container. That's why it has the snapshot semantics. It's been that way > for a long time, and it's curious the first ticket that notices is one > trying to prove a point. :-) But I'm not sure what point I'm trying to prove. I think the initial problem is "Rakudo and the spec disagree. That means that at least one is wrong." The backstory: It (obviously, or maybe not so obviously) started with the discussions about function signatures for Perl 5. To my mind (I may not be representative here), it seems best to stay the same as Perl 5, if there isn't good reason to do otherwise. So, "read only aliases" seem a sensible default, on the assumption that they're actually cheap. But in Perl 5 they don't look to be. (There are no vtables to swap out to make proxy objects, or something, so you have to do the test for "is this an alias" everywhere you look at something. This gets expensive.) So it's a false economy in Perl 5. Getting copy-on-write seems a better plan. Aliases cost everywhere because you have to chase a pointer to the original. But it got me thinking - surely Perl 6 has to do this too? With gradual typing, Perl 6 has a fighting chance of do optimisations that static languages take for granted. But static languages can't assume too much. (and related to enthusiastic discussion about LLVM, and what it might be able to do) in particular, C can't assume that a function call isn't going to change the value of memory at the end of a pointer. So it can't merge dereferences from before and after a function call. So a true alias, even if it's read only, can be treated to all sorts of sensible desirable optimisations. Whereas a read-only (copy) can. So it comes back to "Rakudo and the spec disagree". Rakudo seems to actually be implementing read only copies, on the basis that this is more performant. But if this is a much better strategy, who is right long term? The spec? In which case, is Rakudo going to have to be fixed to match the spec? And pessimise 99% or more of programs for a pathological few? That doesn't feel right. But it also feels very wrong that the spec says one thing, and the implementation does something else. So I guess my question is really a request to step back, and answer "what is the spec trying to achieve here?" Because I'm not comfortable that the design it describes aligns with its underlying goals. Nicholas Clark
