HaloO,
David Green wrote:
I would expect all of those to work the same way in either case. That
is, anywhere the sub is used as an lvalue, it could pass the rvalue as a
special arg, not just when using "=".
I agree. But I want to stress that the big thing is that a lvalue
sub---and to a lesser degree also postcircumfix .[] and .{}---wants
to see its own parameters *and* the rvalue to be assigned.
This data must in general be woven into the control flow of the
sub invocation. That is, when returning a proxy doesn't cut the
whole intension we need something along my yield statement that
joins the functionality of a declarator for a variable to return
as lvalue and capturing the current invocation for later resumption.
OK; but I think that can be handled by a mutating sub -- assuming the
issue is that the proxy-sub "sub foo is rw { blah; $proxy }" runs "blah"
once and returns the proxy that can be assigned to multiple times,
I would prefer to switch back into the sub invocation whenever it is
used in lvalue context. Abandoning control by returning a passive
proxy jumps too short in my eyes.
whereas a mutating sub would run "blah" every time you use it. But:
Hmm, in a statement like
foo(1,2) = 3;
the assignment is the operator that sees both sides involved in the
assignment. And I think it will be the one that other assignment forms
like += and ++ dispatch to unless specifically overridden. My idea is
that foo sees the 1 and 2 as args and prepares itself for rvalue or
lvalue use later in the dispatch. For rvalue use the halted invocation
is garbage collected but in lvalue context the invocation is resumed
by the assignment. This is the point in time when foo "knowns" that
it is in lvalue context and the rvalue 3 is available to the sub as
well. This is a bit like the fork system call where the parent and
child branch into different parts of the code.
sub foo is rw($rval) { unless want~~:($ is rw) { blah };
$unproxy=$rval; }
In other words, the mutating-sub-way can do everything the proxy-way can
(and more), as long as we can tell when being used in lvalue-context.
I think my yield proposal handles all that fine. And it is a more
general concept that is used for coros as well.
Incidentally, now that Perl is all OO-y, do we need tying/proxying like
that, or can we just override the "=" method on a class instead?
It's possible that in perl6, 'STORE' could be spelled 'infix:<=>'; but
then how would 'FETCH' be spelled? And doing so would require that
your storage routine return a value, even if you never intend to use
it. No; I prefer 'STORE' and 'FETCH' as the basic building blocks of
anything that's capable of working like a rw item.
How would the syntax for STORE and FETCH look like in a sub
definition and how would it be related to the invocation involved
in the operation? Note that I make the conceptual unifications
of class and sub definition on the one hand and an object and an
invocation on the other. In the object case the self built-in refers
to the object. Would that work in a STORE or FETCH block of a sub
as well?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
