Ken wrote:
> 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?
Err. No thanks. Being able to mess with the symbol table is one
of the things I most like about Perl.
> Can we have an example of why you want run-time
> symbol table manipulation? Aliases are interesting,
...but not what I had in mind.
The main uses are (surprise):
* introducing lexically scoped subroutines into a caller's scope
* introducing lexically scoped variables into a caller's scope
In other words, everything that Exporter does, only with lexical
referents not package referents. This in turn gives us the ability to
easily write proper lexically-scoped modules.
Other important uses are:
* modifying existing lexically scoped subroutines in a caller's scope
* modifying existing lexically scoped variables in a caller's scope
I can image a Lexically::Verbose module, that modifies all variables and/or
subroutines in a scope to report their own activity:
while (whatever) {
use Lexically::Verbose 'vars';
my $x; # logs: 'created $x at line 4''
$x++; # logs: 'incremented $x to 1 at line 5'
}
> > > 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?
Right. Lexical symbol tables are themselves lexical variables. At the
end of the caller's scope, they vanish.
> 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.
Yep.
> 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?
No. Because some other subroutine called from the caller's scope might
also access caller().{MY}. In fact, you just invented a new pattern, in
which a set of subroutines called within a scope can communicate invisibly
but safely through that scope's lexical symbol table.
> > 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
Not necessarily with Inline. Nor with source filters for that matter (the
C<use> could be 500 lines and 10 nested scopes away at the top of the file)
> 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 would have said that was Perl's signature feature. ;-)
> We also want Perl 6 to be fast and cleanly implemented.
Accessing lexicals will be no slower than accessing package variables
is today. Because in Perl 6 both lexicals and package variables will
use the same look-up mechanism: look up the appropriate symbol table
entry and that's your SV reference (or whatever replaces SVs in Perl 6).
Think of symbol table entries as vtables for variables.
> > 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.
Thank-you. But I have to contend with the inflation of expectations.
Last year I wow'd them with simple quantum physics. This year, I needed
a quantum cellular automaton simulation of molecular thermodynamics
written in Klingon. What will it take next year???
;-)
> 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.
A great deal of that happens off-list: especially between Dan and I and
between Dan and Larry.
> 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.
I'm really not worried about that. Larry has consistently demonstrated
he's open to reassessing his design decisions when necessary.
Damian
