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]

Re: Idea for culling the core of guile to a neater system


Tel <telford@eng.uts.edu.au> writes:

> 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?
> 

Actually, the current gc is pretty removable. As far as I've seen,
code only calls the mark stuff (there may be someone playing behind
it's back breaking things, but I'll reserve that worst case until
after I've made sure that I actually wrote the new gc things correctly
;). I'm currently working on spliting things out (a 2000+ line file
can be a bit unwieldy at times), so it will become something of a
library if I can ever get the bloody thing working. The thing I wonder
at is if taking a general approach wouldn't just be reimplementing
boehm's collector with a guile-centric attitude.

The biggest problem, though, is that it will require rather large bits
of guile to be rewritten. Not that this would be a bad thing, because
there are parts of guile screaming to be cleaned up, but it is quite a
bit of work, with specification (and this is definate ugh work that no
one seems to like doing, myself included) and coordination, as well as
the actual coding, for something that isn't really broken.

-- 
Greg