Suggestions for smob usages in an extended smob space

[Dirk Herrmann <dirk@ida.ing.tu-bs.de>]

Hello!

Currently guile provides 8 bits for smob tags. This is to be extended some
day (it's on Jim's task list). On the other hand, guile uses a complicated
tag system to encode it's built-in types (see the thread regarding
uniform vectors).

Part of the complexity is that for certain types additional flags
are encoded within the type tags. This techniques reduces the need for
extra data structures and can reduce consing.

However, as soon as an enlarged smob space is available, such 'tricks' can
be done without need for a complicated tag system:

long scm_newsmob (scm_smobfuns *funs);

This is the function which is currently available: It adds a single type
to the system and returns the tag used for it. Instead (or in addition) a
function could be provided that adds (expt 2 n) types to the system: 

long scm_newsmobs (scm_smobfuns *funs, unsigned int n);

The idea is that a range of smob tags is reserved in a way that allows
easy extraction of the n bits from the smob tag. This can always be
achieved by leaving some smob numbers unallocated. To clarify the idea,
look at the following example:

long a, b, c, d;
a = scm_newsmob(a_funs);      // assume smob tag #5 is returned. The whole
                              // tag is used to indicate the smob type.
b = scm_newsmobs(b_funs, 3);  // returns smob tag #8: All but the lowest 3
                              // bits indicate the smob type. The lowest 3
                              // bits can be used by the application to
                              // encode additional flags. I.e. this type
                              // uses smob tags #8 - #15.
c = scm_newsmob(c_funs);      // returns smob tag #16
d = scm_newsmobs(d_funs, 1);  // returns smob tag #18 (18 and 19 are used)

In practice it is not that simple, since the smob bits are probably not
the lower bits of the tag. Thus, to extract the bits, additional masking
and shifting is necessary. Nevertheless, for the disadvantage of leaving
some smob slots unused, flags can easily be encoded within the smob type.
(The disadvantage could also be avoided by offering a mechanism that
allows to use those skipped smob types).

This offers great flexibility compared to the current type system and
allows to provide additional types with effective encondings without
interfering with other types.

Looking at the example of uniform vectors, there may be a little
performance overhead: Currently, uniform vectors have fixed, constant type
tags. If a solution like the one sketched above was used, the type tags
for a set of types was computed during run-time. Thus, the tag value would
have to be stored in a variable and some compiler optimizations would not
be possible.

Best regards, 
Dirk Herrmann