Re: Where do you want to go tomorrow?

Stephen> But (from this third party's point of view) neither of you has really Stephen> explained what the advantages are to your preferred dialect. My case for Scheme has been at http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-gener... for a while. It's fairly rudimentary, but I'll be happy to elaborate on anything anyone wants. The highlights (in a comparison to CL) are: 1. Scheme is a small language, both conceptually and in implementation. It carries little historical baggage. 2. Many complete implementations of Scheme exist, and several would make suitable substrates for XEmacs. Some of the best-performing compilers for higher-order languages exist for Scheme. 3. Scheme is built in such a way so as to be able to model most other concepts existing in other programming languages. In particular, it supports high-level macros, control abstraction, and reflection. Stephen> One thing that we have banged up against a couple of times Stephen> recently is the "global option-variable vs. function Stephen> argument" thing. This is especially annoying in the Mule Stephen> modules, since the FSF implementation keeps changing and it's Stephen> useful to keep synch in many cases. It would be nice to have Stephen> CL-like keyword arguments. Is this doable in a robust way in Stephen> Scheme? Would it be efficient, especially when compiled? Sure. In fact, the DSSSL subset of Scheme specifies keyword arguments, and several Scheme implementations already have them. No problem there. (Of course, it's equally possible to add them to the language with a bunch of macros.) However, Scheme idiomatics usually uses a parameterization mechanism to achieve what you're talking about; they're similar to a structured and thread-compatible version of dynamic binding. Stephen> If Hrvoje is correct that much elisp code can be swallowed raw by a CL Stephen> implementation, then this should make synching with the FSF much less Stephen> painful. This is especially dear to Mule people, since the active Stephen> development of Mule, at least in terms of (natural) language Stephen> additions, is nearly all taking place at the FSF. You must have some Stephen> thoughts about that. Or are you assuming that an eventual adoption of Stephen> Guile by the FSF will make an XE-scheme a positive advantage in Stephen> porting FSF code? I think any Lisp engine swap should be preceded by two things: 1. A full emulation of Emacs Lisp, either within the language substrate, or via a native compiler, or via simply including the old Elisp engine, for legacy code support. 2. A source-to-source translator which turns readable Elisp into halfway-readable substrate code for permanent migration. The need for both won't go away with either Scheme or CL. ms> (Note that the reverse is not generally possible, since Common ms> Lisp is not properly tail-recursive and does not support ms> control abstraction.) Stephen> Do we care? Ie, can you give specific examples where those features Stephen> would be useful to developers, either of the core XEmacs or of Stephen> application libraries, or enhance efficiency of a running XEmacs? You're quoting me out of context: I was talking about running Scheme code inside a Common Lisp substrate. Scheme code *very* often depends on the underlying implementation being properly tail recursive. (This essentially means that tail-recursive call don't consume stack space. The Revised^5 Report on Scheme contains a rationale.) Therefore, these Scheme programs won't run properly in a Common Lisp implementation which isn't properly tail-recursive. Some Scheme code relies on full-fledged continuation reification, specifially code which implements co-routines, threads, generators, exception mechanisms, etc. etc. Common Lisp supports only a very limited form of control abstraction in the form of catch/throw which works only in one direction (upwards-only). This makes catch/throw unsuitable for the applications I enumerated. Scheme's call/cc works in both directions. Adding efficient call/cc to a language substrate which wasn't designed with it in mind is usually very difficult, because it requires either a CPS-converting compiler or a stack fragmentation mechanism. Stephen> The answer I need is _not_ "I already told you it's properly Stephen> tail-recursive, what more do you need to know?" I know what tail Stephen> recursion is; I don't know what "proper tail recursion" is. The term doesn't exist as a noun. As I said above, a Scheme implementation is properly tail-recursive if it implements tail calls as gotos. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla