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]

Idea for culling the core of guile to a neater system


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