RE: global environment special case

[Paul Bleisch <pbleisch@...>]

A "next" fallback would be great as it would all one to
support generic container objects that are actually C/C++
objects.  i.e. COM enumerators.

Paul


> -----Original Message-----
> From: David Jeske [mailto:jeske@chat.net]
> Sent: Thursday, April 20, 2000 12:04 PM
> To: Multiple recipients of list
> Subject: Re: global environment special case
> 
> 
> 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
>