Re: global environment special case

[David Jeske <jeske@...>]

Even if it's not possible to change the implementation of the
globals-table to match other tables, it would be nice if it would
"look like" other tables for operations.

Off the top of my head, I think the changes required would be 

(a) a way to "get" the global table reference, such as the
"getglobaltable()" function which has been mentioned, or perhaps some
special symbol in the language.

(b) an implementation of "next" as a fallback method so that walking
the global table could be made to look like walking any other table
through the fallbacks, even though it's implementation was different.

Which sounds like a generally "good idea" (tm) to me. However, a few
days ago when I started thinking about the "next" fallback idea, it
seemed pretty non-trivial to make work fast.

On Thu, Apr 20, 2000 at 11:15:31AM -0300, Roberto Ierusalimschy wrote:
> > Can you explain how much this experiment tells us?  You've added
> > bytecodes, etc., so I'm not surprised it's slower. [...]
> 
> This is only a back of the envelope estimation. The original loop has 10 
> opcodes, the new one has 13, so are not the opcodes that make the 
> difference of more than 50% in run time. Also, my "global" table in the 
> experiment has only one element; a real one would have some hundreds (at 
> least 100 from predefined and library functions). (We need an average of 1.5 
> probes to access such table). 
> 
> Of course there are many ways to improve its efficiency (implicit access to 
> the global table in the opcode, special access method for strings, etc), 
> but we will loose some performance at the end. As I said, we will
> try a real implementation to get a better estimate.
> 
> (Another advantage of using a table for globals: you can change the whole
> global environment with a simple assignment.)
> 
> -- Roberto
> 

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net