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]

structs, records, SMOBs etc.



OK.  I'm attempting to sort out in my own head the
various means of defining new data types in Guile,
and here are my conclusions so far.

I) SMOBs.

  pro:
    Available at the C level;
    Pretty nice and logical interface;
    Fast dispatch (?).
  con:
    Not available at the Scheme level;
    There can be only a finite number of SMOB types (though
    potentially a very large number);
    The biggie (IMHO): the SMOB type tag has to be dynamically
    "allocated".

II) Records.

  pro:
    Available at the Scheme level;
    Nice and logical interface;
    Familiar (to many);
    Unlimited (eq?-tagged by types);
    "Static".
  con:
    Not available at the C level;
    No provision for user-supplied GC hooks and raw binary data
    chunks.

III) Structs.

  pro:
    Available at both levels;
    Unlimited;
    "Static".
  con:
    What can I say?  *ouch*
    Structs seem to be a low level type-definition mechanism
    which has decided in mid-way to become an object system.
    With a MOP.  With protected fields.  Etc.

IV) Conclusions.

  SMOBs.
    great for use in the Guile core, because of the fast dispatch.
    Lots of things are implemented using them.  Their "dynamic"
    nature is IMHO a problem for user extensions, though, as it
    doesn't play well with heap freezing.
  Records.
    I think, this is (potentially) the best of the three.  To make
    it so, records need to be implemented in the Guile core, and
    the C interface to them needs to allow user GC hooks and binary
    data.  Another win of this would be a unified type-definition
    mechanism for both C and Scheme levels.
  Structs.
    With records implemented as above, would we really need structs?

mike.