Re: [zile-devel] Woot, we may soon be obsolete!

[Stephan Titard]

Reuben Thomas escribió:
> On Wed, 12 Jul 2006, Stephan Titard wrote:
>
>   
> > > The current Lisp implementation in Zile is actually a hacked-down small
> > > lisp interpreter (lithp 0.6).
> > >       
> > Ah. Thanks. I could  not find any pointer to that in the docs...
> >     
>
> No, I was trying not to advertise it. I did think originally that a 
> proper Lisp was a good idea, but then changed my mind and eviscerated 
> it. I kept just enough so that the .zile file could have Lisp-ish 
> syntax.
>
> One thought: no need to use tinyscheme, as "small" in the context of a 
> "big" zile includes "using stuff that's already on the system",
quite right.
>  so it 
> could use rep (librep: "It was originally written to be 
> mostly-compatible with Emacs Lisp, but has subsequently diverged 
> markedly.") or guile. guile is politically a better bet as only sawfish 
> depends on librep, whereas lots of things use guile, and if rep has now 
> "diverged markedly" from elisp, it may not make sense to use it for 
> similarity value (though at least it IS Lisp rather than Scheme).
>   
Guile is a dialect of scheme. There are various reasons why the fsf 
people started a plan (many years ago already) to migrate
e-lisp code to scheme, the main one being threads I think, another one 
being the obvious advantage of
having the vm tuned and expanded by specialized people.
Scheme has also been "revived" by various implementations that use the 
java vm (and let you hook *all*
of its libraries); I play with SISC. The kawa project is interesting 
also, as a sub-project is *emacs in java* and offers
already a partial implementation of elisp: this  is particularly 
interesting as it means  probably that a decent  translator
elisp-scheme is not far away. 
http://community.schemewiki.org/?scheme-faq-standards#implementations 
has all the links...

>   
> > I thought actually it was __POSIX__ Code; obviously there are some 
> > poorly-conforming curses as it does not compile on HP-UX. As I 
> > commented, it is probable that having ncurses as a prerequisite would 
> > solve the problem. I will definitely send patches if I make it work.
> >     
>
> OK. Certainly at the moment I develop against ncurses, and I don't have 
> a non-extended implementation to try. ncurses itself doesn't provide 
> compatibility headers, I think, as it's basically a superset of curses, 
> so they'd only be useful for developers trying to write code that works 
> on POSIX-only curses.
>
>