Re: Shrinking the C core

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Would you please stop arguing for rewriting Emacs in Common Lisp?  It
> is a non-starter.

Can we not even talk about it?

Is it really bad to talk about an idea? If you believe that such a
simple idea can hurt you or your project, than I don't think "free
speach" and GNU goes together in the same text, more than possibly as a
sarcastic remark.

> It would be an enormouse job

Sure. I agree on that one.

>                                 including rewriting the Emacs Lisp
> Referance Manual.

Actually, I don't know if I was clear in my first post, but my raison
d'etre for converting Emacs to CL is to actually preserve emacs-lisp bug
by bug, feature by feature, for the explicit reason of not throwing away
40 years of work. As I said; Emacs Lisp is *the* best documented Lisp,
and that is extremely important. People complain a lot on social media
about CL being arcane (hyperspec) and 3rd party libraries undocumented
or badly documented. In my opinion the strong points of elisp are
documentation, manual, 3rd party packages and being relatively small.

Otherwise, if I didn't want to preserve the documentation and manual,
and don't want to run Emacs applications, I would just go over to some
of the text editors already implemented in common lisp. Their problem is
that they are "emacs like", but not Emacs. They basically have to
re-implement everything from scratch. Which is a shame. But if we
implement emacs lisp in cl than we can run 3rd party apps in Emacs in CL
and people can re-use their knowledge, docs and the manual in writing
3rd party applications.

>                    We can't be sure how much the benefit would be,

You can't know anything for sure. But you do know that you would got
work that yat has to be done in Emacs, and you know that you would get
language features that lots of people ask for. It seems that either
Common Lisp will come to Emacs or Emacs will come to Common Lisp,
judging by the attitudes that pop-up in social media from time to time.

You would also get faster iteration time. Testing Emacs core function
would be similar to working in Emacs Lisp: eval and run; instead of
recompile and re-start Emacs just to test.

You would also unify the extension language and the implementation
language, so more people would, at least in theory, be able to look and
fix and experiment with the core. Testing a different renderer or a
different buffer implementation could become much less tedious prospect
than in C core.

Of course, it is not "just", but I would like to hear would be technical
problems, or if it is not technically possible.

As I udnerstand Common Lisp was invented to unify all the dialects such
as Emacs Lisp, and seemed to work well. I see no special technical
problems in implementing elisp in cl either, but I am not an expert and
not so familiar with CL yet, so I have hoped for some constructive input
not trolling and sarcasms.

> because Common Lisp has some drawbacks too.

Sure. Everything has drawbacks. So is life. And in life we are
constantly navigating between cost and gain.

Tell me which are drawbacks; that is actually what I am interesting
in. CL is much bigger, EL is easier to learn, that is my personal
remark, but I think it is secondary compared to what we can get with CL.

>                                              But we know the cost is
> prohibitive.

Perhaps. The cost is certainly prohibitive for a single person to do it
all on their own.

TBH I hoped for some technical input like "it is possible because of" or
this can't be done in CL because of or whatever. Instead I have got a
sarcasm and a troll answer. I should have known though better than to
answer on that one; it takes two to troll, so I guess we are both
guilty there.

That would be my answer to remark about kind communication in the latter
mail.