Re^6: Experimenting with Lvalue Subs

[Aristotle]

He is saying that it would make it impossible to do things like (in spirit)

local $foo->bar = 'baz';

ie dynamic scoping. If the sub was responsible for the actual assignment, this would be impossible because it can't know whether the assignment is scoped dynamically and because there is no obvious mechnism for undoing the assignment at the end of the block. If you require validating to go through a tied proxy object, all of this is trivial since all the existing language hooks work as expected.

[BrowserUk]

I fully understood that bit.

I'm saying that I do not see why that ability would take precedence over being able to validate the value assigned without resorting to callback via tieing (even if it is by the streamlined, inline mechanism). It just seems like an optimisation aimed at the rare case.

I will want to validate every occurance of assignment to an attribute. I (at this stage) cannot see a use for localising it. If it required a callback to achieve localisation for those (I think rare) occasions when I might want to do that but not for the general case , I would see that as a good thing.

But as I said earlier, it is very possible that I am missing the significance of the implementation. I've been sat here trying to understand the P5 code that does this for the last couple of hours and I am none the wiser as to the technical reasoning behind this.

As far as I can tell, with the ability of the code in the sub to decide the target of the assignment at invokation time:

{ 
    my( $x, $y ) = ( 0, 0 ); 
    sub t : lvalue { my $ref = (rand >.5) ? \$x : \$y; $$ref } 
    sub showme{ print "x=$x : y=$y" } 
}

t = 5; showme;
x=0 : y=5

t = 7; showme;
x=0 : y=7

t = 9; showme;
x=9 : y=7

I don't understand the difficulties? The code has to be run to determine the target (and therefore what would need to be localised).

If, at that point, the code produced a warning or died, or rendered a dummy target that prevented the assignment or whatever other action might be appropriate if the rvalue was deemed invalid because it tested the rvalue supplied to it, I don't understand how that would prevent the correct value being localised if it was valid?

[Aristotle]

I (at this stage) cannot see a use for localising it.

Let's just say that this is why Larry is designing the language and not you or I… :-)

I don't understand how that would prevent the correct value being localised if it was valid?

I suppose it could work if the lvalue sub was given the rvalue solely for the purpose of validation, but was expected not to do the actual assignment itself. I'm not sure if that has ramifications past the obvious though — that's something Larry will have to answer.

[BrowserUk]

Let's just say that this is why Larry is designing the language and not you or I

Understood. But I've never needed to do this in the past, (and I assume that were it a common occurance in your programming you would have produced an example), so as hard as I might try, I cannot think of a pressing use for it.

That is, any use beyond the one that is (very breifly) alluded too at the very end of Apo6:

But let and friends need to be blazing fast if we're ever going to use Perl for logic programming, or even recursive descent parsing.

Grammers are the foundation of not just p6 regexes, but at the very core of P6 itself, and (I assume) that grammers (and therefore P6) will require a RDP.

So, reading between the line, I assume that the emphasis on the speed of "hypotheticals" and with them, "temporisable" lvalue subs, is a requirement to ensure that P6 regexes and P6 compilation is fast. If this is the case, it would be nice if that was stated a little more clearly somewhere--even if just in response to questions like this.

That said--and it is only my leap of intuition at this stage--the only way I see of avoiding invoking an lvalue sub twice, whilst retaining the ability to undo lexically localised changes to it, is to actually not assign at the notional point of assignment, but rather defer the actual assignment until the end of the local scope, by proxying the value for the duration of that scope and only making the assignment at the end of the localised scope, if hypothetical is--for want of a better term--realised.

If that is how it will be done, then could not that final rvalue, be provided to the sub at that point for verification? It still comes down to understanding what action might be taken by the sub suthor in the event that rvalue fails verification. And of those actions possible, which would be the cause of an undesirable slowdown in the processing of an lvalue sub?

Like you said, it will probably need LW or TheDamian to resolve that question.