Greetings. In implementing :=, I have discovered two different
set of semantics in explantations.  I will refer them as "linking" and
"thunking".

The "linking" semantic is akin to hard links in filesystems.
It takes the storage location in the RHS and binds its to the
name in the LHS:

    $x := $x;               # no-op
    ($x, $y) := ($y, $x);   # swap

The "thunking" semantic is akin to symbolic links in filesystems.
It takes the expression in RHS and wraps it in an implicit closure,
then give that closure a name to be triggered later.
A12 has an example:

    $endpos := $string.chars;    # thunk, changes as $string changes

Now, those two semantics directly clash when the RHS can be
interpreted both ways.  One good example would be array dereference:

    my ($x, @a);
    $x := @a[-1];
    @a = (1..100);
    say $x;

Under the linking semantic, there is no location in RHS to bind yet.
One possible interpretation is just autovivify it -- but [-1] is not
autovivifiable, so it should throw out an fatal exception under the
linking semantic right there.  Under the thunking semantic, of course,
it will work as expected.

Assuming the thunking semantics however, I am not too sure about how
this can possibly work:

    ($x, $y) := ($y, $x);   # swap?

One interpretation is that the RHS pad bindings are snapshotted,
so future calls to $x always evaluates the bound "$y" at the RHS
context, and hence give correct results.  This would mean:

    my ($x, @a);
    $x := @a[0];
    @a := ($x, $x, $x);
    $x := 1;
    say @a; # (undef, undef, undef)

Okay, that looks good to me.  Should I go ahead and implement
the thunking semantics?

Thanks,
/Autrijus/

Attachment: pgpMbay14Ela7.pgp
Description: PGP signature

Reply via email to