What are the rules for re-binding?

Question

[NOTE: I asked this question based on an older version of Rakudo. As explained in the accepted answer, the confusing output was the result of Rakudo bugs, which have now been resolved. I've left the original version of the Q below for historical reference.]

Raku sometimes prohibits re-binding; both of the following lines

sub f($a) { $a := 42 }
my \var = 'foo'; var := 'not-foo';

produce a compile-time error:

===SORRY!=== Error while compiling 
Cannot use bind operator with this left-hand side

However, Raku allows rebinding in many, many situations – including many that came as a large surprise to me. All of the following successfully rebind; every say outputs not-foo.

my Any \a = 'foo';
say a := 'not-foo';
my Any $b := 'foo';
say $b := 'not-foo';
my @c := ('foo', 'foo');
say @c := ('not-foo', 'not-foo');
my @d is List = ('foo', 'foo');
say @d := ('not-foo', 'not-foo');
my %e := (:foo<foo>);
say %e := (:not-foo<not-foo>);

sub fn1(Any \a) { a := 'not-foo';  say a  }
fn1 'foo';
sub fn2(Any $b) { $b := 'not-foo'; say $b }
fn2 'foo';
sub fn3(@c) {  @c := ('not-foo', 'not-foo'); say @c }
fn3 ('foo', 'foo');
sub fn4(+@d) { @d := ('not-foo', 'not-foo'); say @d }
fn4 ('foo', 'foo');
sub fn5(@d is raw) { @d := ('not-foo', 'not-foo'); say @d }
fn5 ('foo', 'foo');

my ($one-foo, $two-foo) := ('foo', 'foo');
$one-foo := 'not-foo';
say $one-foo;

my \foo = 'foo';
say MY::<foo> := 'not-foo';
sub foo-fn { 'foo' }
MY::<&foo-fn> := { 'not-foo' }
say foo-fn;

my $absolutely-foo = 'foo';
sub fn6 { CALLER::<$absolutely-foo> := 'not-foo';}
fn6;
say $absolutely-foo;

Thus, it appears that rebinding is currently allowed to any name, regardless of the sigil or lack of sigil, if either of the following conditions are met:

1. The name has any explicit type constraint (including Any and the type constraints imposed by the @ or % sigils), or
2. The rebinding uses a qualified name.

This rebinding currently happens for both declared variables and parameters, and includes parameters that are not rw or copy. It even, as the last example indicates, allows re-bindings in ways that (seem to?) violate lexical scope. (That example was based on a Roast test that's annotated with the comment -- legal?, which suggests that I may at least not be alone in finding this behavior surprising! Though the test re-binds a is dynamic variable – in some ways, the behavior above is even more surprising).

As far as I can tell, the only names that cannot be re-bound using one of these approaches are those declared as constant.

So four questions:

1. Am I correctly describing the current behavior? [edit: that is, do the two rules I listed above correctly describe current behavior, or does a correct description require other/additional rules?]
2. Is that behavior correct/intentional/in line with the spec? (Despite the presence of S03-binding, I've found remarkably little on rebinding).
3. If this behavior is not intentional, what are the rules about rebinding supposed to be?
4. Is there any way to tell Raku "don't rebind this name to a new value, no-really-I-mean-it"?

(This question supersedes my earlier question, which I asked before I realized how easy it is to re-bind name; I'm closing it in favor of this one. Another related question: Is there a purpose or benefit in prohibiting sigilless variables from rebinding?, which discusses some of the design tradeoffs from the assumption that sigilless variables cannot be re-bound, contrary to several of the examples above.)

Answer 1

A decidedly non-authoritative answer. Curiously, like jnthn in your prior Q, it feels natural to answer your questions in reverse order:

Is there any way to tell Raku "don't rebind this name to a new value, no-really-I-mean-it"?

As far as I can tell so far -- purely by testing variations, not by checking roast or the compiler source -- you can and must declare a sigil free symbol, and it must not be one declared with my \symbol ...:

constant foo = 42;
class bar {}
enum baz <a b>;
subset boo;

As far as I can tell, the above declarations permanently bind their symbols to their declared values during compilation of their enclosing compunit, and attempts to modify these symbols, eg MY::<foo> := 99;, are silently ignored.

---

Note that use of constant doesn't address whether the bound value is immutable:

constant foo = [42];
foo[1] = 99;
say foo; # [42 99]

If you want absolute immutability, an absolutely immutable binding isn't enough. You must make sure the bound object/value is also absolutely immutable.

---

Note that this declares a sigil'd identifier, so you can modify what it's bound to:

sub f { say 'foo' }
MY::<&f> := { say 'boo' }
f; # boo

---

If this behavior is not intentional, what are the rules about rebinding supposed to be?

My guess, for what that's worth, is that everything is as it's supposed to be.

---

A couple weeks ago, in response to you showing that one could rebind a sigilless variable declared with my Int \foo = 42;, I wrote:

Right now what you've shown in this Q smashed my mental model

But that that was then. And the "Right now" hints at something I've learned to cherish in my experience of Raku, still now, 10 years after first seriously getting into it. Each time I experience such a surprise, I remember I would be well advised to remain fundamentally open to changing my mind. And sure enough, as I wrote in an earlier version of this answer:

I've concluded in retrospect that it all makes perfect Rakunian sense to me.

Huh?

• What happened to smash my mental model? I formed (and, worse, promulgated /o) an incorrect mental model that sigilless variables were necessarily Static Single Assignment. Then I confronted some code that fun da mentally didn't fit that model. Smashing!

• What happened since then? I concluded that the SSA aspect is only true for sigilless variables declared with constant. And that my "smashing" reaction was due to my having long held the wrong mental model. Any that, while I must now atone for my sin of cooperating with other misinformed Rakoons in promulgating that wrong mental model to innocent folk like yourself, I needed to get over it fast and completely. So then I opened my eyes and realized Raku was just being Rakunian.

• What do I mean by "Rakunian"? I think Larry Wall gets the late, great John Shutt's point about Irregularity in language:

  Irregularity is a natural consequence of the impedance mismatch between the formal structure of language and the sapient semantics communicated through it ... large parts of a language, relatively far from its semantic core, may be tolerably regular, but the closer things get to its semantic core, the more often they call for variant structure. It may even be advantageous for elements near the core to be just slightly out of tune with each other, so they create (to use another physics metaphor) a complex interference pattern that can be exploited to slip sapient-semantic notions through the formal structure.

  (Even if Larry does not see things as John did, I do, and think it's one of the principles underlying Raku's semantic core. Well, not Raku's semantic core in the sense of the underlying single semantic model. But here we're focusing on Raku's current standard surface syntactic dialect, so I'm talking about "semantic core" in that context.)

  I would say that declaring and varying (or not) the value of identifiers is close to the semantic core of Raku's standard dialect, and that Raku's related variants are slightly out of tune with each other in useful ways. Specifically, in the context of declaring sigilless identifier variables:

  • = always binds rather than assigns.

  • constant foo = ...; Immutably binds to a value at compile time. (I do wonder at the huffman coding. I've long pondered new declarators a, an, and the, where a and an are aliases for my constant and the is an alias for our constant, which is what a constant means if written without a scope declarator prefix.)

  • my \foo = ...; Binds at run-time; may be rebound by using := with a MY reference.

  • my Type \foo = ...; Like my \foo...; but may also be rebound by using :=.

---

Is that behavior correct/intentional/in line with the spec? (Despite the presence of S03-binding, I've found remarkably little on rebinding).

The official definition of "spec" is roast (repository of all specification tests).

Part of officially releasing a version of the Rakudo compiler is to ensure it has passed roast.

So if you've compiled and run code with an officially released Rakudo, the behavior is officially per spec.

---

Am I correctly describing the current behavior?

You've provided code, which compiles and runs, so by that definition, which is the only sane one imo, that code indeed correctly describes the current behavior, where "current" implies the version of the compiler being used (which in turn will have been tested against some particular version of roast, which version should iirc have been git tagged to correspond to a particular official revision of the Raku language).

Answer 2

The name has any explicit type constraint (including Any and the type constraints imposed by the @ or % sigils), or

I don't think the type constraint should be relevant here. Every container in Raku has an implicit or explicit type constraint (even if it's Mu). Making things rebindable by putting an Any in front of it reeks of a bug.

Instead, I think the rule is that you can rebind a name unless the compiler knows that it's read-only.

Off the top of my hat, the following cases are known to be ready only:

• block/routine parameters
• lexical subs (ie &f after sub f ...)
• any sigilless name (my \x = ..., class A { ... }, constant a = ...)