>i think the point is that we're already dealing w/ a library. the
>question is how efficient is its partitioning. (i must admit, it's not
>a question that i think deserves too much manual study; i guess i would
>appreciate pointers to source-code analysis systems, preferably free.)
It seems to be traditional (some excuse!) for lisp systems to be
incestuous. i.e. you ask for one little exception-handling function,
which brings in the formatter, which brings in the complex number
support, and the I/O port implementations, ... Scheme 48 seems to
have paid a lot of attention to clean partitioning (e.g. the papers
claim you can bring in only the numeric types you need, and everything
will just work), but Guile hasn't.
You'd have to separate read.c from the allocator.
You'd have to separate read.c from all the datatypes you don't care
about reading (uniform vectors, multibyte strings, etc).