help-zile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stephan Titard
Subject: Re: [zile-devel] Woot, we may soon be obsolete!
Date: Thu, 13 Jul 2006 09:35:01 +0200
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]