HaloO,
Autrijus Tang wrote:
All this led us to think about whether (my &foo) can be merely treated
the same as (my Code $foo). The mutable form will enable convenient
notations such as:
I think (my Code $foo) should be an error on the same reason as
(my Array $foo) is an error. A $var can only contain explicit
Ref types like (my Ref of Array $foo) or (my Ref of Code $foo).
But the following should be allowed
my &pi = 3.14;
if $num == pi {...}
&foo = sub { ... };
So instead of having to explain to newcomers that you cannot assign
to a &-sigil symbol, it would all just work. Under this view, &{$x}
would be eliminated with *{}.
I think *{1,2,3} is valid syntax which means listify the code literal.
But it's no special form. In particular * {1,2,3} is the same because
* is a normal prefix op.
Another idea is to treat (my &foo) the same way (my Code $foo is constant).
That will discourage people into assigning into functions, and enable
the compiler to detect function variables at lvalue position as errors,
but on the whole I don't think it's worth the complexity.
Does this make sense?
Yes. I think of the (fantastic) four sigils as referential expressions
that are somehow bound to 'real' data. When and how that binding takes
place is another matter. But in particular I like my idea that the
corresponding dot twigils are firstly applicable only in methods and
are secondly then bound through the invocant. E.g. &.action calls the
action slot of the current invocant---method level block owner aka
$?SELF. This is basically the vtbl dispatch. Note that &. slots are
auto-generated accessor "methods" if not explicitly given by the class
implementor. A method special form is *not* a slot method by a 'free'
method specialized on the surrounding class.
PS: could someone give a summary which sigil forms are still in effect.
E.g. ${}, $(), etc.
--
$TSa.greeting := "HaloO"; # mind the echo!
