Re: GRM questions

[Dirk Herrmann]

On 30 May 2001, Marius Vollmer wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > >   The examples and description use the notion of CDR for the data slot
> > >   of smobs.  Shouldn't that be changed to
> > >   SCM_CELL_WORD/SCM_CELL_OBJECT?  [...]
> > 
> > Yes, please.
> 
> Wouldn't that be SCM_SMOB_DATA?

Good question.  Yes, it could be used.  However, SCM_SMOB_DATA was
introduced at a time when there were no double cells.  Today we have the
situation that a lot of types use double cells, which means that there is
not _the_ smob data entry.  The intention of SCM_SMOB_DATA is to somehow
hide the implementation detail that the smob data is stored in cell#1, but
actually that detail is not really hidden if for cell#2 or cell#3 you
still have to use SCM_CELL_WORD/SCM_CELL_OBJECT.  Further, smobs may also
store data in cell#0, because only 16 bits are used to identify the smob
type.  Another point with SCM_SMOB_DATA is, that you can not distinguish
between extracting the data as scm_bits or SCM, which means you will have
to use packing/unpacking to access the data.  BTW, the packing/unpacking
problem also applies to the smob-creation macros.

I see two possible solutions to this:

* We could introduce macros SCM_SMOB_DATA_[0-3], maybe even
  SCM_SMOB_[WORD|OBJECT]_data_[0-4], with SCM_SMOB_OBJECT_DATA_0 being an
  illegal combination.

* We eliminate the macro SCM_SMOB_DATA.  This is also a valid
  possibility, for the following reason:  Formerly, calls to SCM_CDR and
  SCM_SMOB_DATA were spread all over guile.  Guile now uses much more
  consistently the pattern to provide setter and getter macros for the
  different types (like for example, SCM_[SET]_HOOK_PROCEDURES.  Thus, the
  need to use SCM_[SET_]?CELL_[WORD|OBJECT]_[0-4] would mostly be 
  restricted to the definitions of these macros.
  When we choose this option, however, it would be nice if guile's type
  system and the integration of smobs into this system would be
  documented.  The documentation has already made a big step into this
  direction.

Best regards,
Dirk Herrmann