Jacek> Firstly, I think that CL is a much better general purpose
    Jacek> programming language than elisp. Having CL as emacs'
    Jacek> scripting language would increase the chances of users
    Jacek> recognizing Lisp as a general purpose language independent
    Jacek> of emacs.

    Jacek> Secondly, parts of emacs are written in C. Having emacs
    Jacek> completely implemented in CL, would probably help
    Jacek> significantly to expose Lisp as
    Jacek> a useful general purpose programming language.

    Jacek> Elisp is a scripting language implemented within one
    Jacek> application. CL would be a general purpose language used to
    Jacek> implement the actual application itself, as well as the
    Jacek> scripting language _of_ the application.

    Jacek> I think that this would (pleasantly) shock a lot of people,
    Jacek> and glaringly expose one of Lisp's big advantages.

    >> I don't know, can you fire up elisp without the editor? I
    >> haven't tried, but I suspect that it changes what you would
    >> think of doing with it.

    Jacek> This is what I am talking about: a change in attitude
    Jacek> towards the language which opens a whole new world of
    Jacek> possibilities.

The "Emacs in CL" thread has come up before, hasn't it? I agree of
course, but I suspect that the reasons it hasn't happened are more
political than technical. I'm no Lisp expert, so I can't exactly
volunteer to just jump in and do it. It could be sweet though.

  Tim

    Ng> The better name is "Hikk", like, a python hissing with a lisp.

    Ng> (Well, I don't know if pythons hiss or not. ;-)

I dunno, "Lython" thounds lithpy to me.

For instance, picking a CL implementation is a thorny matter:

 - Picking ACL/LispWorks buys some platform independence, but
   requires that users get ACL/LispWorks licenses.  The Emacs
   code may be "free," but the aggregate environment isn't.

 - The notable "libre" CLs are somewhat unsatisfactory in
   varying ways, /technically/.

Erik Naggum had a proposal that amounted to compiling CL into portable
C, which would get around this; that is by no means a trivial thing to
do.

Picking a CL implementation to use (or ensuring the result is
"portable" across several) is, all by itself, a big /political/ matter
that is a mandatory prerequisite to writing the first line of code.

  An Emacs in Common Lisp would need a full reimplementation of Emacs Lisp
  and would need an enormous compatibility layer if it were to do anything
  differently internally.  To succeed, it would also need to emulate both
  XEmacs and Emacs.  Then it would need to track the development of both
  Emacsen.  While it would make a lot of sense to reimplement the internals
  so that the MULEshit could be cleaned out and international support done
  right, Emacs is not just internals.  What would /really/ make a difference
  to users would be if Emacs Lisp could be compiled to native code and not
  have to run through the byte-code interpreter.

  Some of the other things I have wanted for a Common Lisp Emacs is a user
  process that handles file system interaction instead of the Emacs doing
  it directly, a separation of the displayable area and the "buffer" so
  that less of the data would need to be transferred to the Emacs process
  and converted to the internal character set, which should be Unicode, and
  such that changes to the actual file would require minimal work, and many
  other things that are very hard to do in Emacs today that would change
  the way Emacs behaves and which would make it so much more usable for
  large files and being a "control center" now that most computer users
  command a number of computer, usually widely dispersed.  Some of these
  ideas are strong enough that they could make a Common Lisp Emacs survive,
  but the amount of work to get there would simply be enormous.

--
Erik Naggum, Oslo, Norway

Well, I guess that sums it up, thanks for the insights. The sheer
volume of add-on code for existing Emacs versions makes the idea more
attractive, and the process more daunting.

Have the thoughts on this been distilled and localized somewhere?
Googiling around the subject in the past, I couldn't find the signal
amongst the noise within a sensible amount of time. There are links to
pages by Erik, but these all seemed to be dead.

Surely there's a case for throwing out the 'pure' backward
compatibility (as happened when emacs was ported from TECO macros to
Lisp) in favour of getting something working with a sane set of
internals and a clean programmatic interface to them. Initially one
could do ports of 'important' elisp modules to the new language by
hand, bearing in mind that it's generally better to port by writing a
pile of support functions rather than by changing the code itself.

It's still a *huge* pile of work of course, but by doing it
incrementally and worrying about the elisp interface later, you at
least get yourself a working, useful editor a good deal earlier in
your development cycle.

Not that I actually have the skills to put my money where my mouth is
here. Feel free to dismiss me as a crank, I was just curious as to
whether this sort of incremental approach had been considered.

--
Piers

  Well, how about the destillation: "It turned out to be a waste of time."

| Hmm ...  A quick look suggests that the plan is merely to stick guile
| onto Emacs.  Now I remember why I was so completely underwhelemed by the
| whole idea.

  I fear the whole Guile thing may be the end of Emacs as we know it.

--
Erik Naggum, Oslo, Norway

  Because even now, package developers are seriously pissed off by the
  incompatibilities between Emacs and XEmacs.

| Initially one could do ports of 'important' elisp modules to the new
| language by hand, bearing in mind that it's generally better to port by
| writing a pile of support functions rather than by changing the code
| itself.

  Emacs Lisp is the extension language built on top of the C substrate,
  which exports a large number of C-level decisions to Emacs Lisp.  In
  order for such a project to get off the ground at all, those packages
  that people are quite used to would have to work in the new Emacs.
  This means presenting a compatibility layer that is quite extensive.

  Take my word for it, if you want to change the substrate language, you
  will notice that the substrate language of Emacs really is C.  This is
  not something people will believe right away, since it superficially
  looks very much like a Lisp application.

| It's still a *huge* pile of work of course, but by doing it incrementally
| and worrying about the elisp interface later, you at least get yourself a
| working, useful editor a good deal earlier in your development cycle.

  Well, I went there, spent a few months hacking on clemacs (and even got
  the domain name), and discovered that it would take many years, for no
  real practical improvements until /way/ into the project.

| Not that I actually have the skills to put my money where my mouth is
| here.  Feel free to dismiss me as a crank, I was just curious as to
| whether this sort of incremental approach had been considered.

  All approaches you can think have been considered...

--
Erik Naggum, Oslo, Norway

Also think of the political effort needed, you would be declaring
effective war on the FSF's vision of emacs(guile).  From what I have
read the Emacs/XEmacs split was a very ugly affair.

Also to do this you need a  number of good programmers to spend
a serious chunk of time, each, to make it happen.  How do they get
compensated for the work?  The simple face is that if people are not
willing to pay for it, it is not important.  Money is honest.

    There were some initial indications that switching from a 2 day
  format to a 1 day format actually made the lab *harder* judged by
  the # of attempts/# of passes per day.

    This motivation provided a powerful incentive to Cisco to make it
  as easy as possible [without losing all credibility] for people to
  begin the CCIE certification process.  The end result: a flood of
  (relatively) un-experienced individuals who are certified as
  "experts" because they learned a lot about how to work with Cisco
  networking products.

    For example, one minimum requirement to take the lab is 2 years of
  full-time professional experience.  Many CCIEs have only 3 or 4
  years of experience.  Now, with the downturn in the economy, there
  is a glut of CCIEs - making the cert worth less for those of us who
  hold it.

    Moral:  don't let a vendor control the certification either...

If we imagine a lone developer doing this (I think it scales to lots
of people), then you find that this person uses a huge number of
random Emacs packages all the time, and that they do things that are
useful to them.  Little tools to maintain file headers, do cleverer
line wrapping, incrementally spell-check text files and mail messages,
make writing TeX pleasant, make writing HTML bearable, process files
in outline mode, edit lisp/C/Fortran/Java comfortably, insert
`signatures', integrate with 4 different source-control systems, read
news, read mail, &c &c.  Hundreds of the things.

The moment you get your CL-based editor off the ground, about the
first thing you find is that *none of this works*.  Even if the editor
is highly compatible with Emacs in it's `way of being' so things like
keystrokes work as you expect, nothing else works.  You still have to
use Emacs all the time.  Even if you have one thing that this editor
does better than Emacs - say it integrates with a CL system incredibly
well - then you still need two editors, because there is so much stuff
that Emacs does that you find you really need.  Until you've either
made this thing so you can simply use elisp, or reimplemented all the
Emacs stuff you use, you're stuck in this awkward position.

I went through this with hemlock.  Hemlock had Lisp interaction to die
for: at the time ilisp was a bad joke which would regularly crash
emacs, and even when it didn't hardly worked, but hemlock's
integration with CMUCL was a delight.  I even wrote some clever
form-selection stuff in Hemlock, based on what TEdit did, which would
have been significantly more work in Emacs (then).  But that was *all*
Hemlock did - it wouldn't run news, talk to CVS, keep file headers up
to date &c &c.  And every 3 days some new cool package would appear
for Emacs, but not for Hemlock. Eventually I stopped using it, when
lemacs started working and supported X properly, unlike emacs 18.

Cheers

Erik Naggum  <e...@naggum.no> wrote:

Kind regards,

He told me that Lisp was "inherently" (I'm pretty sure even after all
this time that this was his exact word) 100 times slower than C and
therefore an unsuitable vehicle.  I tried to explain to him that this
was implausible.  That he could probably construct an argument for 2-5
that he could at least defend in some prima facie way, but that 100
was ridiculous.  (This was in the heyday of Maclisp when it had been shown
to trump Fortran's speed, so probably even 2-5 could be refuted, but at least
taking a position in that range would have left him with some defenses in
a debate.  He didn't cite anything credible that I recall to back up this
factor of 100 problem.

I tried to explain why and was not clear why a person smart enough to
"maybe win a nobel prize" couldn't entertain a discussion on the
simple set of concepts involved, whether or not schooled in
computation.  It was quite frustrating and he seemed impatient.

He in fact did not purport to be adequately competent on the matter of
computation at the time but he pointed to a stack (literally) of books
(I'd say about a foot high) including the Knuth books, the compiler
book with the dragon on it, and a number of other really standard
texts.  He then said "I'm going to read these and then I'll know as
much as you."  (Again, I'm pretty sure even now that this is pretty
close to an exact quote.  But whether it's exact or not, what struck
me was the incredible arrogance of the remark.) The point seemed
debatable, but I didn't bother to debate it.  He seemed deadset on his
goal and once he got to the point where he seemed to feel he could use
as a credential books he had not yet read, there seemed to be no
deflecting him.

My real concern, of course, was not that he was using optimized data
structures so much as that he seemed on target to reintroduce
numerical error back into a world that we had worked hard to make
'exact' (Macsyma used bignums from Lisp) or at least 'arbitrarily
exact' (Macsyma had a derived type called 'bigfloat' that was
internally a pair bignums, acting more or less as a ratio but with
lots of other hidden bits to assure that any decimalization had enough
bits to be precise to a given number of digits).  Stephen's aim seemed
to be to sacrifice correctness for speed.

He seemed clear on that the error was not a problem for him.  I'm not
a domain expert and I can only assume that he did know what he was
doing when he accepted an approximation over an exact value.  Probably
HE had a good reason.  But I worried for others, and recall telling
him so.  My specific recollection of this part of the discussion is
less clear, but I'm pretty sure his response was that what tools
others chose to use or not use was not his concern.  

There's a fine ethical line here between simply making a tool and
actively promoting it, but I'll not expound on that in detail.
Rather, I'll just say that this line concerned me.  The problem I
have, and had then, is that other users, not him, might NOT understand
that this trade-off had been made and so might not be making an
informed choice.  People tend to say "well, if it's good enough for
him" rather than "well, if it's good enough for the purpose he had in
mind" since presumably there are other applications Stephen or anyone
could have come up with that would not have tolerated error.

But ah well.  History marched on and what happened happened.

I think that if a cl-emacs "takes off" it will be on its own merits,
not as a GNU Emacs clone.  I'm not sure what the driving force will
be; perhaps good integration with the development environment and CLIM,
perhaps real editing with shared kill ring in every text widget.

| This doesn't really explain why you stopped using Hemlock... was
| unbearable to switch between editors for different tasks?

I don't know why he did, but to me it's a royal pain switching between
programs having similar but not quite the same keybindings.  Of
course, any program worth its salt lets you change keybindings (except
vi - I'm not sure about vim), but unless I use it a lot I don't
usually bother.  I mean, how much time do you want to spend diddling
with your environment instead of doing real work?  I guess I am really
conservative on this front.  I've only ever used three window managers
(twm, fvwm, sawfish) and don't really want to change again unless
bitrot makes the current one totally useless.  But I seem to have
gotten off along a tangent here...  Even if you can change keybindings
to make to editors more similar, there will always be differences that
tend to confuse, and paradoxically the more subtle the differences,
the more likely they are to trap you.  When Norwegians and Swedes
converse, misunderstandings often occur because we think we understand
each other's language perfectly well, when in fact we do not.  So in
summary, I am much more comfortable switching between emacs and vi
than between emacs and some other emacs-like editor.  In fact, I often
prefer to use vim for many trivial editing jobs.

  Why, yes, of course.  (And I'm dead serious, too.)  (Well, almost.)

--
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.

But this may have been due to the extraordinary efforts of Ray and the
ALU and Franz. And because they cast the net wider; I heard a lot of
talks that included "I suppose I should mention Lisp at least once
before ending, so...we use Lisp. Questions?".

:)

--

So, I stick with the GNU Emacs. It's the old Baby Duck syndrome.

However I do agree with Tim there's no reason why CLEmacs needs to "Do
Everything" on day one, and that perhaps it could just provide a better
environment and tighter integration with a CL image.

Regards,