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] |
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.