[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Questions about throw-on-input
From: |
Drew Adams |
Subject: |
RE: Questions about throw-on-input |
Date: |
Thu, 14 May 2020 09:56:13 -0700 (PDT) |
> > Your ideal world seems to be based on an editor design that is very
> > different from what Emacs is. The absolute majority of objects which
> > an average Lisp program manipulates are globally visible -- buffers,
> > windows, frames, global variables, the obarray, etc., and doing that
> > in non-blocking ways is not really trivial.
>
> And that's what I'd call one of the biggest problems in current
> Emacs's design. Much of the development in programming practices over
> the last few decades has been moving away from global mutable state,
> in order to increase robustness and predictability, and also to make
> concurrency without subprocesses possible.
Ah, but Emacs and Emacs Lisp are not just about
programming and writing Elisp libraries.
Certainly, a purely functional (or purely
logic/relational) language has advantages
(many, many!) from a programming point of view.
But Emacs Lisp, and in particular the global
thingies you decry, and in particular dynamic
binding, are very useful for Emacs _users_,
for easy customization/extension.
Again, I point to the rationale:
https://www.gnu.org/software/emacs/emacs-paper.html#SEC17
https://www.gnu.org/software/emacs/emacs-paper.html#SEC18
Emacs Lisp is not Haskell, and it's not Scheme.
You may say, "Alas", but until you or someone
else comes up with a reasonably useful "editor"
on the order of Emacs and Elisp, but which uses
only pure Lisp (no side effects) or Haskell, I
remain skeptical.
The argument for the presence of such dynamic,
and sometimes global, thingies is not an argument
against lexical etc. or an argument in favor of
abusing or exaggerating the use of global etc.
thingies. It's just to point out that they have
their place, in a context such as Emacs. They're
not just things to be purged in some blanket
cleanup campaign.
- Re: Questions about throw-on-input, (continued)
- Re: Questions about throw-on-input, Eli Zaretskii, 2020/05/11
- Re: Questions about throw-on-input, Stefan Monnier, 2020/05/11
- Re: Questions about throw-on-input, Alexander Miller, 2020/05/11
- Re: Questions about throw-on-input, Stefan Monnier, 2020/05/11
- Re: Questions about throw-on-input, Alexander Miller, 2020/05/12
- Re: Questions about throw-on-input, Eli Zaretskii, 2020/05/13
- Re: Questions about throw-on-input, Alexander Miller, 2020/05/13
- Re: Questions about throw-on-input, Philipp Stephani, 2020/05/14
- Re: Questions about throw-on-input, Eli Zaretskii, 2020/05/14
- Re: Questions about throw-on-input, Philipp Stephani, 2020/05/14
- RE: Questions about throw-on-input,
Drew Adams <=
- Re: Questions about throw-on-input, Richard Stallman, 2020/05/14
- Re: Questions about throw-on-input, Stefan Monnier, 2020/05/14
- Re: Questions about throw-on-input, Arthur Miller, 2020/05/15
- Re: Questions about throw-on-input, Stefan Monnier, 2020/05/15
- Re: Questions about throw-on-input, Yuan Fu, 2020/05/15
- Re: Questions about throw-on-input, Stefan Monnier, 2020/05/15
- Re: Questions about throw-on-input, yyoncho, 2020/05/15
- Re: Questions about throw-on-input, Alexander Miller, 2020/05/15
- Re: Questions about throw-on-input, Stefan Monnier, 2020/05/15
- Re: Questions about throw-on-input, Philipp Stephani, 2020/05/15