Re: Shrinking the C core

[Arthur Miller <arthur.miller@live.com>]

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. ]]]
>
>   > It was designed for the time of single-core slow
>   > machine, and its design makes sense in that perspective. 
>
> That is true.
>
>                                                              However, for
>   > todays multicore machines, the fact that a lisp machine is slapped on
>   > top of an existing text editor (Gosslings I guess),
>
> No, that's not how I developed it.
>
> I first wrote Emacs Lisp as a standalone Lisp interpreter.
> Then I wrote the code to handle buffers and editing the text in them.

Ah; I thought I remembered either from some of your articles or some of
earlier disucssions that you obtained a copy of GE from a friend, and
realized it needed a proper Lisp interpreter. Cool to hear a bit of
history, thank you.

> Turning to the question of future development,
> I think the design of Emacs is good enough,
> To rewrite Emacs completely would be an enormous misdirected effort.

No, I don't suggest to rewrite entire Emacs. On contrary I am
conservative about keeping Elisp as-is, as I said, it would be a waste
of human effort to throw away 40 years of work. No, on the contrary, and
that is why I suggested what I did, otherwise I would go to some greener
editor and use that; if I didn't found all the old work important, so to
say.

I suggest to re-implement the Lisp API implemented in C, in Common
Lisp. I understand that you didn't like Common Lisp back in the time
because it was big and slow for the computers at that time; but nowadays
things have changed. SBCL and CCL are two quite good compilers and would
give access to more advanced Lisp Machines than what one in Emacs is,
better garbage collector, native threading, namespaces, and so on.

> GNU Emacs is a part of the GNU opersating system,
> whose goal is to provide, in the Free World, all the features
> that people want.

Well, yes, I totally understand and agree. What I see from the
interaction with the Emacs community on social media, or at least on
Reddit where most of non-dev community seems to be, people want features
that are not in Emacs. Those mentioned above come up quite
often.

But it is about more than just features. It is about the widening the
community. Free world is bigger than just Emacs, as you seem to imply
yourself. Lisp communities are small, I think it is a pitty that we
can't natively use Common Lisp libraries. If we had Emacs implemented in
Common Lisp, we would get access to lots more libraries and tools than
what is in Elisp packages only. More eyes would be looking at Emacs too.

If extension and implementation language were the same, than more people
would potentially get enabled to contribute to Emacs. Of course, just
having the core in a hackable Lisp language does not mean everyone
*will* contribute or be able to contribute, but potentially, there might
be one or another individual that would. It might encourage more
experimentation and make it easier to test new ideas.

The speed of Emacs development would potentially increase; developing in
Lisp is much faster compared to hack, recompile, start Emacs
cycle. Don't get me wrong, I don't mean hacking C is hard, impenetrable,
undoable or so, I am just saying it could be smoother and faster.

People also do ask for better tools that enable "programming at large"
in Emacs. We do use Emacs for more than just editing text at least some
of us; it has become an automation tool. People also seems to want to
use Emacs and Emacs Lisp as a more general programming tool to solve
other problems, not just to extend the text editor. I think it is a good
thing.

> With the same work it would take to rewrite Emacs from scratch,

I see I have expressed myself exaggerated; I wrote the mail in just 3-4
minutes of fast typing; I should have probably explained myself
better. I meant that certain parts of Emacs have to be re-designed from
the scrath, things that prohibit multithreading, the shared state. It
does not necessary mean, that I suggest to throw away entire Emacs and
rewrite everything from scratch.

> we could write some other complex and powerful free program
> which does some other job -- a job that there is no free software to
> do.

Or we could improve Emacs and make it a powerful tool in another areas
where it is not as used.

For example, I think Emacs would be great as a teaching tool, I think I
have said that before on this list. I see concept of buffers in Emacs
Lisp, or rather to say, concept of editor implemented in the programming
language as a really good and useful tool. I mean it. Common Lisp
(probably some before it) has given us a repl as a mandatory tool in the
language. Emacs Lisp shows us that an editor as part of the environment
or language is as important as repl. I do miss edebug and seing the
result in another buffer when stepping through when I program with
sbcl. I wish Common Lisp had buffers and editor built-in. Implementing
Emacs in Common Lisp, would in a way, merge those two, and perhaps Emacs
could be used as another Processing or as a teaching tool where kids can
learn programming by interactive development, have the environment
avaialable for introspection, step through and see the results as they
execute the code and similar.

> Or we could add features -- to Emacs or some other free program -- which
> would greatly extend what people can do in the Free World.
>
> Consider, for instance, the idea of extending a free spell checking
> program so it could tell you the gender of each noun if you ask.
> Going beyond that, maybe it could check for agreement of modifiers
> with their nouns.  That would be a big help for writing in many
> Indo-European languages and Semitic languages.  Perhaps also other
> languages which have something grammatically like gender but not
> based on gender of humans.

I have no familiarity with spell-checking so I can't reflect on that one. I
struggled to install Hunspell in my Emacs untill Zaretsky helped me some
10 years ago or so :). But what you suggest seems to me like you would
need to find an expert for each language in question, which suggests
rather social skills than programming skills. I am more for solving math
problems after eveyone else is at sleep, so I can't help you with that one.

> That would be a tiny fraction of the work that people are proposing
> here.

I think on contrary; I propose to switch Emacs to a different Lisp
implementation so that devs here don't have to re-implement and maintain
some important parts of the Lisp Machine if Emacs will get features lots
of people seem to ask for. While what I suggest is a volumous work as
well, it also save a lot of work elsewhere, and opens some other
possibilities.

By the way, a single threaded shared state does not thread itself just
because it is transplanted over a multithreaded implementation :). Of
course. But getting access to such platform enables people to use
threads, while the implementation itself is tranformed, as well as buys
other benefits as discussed above.

Thanks for the kind answer, and I am hope I am not take wrong; I don't
mean Emacs is bad, and certainly notthing wrong. Actually I am very fond
of Emacs, I find it very useful tool, and would just like to see it ever
better.