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] |
I sympathize with the desire for a consistent syntax. I'd suggest writing something afresh that parses a subset of Guile's read syntax. >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).