Damian Conway wrote:
> It would seem *very* odd to allow every symbol table *except*
> %MY:: to be accessed at run-time.
Well, yeah, that's true. How about we make it really
simple and don't allow any modifications at run-time to
any symbol table?
Somehow I get the feeling that "*very* odd" can't be
fixed by making the system more normal. ;)
> > Is stuff like:
> >
> > %MY::{'$lexical_var'} = \$other_var;
> >
> > supposed to be a compile-time or run-time feature?
>
> Run-time.
A definition of run-time would help too since we have
things like BEGIN blocks. I consider it run-time if the
compiler has already built a symbol table and finished
compiling code for a given scope. Is that an acceptable
definition of run-time? This allows BEGIN blocks to
modify their caller's symbol tables even if we prohibit
changes at run-time.
Can we have an example of why you want run-time
symbol table manipulation? Aliases are interesting,
but symbol table aliases don't seem very friendly.
It would be simple to write:
%MY::{'@point'} = [ $x, $y ];
But that probably won't work and using [ \$x, \$y ]
doesn't make sense either. What seems necessary is:
%MY::{'$x'} = \$point[0];
%MY::{'$y'} = \$point[1];
If the alias gets more complicated, I'm not sure the
symbol table approach works well at all.
> > Modifying the caller's environment:
> >
> > $lexscope = caller().{MY};
> > $lexscope{'&die'} = &die_hard;
This only modifies the caller's scope? It doesn't modify
all instances of the caller's scope, right? For example,
if I have an counter generator, and one of the generated
closures somehow has its' symbol table modified, only that
*one* closure is affected even though all the closures
were cloned from the same symbol table.
What about if the symbol doesn't exist in the caller's scope
and the caller is not in the process of being compiled? Can
the new symbol be ignored since there obviously isn't any
code in the caller's scope referring to a lexical with that
name?
> Between source filters and Inline I can do pretty much whatever I like
> to your lexicals without your knowledge. ;-)
Those seem more obvious. There will be a "use" declaration
I wrote and I already know that "use" can have side-effects on
my current name space. IMHO this could become a significant problem
as we continue to make Perl more expressive. Macros, filters,
self-modifying code, mini-languages ... they all make expressing
a solution easier, and auditing code harder. Do we favor
expression too much over verification? I'm not qualified to
answer because I know I'm biased towards expression. (The %MY
issues I'm raising mostly because of performance potential.)
> I would envisage that mucking about with symbol tables would be no more
> common in Perl 6 than it is in Perl 5. But I certainly wouldn't want to
> restrict the ability to do so.
We also want Perl 6 to be fast and cleanly implemented.
This particular issue is causing trouble because it has a big
impact on local variable analysis -- which then causes problems
with optimization. I'd hate to see lots of pragmas for turning
features on/off because it seems like we'll end up with a more
fragmented language that way.
> How am I expected to produce fresh wonders if you won't let me warp the
> (new) laws of the Perl universe to my needs?
You constantly amaze me and everyone else. That's never
been a problem.
One of the things that I haven't been seeing is the exchange
of ideas between the implementation side and the language side.
I've been away for a while, so maybe it's just me.
It vaguely worries me though that we'll be so far down the
language side when implementation troubles arise that it will
be hard to change the language. Are we going to end up with
hacks in the language because certain Very Cool And Important
Features turned out too hard to implement?
- Ken
