HaloO,
Larry Wall wrote:
In this case it desugars to
my $pi is constant = 3;
:-)
In other words the assignment to a my turns into an ordinary assignment
that happens at runtime. Hopefully, since $pi is marked constant,
it could be optimized to a binding in many cases, but that's not the
semantics, and the difference shows up on objects pretending to be
values that have to be copied under assignment. If you don't want
a copy every time the "my" is instantiated you need to use := instead.
Is it arguable to imagine the above beeing implemented by dispatching to
&infix:{'='}:(Item of Undef is constant, ::T.does(none(Undef) & Item)
--> ::T is constant)?
The Item of Undef is the return type of my and the is constant in the
return type prevents subsequent handling as lhs by standard targets of
&infix:{'='} or &infix:{':='} dispatches? Other mutator dispatches
like rw ref taking are excluded as well. To me it is a natural extension
of the concept of "interesting values of undef".
Constant value rapers/enchanters can of course still write non-standard
targets and I don't know how prospective victims/receivers can prevent
that fate/bliss. The German expression for what I mean here is
'Vergewohlwurstelung' which is a comprehension of
Vergewaltigung - rape, abuse
Wohltat - beneficence
wursteln - mess with the guts
Anyone know an english equivalent? I guess the concept is widespread
in the Perl community.
: If not a special form, should this work?
:
: my $pi is constant;
: $pi = 3;
That could be made to work by defining constant to mean you can assign
to it if it's undefined. But then it gets a little harder to reason
about it if $pi can later become undefined. I suppose we could
disallow undefine($pi) though.
Yep.
: If yes, should this pass compilation?
:
: my $pi is constant;
: $pi = 3 if (0|1).pick;
: $pi = 4;
If it's a special form, it's a different special form from the assignment
case, and would have to revert to the allow-if-undefined semantics, which
is probably a halting problem for the compiler, and so would have to
defer to runtime to determine legality. But maybe that's a feature.
I dought that it's a halting problem. The (0|1).pick is just typed as
any(true,false) and as such renders the type of $pi after the respective
line as Int|Undef or Int^Undef which are both not applicable to
&infix:{'='}:(Item of Undef is constant, ::T.does(none(Undef) & Item)
--> ::T is constant)
This leads to $pi = 4 to fail at compile time if the set of possible
targets is closed at that time and contains no non-standard target.
Otherwise this check has to be defered to runtime.
I'm not sure what that view does to formal parameters though. Does it
mean that this is legal:
sub foo($a, ?$b) {
$b //= 2;
}
foo(1);
even though $b is not marked "rw" but is implicitly "constant"?
Hmm, isn't the rw marking important to what happens to the callers
value that is bound to the formal parameters? Only an explicit
is constant trait constrains the inside on where the parameter can
be dispatched to.
But maybe this would be illegal:
sub foo($a, ?$b = 42) {
$b //= 2; # compile-time error
}
foo(1);
on the theory that the = of the default construct is the same special
case as the = in
my $b is constant = 42;
Only that ?$b is not marked is constant? Strange that is.
--
$TSa.greeting := "HaloO"; # mind the echo!
