3:19 p.m.
sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
Hrvoje> Common Lisp is much closer to elisp than any Scheme
dialect
Hrvoje> is.
You've said that on a number of occasions, but I don't even know
what you mean. Actually, I claim this is false.
Lots of elisp code can run under Common Lisp almost unchanged. This
is not true for Scheme.
Hrvoje> Using Scheme as a primary language in XEmacs will alienate
a
Hrvoje> large number of our contributors, and I, for one, do not
Hrvoje> want to see that happen.
If that is indeed so, I'm more than willing to give in. However, we
don't have any evidence for this statement yet.
I don't want us to find the evidence for it the hard way.
I personally believe a small substrate is less likely to alienate
people than a large substrate.
I believe clisp is small enough, especially if we remove the parts we
don't need. Bruno Haible, the primary Clisp maintainer, offered his
help to do this. Someone with more clisp experience should speak up.
Hrvoje> Translators or compatibility packages for elisp
implemented
Hrvoje> in Scheme would of little help, except for porting old code.
You consider porting old code (several hundred thousands of lines)
"of little help"?
You are pulling my words out of context. Yes, translators are of
little help, because all they will ever achieve is porting old code.
My goal is having lots of new code in XEmacs.
Hrvoje> I doubt anyone will consider using them to write new,
Hrvoje> XEmacs-specific code.
Of course not, that's why we want a substrate change in the first
place. What's your point?
My point is that choosing Common Lisp is a better idea because it is
closer to Emacs Lisp. But if you answer that you "don't know what I
mean", or that it is false, then we don't have a discussion, do we?
Hrvoje> My second argument is that XEmacs has been going in the
Hrvoje> direction of Common Lisp for several years now. Extensions
Hrvoje> such as cl.el show that pretty clearly.
I honestly want to understand what you mean by this, but I don't.
Sure, it has made sense to write Elisp libraries with constructs
modelled like equivalent constructs in Common Lisp. It makes sense
to write Scheme libraries with those constructs as well.
Does it? Not for me!
Sure, some people will prefer different programming idioms when they
have the full power of Scheme available. But they don't have to. I
use Scheme programming idioms when writing Elisp, for that matter.
Look at my code. If you want to use Common Lisp idioms when using
Scheme, that's absolutely fine. In fact, you can make Scheme look
almost completely like Common Lisp, if you want to.
Yes, that's what we were doing with Emacs Lisp, and I don't really
like the "poor man's common lisp" any more.
Hrvoje> Suppose the impossible happens, and Erik does come in and
Hrvoje> does all the work to port XEmacs Lisp to, say, clisp. Would
Hrvoje> you quit XEmacs development?
Yes.
[...]
Hrvoje> Now replace Erik with Bruno or Hrvoje. Do the answers
change?
Absolutely.
OK, that's what I wanted to know. We can keep discussing.
Hrvoje> I think that you are arguing for Scheme because of
personal
Hrvoje> preferences, which is perfectly natural. Your battle plan
Hrvoje> includes only Scheme-based options, and I think that no
Hrvoje> words of mine would ever convince you to consider anything
Hrvoje> else.
There must be a misunderstanding here, Hrvoje. My "battle plan" (I
assume you're referring to my Web page on the subject matter)
*specifically* includes other options.
Yes, but all the "Lisp engines" you mention are Scheme engines.
Moreover, I've reserved Web space for arguments on Common Lisp,
but
nobody has sent me anything yet to put there.
I've argued for Common Lisp, both in this thread and elsewhere, but
you kept rejecting my arguments as either irrelevant or false. So I
don't know what else to say to you.
Hrvoje> This is why I think our disagreements can be only settled
by a
Hrvoje> split, or by one of us leaving the development.
I don't get it Hrvoje, we've hardly started discussion on this, and
already you claim an irreconcileable split. Why?
Because there is little real discussion between us. I have no
problems with you, and you have no problems with me, but on this
particular issue the two of us appear to be unable to communicate
reasonably. All of my arguments are met with "I don't understand you"
or "I claim this is false." I'm at a loss how to approach discussion
on this topic.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Personifiers Unite! You have nothing to lose but Mr. Dignity!
4:58 p.m.
New subject: Where do you want to go tomorrow?
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
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:
> You've said that on a number of occasions, but I don't
even
> know what you mean. Actually, I claim this is false.
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.)
> Moreover, I've reserved Web space for arguments on Common
Lisp,
> but nobody has sent me anything yet to put there.
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" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
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
9641
days inactive
9641
days old
1 comments
2 participants
participants (2)
-
Hrvoje Niksic -
Stephen J. Turnbull