This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: emacs with guile instead of elisp



thomas.fischbacher@physik.uni-muenchen.de writes:
> 
> On Wed, 8 Jul 1998, Maciej Stachowiak wrote:
> 
> > There are only 256 possible smob types? That seems like a limit that
> > might actually get run into in practice, especially if you use a lot
> > of complex extensions together in one program.
> 
> Think you are right. One "quick fix" might be to use one more level of 
> indirection (smob CDR = pointer to C structure consisting of a data pointer 
> and a 'method array pointer'. Smob methods do some additional bookkeeping 
> (i.e. freeing this two-pointer structure, etc.) and call the 'indirect 
> methods'. Yes, it's a kludge, but it would work.

I was thinking of something much simpler, which is to use those extra
16 bits in the type code that are used for an optional length or other
user data. I'd imagine most smobs don't use this region at all, or use
fewer than 16 bits. However there might be a few that do. It may be
worthwhile to partition the smob space into two or more regions
depending on how many bits of the type code are left free for the
user, and allow the user to request some minimum number of free type
code bits when registering a new smob. The simplest case would be to
leave the first 255 smob codes as is, and use the 256th as an escape
for smobs that use 16 extra bits of type code, allowing a total of
65791 smobs, only 255 of which have the 16 free bits in the type code.

> BTW: are there any means 
> of finalization remotely similar to Allegro CL's or CMU CL's?
> 

You'd probably want to do you finalization in the free function.

 - Maciej Stachowiak