It might even be more than a decade that I found out about
SCM_NULL_OR_NIL_P and about that "elisp dream" and its completely
useless effects on the Guile source code.
from eval.c
while (!scm_is_null (SCM_CDR (*lloc)))
/* Perhaps should be
SCM_NULL_OR_NIL_P, but not
needed in 99.99% of cases,
and it could seriously hurt
performance. - Neil */
Well, perhaps it was not about performance but NIL is gone
as lang in Guile.
I'm currently pulling out elisp "support" from 1.8
completely. An algorithmic language scheme for me still consists of
an evaluator, a reader, a possibility to display or print values,
some magical being called garbage collector and some other needed
primitives. No virtual machine, no different langs just Scheme plus
what you want to have.
You could say I'm using Guile 1.8 as the extension language that it
was meant to be -
but you could as well turn it around and say I'm using it as the
system interface for my scheme application.
My current goals are:
- remove all traces of elisp completely: it's all over the place
and not useful at all (will be finished today)
- implement SCM implementations for terminal control with ioctl
calls (and perhaps later inotify)
- remove readline support completely - my terminal interface can
already do better
- move functionality to Scheme again: this might even have the
consequence that C routines depend on Scheme implementations
(current implementations of e.g. list processing should be
renamed to opt[imized]-sth
- make the garbage collector controllable from within Scheme
- clean up the reader, clean up macro expansion, support braces and
brackets in terms of code point normalization to make them optional
equivalent alternatives to parenthesis
- clean up, fixes, harmonization of components
Why Guile 1.8? It is easy to extend Scheme, i.e. its system
interface, with SCM. This is the only thing I I have ever done so
far under the hood and my understandings of Guile's core components
is next to imaginary of what they should be.
What about Unicode? While my text editor will eventually support all
of the Unicode Latin sections, my Scheme code will be restricted to
Unicode C which is equivalent to the C locale. This means symbols
might even be restricted to Unicode C0 (7bit ascii) as normalization
issues arise early on: take the accented letter e in Unicode C1: è.
It's still an e and might sometimes even be represented by the to
characters E'. The developer's application itself might know how to
handle these cases but the programming language doesn't need to. And
than I don't see any advantage in having the possibility to define
Scheme symbols in terms of wingdings which is part of the Unicode
standard. Current R6RS implementations allow Scheme symbols (and
thus identifiers) to be mostly arbitrary code points. Greeks could
then use their own alfabet to transcript identifiers. But at the
same time R6RS implementations tend to abuse original greek letters
instead of using their latin transcriptions: they write λ instead
of lambda - where they forget about the capital letter Lambda which
looks like this: Λ. That is not really a problem but I don't need
it.
Please let me know when you're interested in a cleaned up Guile 1.8
and the clean and lean Scheme path.