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.

the only way I see of avoiding invoking an lvalue sub twice, whilst retaining the ability to undo lexically localised changes to it

But there is a simple way. If the lvalue sub is not responsible for changing the value itself, but rather only responsible for providing a normal lvalue ie a scalar or such, then you can use the same mechanisms to handle hypothetical values on that scalar or whatever it is as you do everywhere else — after all, there's nothing special about it.

Incidentally, that is exactly the situation we already have.

Your deferred assignment proposition OTOH is a non-starter if you consider that that same lvalue sub can itself serve as an rvalue in another occasion during the same dynamic scope. In fact, it (or the underlying effective lvalue assigned to) must serve as an rvalue somewhere at some point, because otherwise, what is the purpose of assigning a dynamically scoped value to it in the first place?

Makeshifts last the longest.

I do see what you are saying. The call to the lvalue sub is made in order to obtain a reference to a scalar or other lvalueable entity. And it is that reference that will be localise.

But the suggestion is that the programmer can validate the assignment by tieing the lvalue. If the programmer can do this, then the code generator could too. Rather than forcing the programmer to do this for every attribite of every class, couldn't the generator do it for him under the covers? Isn't that the essence of code reuse? If the value was presented to the sub as $^_ (for example) and that was tranparently tied.

Your deferred assignment proposition OTOH is a non-starter...

So what is wrong with proxying the sub locally?

In p5 terms:

#! perl -slw
use strict;

{
    my $x = 5;
    sub x : lvalue {
        $x;
    }
}

print x;

if( 1 ) {
    no warnings 'redefine';
    our $temp;
    local $temp = x;
    local *x = sub : lvalue{ $temp };
    
    print x;
    x = 123;
    print x;
}

print x;
__END__
P:\test>424776
5
5
123
5
[download]

And then whatever mechanism will be in place to 'realise' the hypothetical as a real value at the end of scope, would instigate the call to the real sub (or not) as required by the logic of the code.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.