Re: emacs with guile instead of elisp

[Mikael Djurfeldt <mdj@nada.kth.se>]

Miroslav Silovic <silovic@zesoi.fer.hr> writes:

> Mikael Djurfeldt <mdj@nada.kth.se> writes:
> 
> > Requirement: Guile must know how to read ELisp.
> 
> There also needs to be a way to save Guile parse trees in a way that's
> faster to download. The ammount of LISP code that has to be loaded
> into Emacs is much larger than the current Guile applications.

Yes.

But Guile loading of source code is currently exceptionally slow (due
to the module system I use to claim) and needs to be improved anyway.

I think that Guile loading will be acceptable when we have a new
module system (with symbol lookup written in C).  (Note that loading
of stable software should be made with the positions read option
turned off.)

Regarding saving of Guile parse trees:

I've been thinking that if Guile is used as a scripting language in
many applications, then it is a pity that only the C part can be
reused (through the use of shared libraries).  I'd like the Scheme
part to be shared as well.

How could we accomplish that?

One answer is: compile Scheme code into a shared library.

I've also been speculating about another alternative:

What about maintaining a common heap store which can be memory mapped
read-only into a fixed address space of the process?

Let's say that process A requests library (P M).  A first checks in an
index if library (P M) is in the store.  If it isn't, library (P M) is
loaded into the store, starting at next free cell.  This automatically
results in that (P M) is loaded into A's memory space since the store
is memory mapped into A.  Since the store itself is a file it can
"live" between sessions in a natural way.

The loading into the store is a tricky thing because it is important
that only cells which should look the same globally are loaded into
the common part of the store.  Probably one should first load it into
some Guile process normally and then let an intelligent
garbage-collector-like program copy-and-modify it into the store.

This idea could be tricky to realize but it might not be as
fundamentally non-robust as one would expect since any attempt to
modify store heap cells will lead to a memory exception and a normal
error message.

Well, well, wild ideas...

/mdj