Guile 1.8 / Viper System Interface

[Michael Tiedtke <michele.titke@o2online.de>]

[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 4254 bytes --]