Re: What's up with %MY?
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
Re: Prototypes
On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote: The third value is a peek value. Do the runtime checking, but don't do any magic variable stuff. As a matter of fact, don't run any user-code at all. Simply return a true or false value if the arguments *would* match. (This allows us to check incoming coderefs, to see that they take the arguments that *they* expect. Similar to the whole pointer to a function that takse a pointer to a function, and an int. Of course, no checking the return value. But they're supposed to handle your want()s.) Er, scratch this. Blows up if the sub isn't prototyped. A much *better* way is to make the prototype of any sub a property (trait) of that sub. We can always query for a property. -- Bryan C. Warnock [EMAIL PROTECTED]
RE: Prototypes
From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote:
The third value is a peek value. Do the runtime
checking, but don't do any magic variable stuff. As a
matter of fact, don't run any user-code at all. Simply
return a true or false value if the arguments *would*
match. (This allows us to check incoming coderefs, to
see that they take the arguments that *they* expect.
Similar to the whole pointer to a function that takse
a pointer to a function, and an int. Of course, no
checking the return value. But they're supposed to
handle your want()s.)
Er, scratch this. Blows up if the sub isn't prototyped. A
much *better* way is to make the prototype of any sub a
property (trait) of that sub. We can always query for a
property.
This is possible now:
$foo = sub ($) { print hello world\n };
print prototype $foo;
RE: Expunge implicit @_ passing
The only good justification I've heard for final is as a directive for optimization. If you declare a variable to be of a final type, then the compiler (JIT, or whatever) can resolve method dispatch at compile-time. If it is not final, then the compiler can make no such assumption because java code can load in extra classes later. This is the only real reason I've seen to allow final. (And it's not a bad reason, honestly, though not necessarily one appropriate in all cases) It does allow a fair amount of optimization to be done, which can be especially important when you can't see all the source. (Pretty much the case in all languages that compile down to object modules you link together later) If our intention is only for optimization, I prefer to use word inline instead of final. The word final already has been abused. It is very awkward to use it for this purpose. Hong
Re: What's up with %MY?
DC == Damian Conway [EMAIL PROTECTED] writes: DC Dan revealed: That's easy--you slip the pumpking or internals designer a 10-spot. Amazing what it'll do... :) DC And how do you think I got five of my modules into the 5.8 core??? i heard it was blackmail. you got a hold of pictures of jarkko's honeymoon. :-) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
RE: What's up with %MY?
From: Ken Fox [mailto:[EMAIL PROTECTED]]
Can we have an example of why you want run-time
symbol table manipulation?
How about being able to dump and restore subroutines and closures along with
their lexical environment?
Perhaps this next example doesn't have to fall under the runtime category,
but I personally would like to be able to use Perl5 attributes to take the
argument from an attribute specification's parameter list and convert it
from q{} into an anonymous subroutine with the same lexical context as the
subroutine implementation of which it is an attribute. Here's a contrived
example:
{
my $year = 2001;
sub year
: Pre($_[0] = $year or die q{can't go back})
{ @_ ? $year = shift : $year }
}
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.
In the example above, any future use of 'die' within the caller's lexical
scope would execute die_hard instead of whatever die used to refer to.
In your example it depends on whether by cloning you mean that each
generated closure has its own symbol table which is a copy of the values
from the original symbol table, or whether it is aliased to refer to the
same underlying values from the original 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?
My preference would be for autovification. That new symbols would be pushed
onto the scratchpad/symbol-table of the target lexical scope. Using another
contrived example in Perl5 syntax, what about:
{
my $foo = sub {'hello'};
sub say {
$foo;
my $a = eval qq{$_[0]};
eval(qq{\$$a})-();
};
}
print say('foo');
What if you'd like to insert an anonymous $bar subroutine into the
scratchpad of say?
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.)
What are the performance problems? Don't Cv's already have their own
scratchpads which could potentially by modified by code using Inline.pm or
XS code at runtime? It's not like we're adding anything new here... are we?
Isn't this just making something that is currently very difficult to do
easier?
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.
Is this really a pragma issue?
I thought part of the Parrot thing was to allow simpler objects and their
associated vtables to be promoted to more complex ones. So we can have bells
and whistles, without having them impact performance until you start making
use of them. And then only affecting the performance of those objects which
are promoted. So write access to a Cv's local scope might done with one of
those scary polymorphic function objects which is less efficent than the
base function object where a function call is 'just a function call'.
RE: Expunge implicit @_ passing
At 09:30 AM 9/4/2001 -0700, Hong Zhang wrote: The only good justification I've heard for final is as a directive for optimization. If you declare a variable to be of a final type, then the compiler (JIT, or whatever) can resolve method dispatch at compile-time. If it is not final, then the compiler can make no such assumption because java code can load in extra classes later. This is the only real reason I've seen to allow final. (And it's not a bad reason, honestly, though not necessarily one appropriate in all cases) It does allow a fair amount of optimization to be done, which can be especially important when you can't see all the source. (Pretty much the case in all languages that compile down to object modules you link together later) If our intention is only for optimization, I prefer to use word inline instead of final. The word final already has been abused. It is very awkward to use it for this purpose. Fair enough. I don't much care what its called, as long as I know what it does. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: What's up with %MY?
At 12:50 PM 9/4/2001 -0500, Garrett Goebel wrote:
sub Bar::import {
my %m = caller(1).{MY}; # or whatever
delete %m{'$x'};
}
hmm... when:
{ my $x = 1; sub incr {$x++} }
is compiled, the $x++ in incr refers to the lexical $x. So deleting it
would remove it from the scratchpad of incr. But I would guess that
future calls to incr would have to autovify $x in the scratchpad and
start incrementing it from 0. I.e., ignoring a package $x if it exists. I
could see people prefering it either way...
Folks might also want that to then refer to the $x in the enclosing scope.
Don't think that's going to happen, though. (Lots and lots of runtime
overhead in that case)
IE what effects to do the standard hash ops of adding, modifying,
deleting, testing for existence, testing for undefness, etc
etc map onto when applied to some sub's %MY, at either compile
or run time.
I would hope that it would be identical to the current behavior we
experience when modifying a package's stash. Or however the new behavior
for stashes maps to Perl6.
I can see allowing read/write/change/iterate access (possibly enforcing
types when writing) but not delete. That opens up a number of cans of worms
I'd rather stay closed for now.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: What's up with %MY?
At 09:20 AM 9/5/2001 +1100, Damian Conway wrote:
The main uses are (surprise):
* introducing lexically scoped subroutines into a caller's scope
I knew there was something bugging me about this.
Allowing lexically scoped subs to spring into existence (and variables, for
that matter) will probably slow down sub and variable access, since we
can't safely resolve at compile time what variable or sub is being
accessed. Take, for example:
my $foo;
my sub bar {print baz\n}
{
bang();
$foo = bar();
print $foo;
}
Now, what I want to do is to have bar() resolve to previous pad, entry 2
and bar to previous pad, entry 1. Which they essentially do now. Those
lookups are snappy, at best we need to walk up the pad pointer chain. No
biggie.
However...
If we can inject lexicals into the caller's scope, bang() could add both a
$foo and a bar() inside the block. That means, for this to work right, I
*can't* resolve to a pad#/offset pair--instead I need to look up by name,
potentially every time. For any sort of speed I'd also need to do some sort
of caching scheme with multi-level snooping and cache invalidation, since
if the variables in question resolve in pad N at compile time, and I use
them at pad 0, I need to potentially check that pads 1-N have had changes
to them. I can see this making closures odd too, if I mess with pads at
runtime. (Odd in the walking down from pad N just got more interesting sense)
Not that I'm arguing against it, just that I can see some efficiency issues.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: What's up with %MY?
Dave Mitchell asked:
If there is to be a %MY, how does its semantics pan out?
That's %MY::. The colons are part of the name.
for example, what (if anything) do the following do:
sub Foo::import {
my %m = caller(1).{MY}; # or whatever
%m{'$x'} = 1;
}
That would be:
sub Foo::import {
my $m = caller(1).{MY};
$m{'$x'} = \1;
}
Symbol table entries store references (to the actualy storage), not values.
My above example would make the lexical $x variable in the caller's scope
equivalent to:
my $x : const = 1;
sub Bar::import {
my %m = caller(1).{MY}; # or whatever
delete %m{'$x'};
}
That would be:
sub Bar::import {
my $m = caller(1).{MY};
delete $m{'$x'};
}
which would cause the next attempted access to the lexical $x in the
caller's scope to throw an exception.
sub f {
my $x = 9;
use Foo; # does $x become 1, or $x redefined, or runtime error, or...?
$x becomes constant, with value 1.
{
# is this the same as 'my $x = 1' at this point,
Yes.
# or is the outer $x modified?
No.
use Foo;
...
}
Because %MY:: is lexical to each scope.
use Bar; # is $x now still in scope?
No.
print $x; #compile error? or runtime error? or prints 9 (or 1...)
Run-time exception.
Bar::import(); # any difference calling it at run time?
No.
IE what effects to do the standard hash ops of adding, modifying,
deleting, testing for existence, testing for undefness, etc etc map onto
when applied to some sub's %MY, at either compile or run time.
No difference between compile- and run-times.
Effects:
What Effect
add entry to %MY:: Creates new lexical in scope
modify entry in %MY::Changes implementation of lexical
delete entry in %MY: Prematurely removes lexical from scope
existence test entry in %MY::Does lexical exist in scope?
definition test entry in %MY:: Is lexical implemented in scope?
Damian
Re: What's up with %MY?
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.
Foxy variables. Nice.
RE: What's up with %MY?
Dan wrote:
At 12:50 PM 9/4/2001 -0500, Garrett Goebel wrote:
So deleting it
would remove it from the scratchpad of incr. But I would guess that
future calls to incr would have to autovify $x in the scratchpad and
start incrementing it from 0. I.e., ignoring a package $x if it exists. I
could see people prefering it either way...
Folks might also want that to then refer to the $x in the enclosing scope.
Don't think that's going to happen, though. (Lots and lots of runtime
overhead in that case)
I agree (both that people might want that, and that it's probably not
going to happen ;-)
I can see allowing read/write/change/iterate access (possibly
enforcing types when writing) but not delete. That opens up a
number of cans of worms I'd rather stay closed for now.
Why not Cdelete? It merely requires that the internals equivalent of:
sub LEXICAL::SCALAR::FETCH ($varname) {
$scalar_ref = caller().{MY}{$varname};
return $$scalar_ref;
}
sub LEXICAL::SCALAR::STORE ($varname, $newval) {
$scalar_ref = caller().{MY}{$varname};
$$scalar_ref = $newval;
}
becomes:
sub LEXICAL::SCALAR::FETCH ($varname) {
$scalar_ref = caller().{MY}{$varname}
or throw lexical $varname no longer in scope;
return $$scalar_ref;
}
sub LEXICAL::SCALAR::STORE ($varname, $newval) {
$scalar_ref = caller().{MY}{$varname}
or throw lexical $varname no longer in scope;
$$scalar_ref = $newval;
}
I don't understand why you think that's particularly wormy?
Damian
Re: Prototypes
Bryan wrote:
Er, scratch this. Blows up if the sub isn't prototyped. A much
*better* way is to make the prototype of any sub a property
(trait) of that sub. We can always query for a property.
This is possible now:
$foo = sub ($) { print hello world\n };
print prototype $foo;
Well, it's nice to know that when I reinvent the wheel, it's still round.
But I strongly agree that the parameter list of a subroutine ought to be
accessed via a trait, rather than a builtin function.
Damian
RE: What's up with %MY?
At 10:04 AM 9/5/2001 +1100, Damian Conway wrote:
Dan wrote:
Why not Cdelete? It merely requires that the internals equivalent of:
[Snippy]
I don't understand why you think that's particularly wormy?
Ah, but what people will want is:
my $x = foo\n;
{
my $x = bar\n;
delete $MY::{'$x'};
print $x;
}
to print foo. That's where things get tricky. Though I suppose we could put
some sort of placeholder with auto-backsearch capabilities. Or something.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: What's up with %MY?
On Tuesday 04 September 2001 07:25 pm, Dan Sugalski wrote:
Ah, but what people will want is:
my $x = foo\n;
{
my $x = bar\n;
delete $MY::{'$x'};
print $x;
}
to print foo. That's where things get tricky. Though I suppose we could
put some sort of placeholder with auto-backsearch capabilities. Or
something.
Other than the obvious run-time requirements of this, what's wrong with
simply looking in the current pad, seeing it's not there, then looking in
the previous pad...? (Assuming you know the variable by name)
--
Bryan C. Warnock
[EMAIL PROTECTED]
RE: What's up with %MY?
Dan sighed:
I don't understand why you think that's particularly wormy?
Ah, but what people will want is:
my $x = foo\n;
{
my $x = bar\n;
delete $MY::{'$x'};
print $x;
}
to print foo. That's where things get tricky. Though I suppose we
could put some sort of placeholder with auto-backsearch
capabilities. Or something.
Exactly.
Damian
Re: What's up with %MY?
At 10:34 AM 9/5/2001 +1100, Damian Conway wrote: Dan wept: I knew there was something bugging me about this. Allowing lexically scoped subs to spring into existence (and variables, for that matter) will probably slow down sub and variable access, since we can't safely resolve at compile time what variable or sub is being accessed. [snippage] Not that I'm arguing against it, just that I can see some efficiency issues. Understood. And that's why you get the big bucks. ;-) I'm getting paid? Keen! :-P Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What's up with %MY?
At 07:24 PM 9/4/2001 -0400, Bryan C. Warnock wrote:
On Tuesday 04 September 2001 07:25 pm, Dan Sugalski wrote:
Ah, but what people will want is:
my $x = foo\n;
{
my $x = bar\n;
delete $MY::{'$x'};
print $x;
}
to print foo. That's where things get tricky. Though I suppose we could
put some sort of placeholder with auto-backsearch capabilities. Or
something.
Other than the obvious run-time requirements of this, what's wrong with
simply looking in the current pad, seeing it's not there, then looking in
the previous pad...? (Assuming you know the variable by name)
Absolutely nothing. The issue is speed. Looking back by name is, well,
slow. The speed advantage that lexicals have is that we know both what pad
a variable lives in and what offset in the pad it's living at. We don't
have to do any runtime lookup--it's all compile time. If we lose that
compile-time resolution, things get a lot slower. (Runtime lexical name
lookup is a lot slower than runtime global lookup because we potentially
have a lot of pads to walk up)
Certainly doable. Just potentially slow, which is what I'm worried about.
Making it not slow has both potential significant complexity and memory
usage. If we have to, that's fine. Just want to make sure the cost is known
before the decision's made. :)
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: LangSpec: Statements and Blocks
Bryan asked:
That would be:
given ( $a ) {
when /a/ : { foo($a); goto BAR }
when /b/ : { ... }
BAR: when /c/ : { ... }
...
}
If they were statements, wouldn't that be:
when /a/ : { foo($a); goto BAR };
when /b/ : { ... };
BAR: when /c/ : { ... };
...
That's why I was considering them blocks, which I, of course, mislabelled
clauses. Like if blocks and while blocks.
A Cwhen is a statement, just as an Cif or a Cwhile is a statement.
Using Cnext BAR would (presumably) cause control to head up-scope
to the first *enclosing* block labelled 'BAR'.
But wasn't a bare 'next' supposed to continue on to the next statement?
Yes.
given ( expr ) {
when /a/ : { foo; next }
when /b/ : { bar }
}
If /a/ is true, do foo(), and then continue on to the next statement.
Yes.
If that was/is still the case, then wouldn't a 'next LABEL' imply
continuing on to the next statement labelled LABEL?
I guess that would be consistent too. H.
Of course, if it is no longer 'next', then that's fine, too.
No. As far as I know, it's still Cnext. That's just an extension of
the Cwhen...next semantics I hadn't considered. Thanks.
Damian
Re: LangSpec: Statements and Blocks
On Tuesday 04 September 2001 09:09 pm, Damian Conway wrote: A Cwhen is a statement, just as an Cif or a Cwhile is a statement. Okay, then I simply need to rethink/redefine how I'm defining a statement, (which is currently in terms of the statement separator). -- Bryan C. Warnock [EMAIL PROTECTED]
Re: What's up with %MY?
At 12:00 PM 9/5/2001 +1100, Damian Conway wrote: Dan concluded: Certainly doable. Just potentially slow, which is what I'm worried about. Making it not slow has both potential significant complexity and memory usage. If we have to, that's fine. Just want to make sure the cost is known before the decision's made. :) I rather liked the delete-means-install-a-pad-walking-placeholder notion. That way things only get slow if you actuallt do something evil. Insert needs one too. Or, rather, there needs to be one there already, and we may need to walk back pad by pad if a pad's changed. I think we're going to have to go with a doubly-linked tree structure for pads with some sort of runtime invalidation of fake entries when the pad itself is messed with. Have to think on that one a bit. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What's up with %MY?
Damian wrote: Dan wept: I knew there was something bugging me about this. Allowing lexically scoped subs to spring into existence (and variables, for that matter) will probably slow down sub and variable access, since we can't safely resolve at compile time what variable or sub is being accessed. Understood. And that's why you get the big bucks. ;-) Efficiency is a real issue! I've got 30,000 lines of *.pm in my latest application -- another 40,000 come from CPAN. The lines of code run a good deal less, but it's still a pretty big chunk of Perl. The thought of my app suddenly running slower (possibly *much* slower after seeing the semantics of Perl 6 lexicals) doesn't make me real happy. IMHO it would fork the language, even if the fork was only done with pragmas. - Ken
Re: What's up with %MY?
At 10:23 PM 9/4/2001 -0400, Ken Fox wrote: Efficiency is a real issue! I've got 30,000 lines of *.pm in my latest application -- another 40,000 come from CPAN. The lines of code run a good deal less, but it's still a pretty big chunk of Perl. The thought of my app suddenly running slower (possibly *much* slower after seeing the semantics of Perl 6 lexicals) doesn't make me real happy. IMHO it would fork the language, even if the fork was only done with pragmas. I still have the perl 6 must run faster than perl 5 mandate. Things *will* be faster. Somehow. We may have to do Weird Magic (or I have to convince Larry that demonstrated performance won't get any better) but I think we can get there. I think we're going to have to sacrifice some memory for it, though. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What's up with %MY?
On Tuesday 04 September 2001 10:10 pm, Dan Sugalski wrote: At 08:59 PM 9/4/2001 -0400, Bryan C. Warnock wrote: Yes, this is akin to redeclaring every lexical variable every time you introduce a new scope. Not pretty, I know. But if you want run-time semantics with compile-time resolution That is exactly what it is, alas. If we allow lexicals to get injected in, we need to either do this (Basically having every non-package variable getting an entry in the scope's pad) or search backward. I don't much like either option, but I think this is the best of the lot. So much for the Extra braces don't carry any runtime penalty to speak of speech in class... :) Well, they still wouldn't. Mostly. All the pads could *still* be set up at compile time. All lexicals within a scope would be grouped together, which might (doubtful) help reduce paging. If pads were still arrays, the original construction would consist of memcopys - about as cheap of duplication that you'll get. And the performance hits would be taken only by a) the unqualified globals, and b) the actual twiddling of the lexical variables (both in lookup, and in manipulation). If you're going to take hits, that's where to take them. Of course, then you've got the bloat to worry about. Which might make your decision to go ahead and be slow an easy one But why are we on the language list for this? Back to internals we go.. -- Bryan C. Warnock [EMAIL PROTECTED]
