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] |
This is a bit fanciful but it occurs to me that the guile core could be neatly divided in this way. A lot of the SCM stuff is related to dynamic storage, lists and garbage collection. In many ways, such storage could quite conceivably make a useful library in itself. This would consist of the ability to translate basic types of SCM data to C native types, the ability to check the type of SCM data, making cons cells and thus lists and garbage collection. Also only the framework for SMOB support should be in this library so that you can make SMOBs, check to see if data is an SMOB but the library defines no SMOBs at all. I suggest that strings and vectors should be included at this level since they are pretty generic but not symbols which are special to scheme. None of this requires the evaluator, any file handling or parsing or really any scheme specific routines at all. Such a library could be billed as a general purpose storage and garbage collection library and could be given quite a neat API. The next level up would use the storage library to define a hash-table SMOB which would allow symbols to be defined, and port SMOBs to allow read and write of scheme expressions to files, then go on and include the guts of the evaluator and numerical libraries. This is where all of the really scheme specific stuff would reside. The rationale for this is that the storage library isolates most of the irritating issues behind an API and it also separates things like data tagging from scheme evaluation (which to my mind aren't logically related). Also, more than one storage library might be written with the same API so that the scheme evaluation library could ride on either depending on what was required. A split of this nature would surely simplify future maintenance of both the garbage collector and the evaluator. Worth considering? - Tel