Guile 1.8 / Viper System Interface

[Michael Tiedtke]

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.