Re: Where do you want to go tomorrow?

Hrvoje> Common Lisp is much closer to elisp than any Scheme Hrvoje> dialect is. Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber Hrvoje> [Mr. Preprocessor]) writes: Hrvoje> Lots of elisp code can run under Common Lisp almost Hrvoje> unchanged. This is not true for Scheme. I thought you had agreed that translators for porting old elisp can be written? The question is "how hard will it be for developers to change their mindsets", and from a brief review of some Scheme code I don't think this will be that hard for me personally. XE-Scheme is going to look an awful lot like elisp as far as I can tell, except for some changes in conventions (like using `?' instead of `p' as the "predicate suffix"). But most function calls will be to editor functions, just as they are today, at least from my personal perspective. What specifically is going to be hard for you in the transition? ("Breaking with traditional naming conventions" is not trivial IMO, but I personally could live with it.) Hrvoje> I've argued for Common Lisp, both in this thread and Hrvoje> elsewhere, but you kept rejecting my arguments as either Hrvoje> irrelevant or false. So I don't know what else to say to Hrvoje> you. But (from this third party's point of view) neither of you has really explained what the advantages are to your preferred dialect. ms> Sure, some people will prefer different programming idioms ms> when they have the full power of Scheme available. But they ms> don't have to. I use Scheme programming idioms when writing ms> Elisp, for that matter. Look at my code. If you want to use ms> Common Lisp idioms when using Scheme, that's absolutely fine. ms> In fact, you can make Scheme look almost completely like ms> Common Lisp, if you want to. One thing that we have banged up against a couple of times recently is the "global option-variable vs. function argument" thing. This is especially annoying in the Mule modules, since the FSF implementation keeps changing and it's useful to keep synch in many cases. It would be nice to have CL-like keyword arguments. Is this doable in a robust way in Scheme? Would it be efficient, especially when compiled? If Hrvoje is correct that much elisp code can be swallowed raw by a CL implementation, then this should make synching with the FSF much less painful. This is especially dear to Mule people, since the active development of Mule, at least in terms of (natural) language additions, is nearly all taking place at the FSF. You must have some thoughts about that. Or are you assuming that an eventual adoption of Guile by the FSF will make an XE-scheme a positive advantage in porting FSF code? 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.) Do we care? Ie, can you give specific examples where those features would be useful to developers, either of the core XEmacs or of application libraries, or enhance efficiency of a running XEmacs? The answer I need is _not_ "I already told you it's properly tail-recursive, what more do you need to know?" I know what tail recursion is; I don't know what "proper tail recursion" is. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091