Apply a proxy to a variable (not an attribute) using traits

user_10173009 0
Viewed 157

This question is a near-duplicate of Apply a proxy using traits. However, that question dealt with applying a proxy to an Attribute, and I would like to do the same thing for a Variable. From Jonathan's answer, I understand that I

need to arrange for the Proxy to be bound into the attribute, so that there's a Proxy there rather than a Scalar container that is usually created by class initialization logic.

However, I can't seem to bind successfully to a Variable:D, even at compile time. (Including with nqp::bind). I'd greatly appreciate any pointers in the correct direction.

(Ideally, I'd like to support using the variable/trait with assignment syntax. In a perfect world, I'd have syntax like:

my $thing is custom-proxy = 42;

And the result of that would be that $thing is containerized inside the Proxy, but not in a Scalar. But if that's not possible, I'd settle for getting it working with binding via :=.

[EDIT: building on the accepted answer below, it is possible to mostly do this with the following code:


multi trait_mod:<is>(Variable \v, :$tom) {
    v.block.add_phaser(
        'ENTER',
        v.willdo(<-> $_ {
            $_ = Proxy.new:
                     STORE => -> $, $v { say "store $v" },
                     FETCH => { say "fetch!"; 42}
                }, 1))
}

This works for variables that are not initialized to a different value or for state variables on calls to the function other than the first.

rakudo raku
2 Answers

You can always bind.

my $actual-thing = 42;

my $thing := Proxy.new(
    FETCH => anon method fetch () {
        say 'fetch';
        $actual-thing
    },
    STORE => anon method store ($new) {
        say 'store ',$new;
        $actual-thing = $new
    }
);

say $thing;
$thing = 5;
say $thing;

Which currently results in the following.

fetch
fetch
fetch
fetch
fetch
fetch
fetch
42
store 5
fetch
fetch
fetch
fetch
fetch
fetch
fetch
5

(The repeated FETCH calls are a known limitation.)

If you wanted to have syntax like

my $thing is custom-proxy = 42;

You would need to start with

multi trait_mod:<is> ( Variable:D \var, :$custom-proxy! ){
    …
}

The problem is that currently doing it this way requires a lot of deep Rakudo/nqp knowledge that I do not possess.

For example the code behind my $var is default('value') looks a bit like this:

multi sub trait_mod:<is>(Variable:D $v, Mu :$default!) {
    my $var  := $v.var;
    my $what := $var.VAR.WHAT;

    my $descriptor;
    {
        $descriptor := nqp::getattr($var, $what.^mixin_base, '$!descriptor');
        CATCH {
            my $native = $v.native($what);
            …
        }
    }
    …
    $descriptor.set_default(nqp::decont($default));

    # make sure we start with the default if a scalar
    $var = $default if nqp::istype($what, Scalar);
}

Why does that have $what.^mixin_base?
I have no idea.

Why isn't $!descriptor accessible something like $v.var.descriptor?
I have no idea.

How do we change $v.var.VAR from a Scalar to a Proxy?
I have no idea.

Is that last one doable? (From within a trait_mod:<is>) I am fairly certain that the answer is yes.

Brad_Gilbert_13370

My 2d[1]:

I'd settle for getting it working with binding via :=.

sub custom-proxy is rw { Proxy.new: FETCH => { 42 }, STORE => { ... } }
my $variable := custom-proxy;
say $variable; # 42

In a perfect world, I'd have syntax like:

my $thing is custom-proxy = 42;

Aiui, that's @Larry's intent.

But, as you presumably know, if a type (eg role custom-proxy { ... }) is applied using an is trait to a scalar variable (eg my $variable is custom-proxy) then the compiler emits a compile time error message (is trait on $-sigil variable not yet implemented).

I can't seem to bind successfully to a Variable:D, even at compile time

First, let's clarify what a Variable is, and what you would need to successfully bind to:

multi trait_mod:<is>(Variable \var, :$foo!) { say var.var.VAR.WHAT } # (Scalar)
my $variable is foo;

You might think you could bind to var. But the compiler is passing an lvalue, so you're not going to be able to alter it.

You might think you could bind to var.var, which is an attribute of a Variable. (I explain what a Variable is, and its var attribute, and why I had to write "varvarVAR!" in the above code, here.)

The SO you linked shows how to alter the value bound to an attribute in some object:

$a.set_build: -> \SELF, | {
  $a.set_value: SELF, Proxy.new:
    STORE => -> $, $val { say "store $val" },
    FETCH => { say "fetch!"; 42 }
}

So perhaps you could use that approach to alter the .var attribute of a Variable?

Unfortunately, "setting build logic" is used to "bind the attribute ... at each object creation", (hence "you'll be overriding any initial default value").

So I don't think this technique is going to help in this case because the Variable, and hence its .var attribute, has presumably already been built by the time the Variable is passed to the is trait.

In summary, while a trait is called at compile-time, I think it's called too late because the var attribute has already been permanently bound.

My guess is that altering Raku(do) so that the Variable's .var attribute becomes writable, or using metaprogramming to dive underneath Variable's public API to force through a change, would be beyond fraught, unreasonably complicating the compiler's variable handling code and/or swapping out codegen optimization logic for pessimization logic.

This may be behind @Larry's speculation that a more controlled is type on scalar variables will one day be implemented.

Footnotes

[1] My two (pennies | dogecoin).

user_10776720
Related