From @masak

<masak> there is at least a little code smell inherent in p6 dynamic
variables, since these are not namespaced at all. it'd be nice to see
a solution for namespacing dynamic variables.
<TimToady> dynamic var is a lexical, not a global
<TimToady> masak​: I don't think dynamic variables are useful enough to
warrant the baggage of namespacing
<TimToady> dynamic hashes and common prefixes are probably good enough
<masak> TimToady​: maybe.
<masak> TimToady​: but I'd be wary every time I used both dynamicals
and callbacks.
<TimToady> esp if we allow :​: in a dynamic name :)
<masak> :D
<masak> then I'm fine :)
<TimToady> we can think about that
<TimToady> might also be useful to target the final default to a
package other than GLOBAL
<TimToady> which makes it slightly less smelly, I suspect
<TimToady> std​: my $*FOO​::BAR = 2;
<p6eval> std 625303c​: OUTPUT«ok 00​:01 121m␤»
<TimToady> heh
<masak> rakudo​: my $*FOO​::BAR = 42; say $*FOO​::BAR
<p6eval> rakudo 723986​: OUTPUT«Cannot modify readonly value␤ in
'&infix​:<=>' at line 1␤ in main program body at line
22​:/tmp/2PoIAPndlk␤»
* masak submits rakudobug
<TimToady> not clear that STD parsed it correctly though
<masak> should it error out on FOO​:: not being predeclared?
<TimToady> there's definitely something wonky in the STD parse of that
<TimToady> nevertheless it can probably be made to work someday
<masak> TimToady​: well, Rakudo parsed it too, since it got to runtime.
<TimToady> package globals don't generally care about whether FOO​::
exists yet for normal variables
<masak> ok.
<TimToady> std​: $FOO​::bar = 42;
<p6eval> std 625303c​: OUTPUT«ok 00​:01 120m␤»
<masak> rakudo​: module Foo {}; my $*Foo​::bar = 42; say $*Foo​::bar [18​:06]
<p6eval> rakudo 723986​: OUTPUT«Cannot modify readonly value␤ [...]

From @jnthn

On Tue Jan 25 09​:08​:20 2011, masak wrote​:

<masak> there is at least a little code smell inherent in p6 dynamic
variables, since these are not namespaced at all. it'd be nice to see
a solution for namespacing dynamic variables.
<TimToady> dynamic var is a lexical, not a global
<TimToady> masak​: I don't think dynamic variables are useful enough to
warrant the baggage of namespacing
<TimToady> dynamic hashes and common prefixes are probably good enough
<masak> TimToady​: maybe.
<masak> TimToady​: but I'd be wary every time I used both dynamicals
and callbacks.
<TimToady> esp if we allow :​: in a dynamic name :)
<masak> :D
<masak> then I'm fine :)
<TimToady> we can think about that
<TimToady> might also be useful to target the final default to a
package other than GLOBAL
<TimToady> which makes it slightly less smelly, I suspect
<TimToady> std​: my $*FOO​::BAR = 2;
<p6eval> std 625303c​: OUTPUT«ok 00​:01 121m␤»
<TimToady> heh
<masak> rakudo​: my $*FOO​::BAR = 42; say $*FOO​::BAR
<p6eval> rakudo 723986​: OUTPUT«Cannot modify readonly value␤ in
'&infix​:<=>' at line 1␤ in main program body at line
22​:/tmp/2PoIAPndlk␤»
* masak submits rakudobug
<TimToady> not clear that STD parsed it correctly though
<masak> should it error out on FOO​:: not being predeclared?
<TimToady> there's definitely something wonky in the STD parse of that
<TimToady> nevertheless it can probably be made to work someday
<masak> TimToady​: well, Rakudo parsed it too, since it got to runtime.
<TimToady> package globals don't generally care about whether FOO​::
exists yet for normal variables
<masak> ok.
<TimToady> std​: $FOO​::bar = 42;
<p6eval> std 625303c​: OUTPUT«ok 00​:01 120m␤»
<masak> rakudo​: module Foo {}; my $*Foo​::bar = 42; say $*Foo​::bar [18​:06]
<p6eval> rakudo 723986​: OUTPUT«Cannot modify readonly value␤ [...]

More recent feeling is that we don't want this feature​:

http://irclog.perlgeek.de/perl6/2015-10-15#i_11381191

So I've made the compiler reject such things with an error​:

$ perl6-m -e "my $*FOO​::BAR"
===SORRY!=== Error while compiling -e
Dynamic variables cannot have package-like names, like $*FOO​::BAR
at -e​:1
------> my $*FOO​::BAR<HERE><EOL>

Tests are in S02-names-vars/contextual.t. In the event we do decide we want this syntax for something in the future, rejecting it outright now while we're not sure nicely reserves it for then.

/jnthn

The RT System itself - Status changed from 'new' to 'open'

@jnthn - Status changed from 'open' to 'resolved'