but in non-lvalue context, I can return the variable directly in the belief that it is not being modified or assigned to.

Your belief is wrong. In order for Perl to determine if the lvalue you return is ever modified, it would have to trace every usage or reference or alias of that variable right through to the end of the program.

Eg.

sub x :lvalue { ...; $lvalue }
...

$y = this( $_ ) ? that( $_ ) : tother( $_ ) for x();
[download]

You may think that is too elaborate an example that will never come up; but to be useful, your wantlvalue() would need to handle that and every other possibility.

Even the 'simple case', of somefunc( x() ); conceals the fact that the lvalue returned by x() is aliased, and within somefunc() could be passed on to still more code as an alias or reference.

For your "belief that it is not being modified or assigned to" to have any validity, Perl would need to follow every possible path to the end of the program before it decide whether to return true or false from wantlvalue().

Imagine the lvalue (or an alias or reference to it) is used in a conditional statement inside a loop; that could be dozens (hundreds/millions) of different possible paths, any of which might modify it.

It would be impossible for a dynamic, interpreted language to provide an "is never modified" guarantee.

And that's before you consider the possibility that an alias or reference to your lvalue might be used as part of a piece of run-time constructed code that gets eval'd.

In non-lvalue context, you can return the direct variable. It doesn't matter if the lvalue is "ever" modified -- only at that point when it is dereferenced. It isn't returned if you are taking a reference to it.

Only in every instance where you dereference it, does it THEN determine context. But passing around a reference is a null-op as far as the object goes. The code in it won't get called as long as one is only taking references to it and passing them around as references or aliases.

In non-lvalue context, you can return the direct variable. It doesn't matter if the lvalue is "ever" modified -- only at that point when it is dereferenced. It isn't returned if you are taking a reference to it.

Sorry, but I think I've been more than patient. That's BS!

Its BS, because you cannot ever know if it is called "In non-lvalue context". Perl provides no mechanism to give you that information.

Wishing it were so does not make it so. Stridently concluded that "you can"; on the basis of your fantasy that you could if perl gave you the information; is stupid.

Stupid, because Perl cannot give you that information!.

Another attempt. This time, try reading the code and understanding it -- not your fantasy vision of it:

sub x :lvalue{ ...; $something }
...

someFunc( x() );
[download]

The value returned from x() is passed to somefunc() as $_[0]; if somefunc() modifies $_[0], it also modifies $something within x(). Perl cannot know if it does!

And someFunc() might do someOtherFunc( $_[0] ); And if someOtherFunc() modifies it's version of $_[0], it will also modify $something in x().

And if someOtherFunc() calls someOtherOtherFunc( $_[0] ); And if someOtherOtherFunc() modifies it's version of $_[0], then it will also modify $something.

And if someOtherOtherFunc()....

It is not possible for Perl to delve into all the calling code; and all the code it calls, and all the code that code calls through to the end of the program run to determine if anything will/could/might modify the lvalue x() returns.

And wish and prevaricate as much as you like; it ain't never gonna happen.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.

In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

Yes you are never returning a read only value.

But as BUK demonstrated the caller could take a reference* and assign later.

In this case your logic would break without a protecting tie.

Anyway did you benchmark the impact of a tie?

IIRC does a tied variable without FETCH method fall back to a normal read.°

Not sure about the resulting performance penalty.

*) Your WANTLVALUE would need reflect this too, like in an extra state "referenced".

°) looks like I was confusing the semantics of Tie::Scalar (with a fallback method) with a normal perltie on scalars, where FETCH must be defined.

This idea of a reference to an lvalue violating the logic inside the object is very confused.

The reference is a reference to an OBJECT.

When you dereference the reference, THEN you access the object which can look at context to see if it is being assigned to or not.

My lvalue object, is not entered and the code in it is asleep when you take a reference to it.

This is the whole reason for wrapping things in an object. While you can pass a reference around or create an alias -- no matter. It's only when you try to assign to the object (the dereferenced thing) OR read from it that the decision code inside the object would look at the return context to see if it is really being modified or is being used in an rvalue context and return a more expensive or cheaper version.

Upon assignment to my object (through references or aliases), I store the new value and do the post processing -- all within the object, then it returns.

So no logic is broken unless someone opens up the object and starts calling internal functions or changing internal values.

If I'm way off base, please explain it to me, as the way I see it is, for this code:

my $ref = \x(); ## lvalue context, no assignment.

... some time later assign through the ref taken.

$$ref = 'anything at all';
[download]

There's no magical getting around 'X()' which isn't called until dereferencing '$ref' w/'$$ref'.

The dereferencing is really doing ${\x()}, which calls x() at the time it is dereferenced (accessed). Only in that final context would it detect if it is being assigned to or not.

Haven't benched-marked anything as I'm trying to figure out a way to not implement it using 'tie' that doesn't allow for optimization. So far, the magic::variable is the most likely candidate as it seems to have a post-store phase where I can update related variables.