5 ms·

I should be more clear. I don't think that just because Emacs contains an Elisp interpreter, we should call it a "non-native" application -- even if Elisp is in

I should be more clear. I don't think that just because Emacs contains an Elisp interpreter, we should call it a "non-native" application -- even if Elisp is integral to Emacs' operation. If forced, I would say that Emacs-the-platform is native, and Emacs the system of Editor MACroS is not, since the macros run on the Emacs platform. But it seems kind of pedantic.

lispm 10y ago
The Lisp code is not natively executed. Some features like memory management (garbage collection) are layered on top of the OS. The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems. The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...). etc.etc.
- gmfawcett 10y ago
  I never said the Lisp code was natively executed. I'm not sure where you got that idea. Let's just agree to disagree. We are talking past each other at this point. Best regards!
  - deleted 10y ago
    [deleted]
  - kazinator 10y ago
    I think that the definition of "native" should take into account how the code interacts with the system. Because compiling code to the native instruction set shouldn't affect the semantics: so why should that be the only yard-stick for "native", right? What is semantically relevant is: how much of the platform is exposed to the programs directly, versus through abstractions. Suppose a language like Emacs Lisp or Java or whatever has only thin wrappers around POSIX through which applications interact with the platform. Then those programs are quasi-native POSIX programs, really. They are doing things like fork, waitpid, dup2 and whatever almost directly. And suppose that in the Windows version of that language, programs use functions that mimic CreateProcess or WaitForSingleObject. Then, regardless of the language being interpreted, it's really a native programming language.
klibertp 10y ago
> I don't think that just because Emacs contains an Elisp interpreter, The number of lines of Elisp my Emacs uses (counting plugins, but also built-ins) is actually more than twice the number of lines of C. It's not that "Emacs contains an interpreter", rather it's "Emacs has all these features written in Elisp [...a looong list here...] Oh, and it also has an interpreter to execute it all".

lispm 10y ago

The Lisp code is not natively executed. Some features like memory management (garbage collection) are layered on top of the OS. The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems. The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...). etc.etc.

gmfawcett 10y ago
I never said the Lisp code was natively executed. I'm not sure where you got that idea. Let's just agree to disagree. We are talking past each other at this point. Best regards!
- deleted 10y ago
  [deleted]
- kazinator 10y ago
  I think that the definition of "native" should take into account how the code interacts with the system. Because compiling code to the native instruction set shouldn't affect the semantics: so why should that be the only yard-stick for "native", right? What is semantically relevant is: how much of the platform is exposed to the programs directly, versus through abstractions. Suppose a language like Emacs Lisp or Java or whatever has only thin wrappers around POSIX through which applications interact with the platform. Then those programs are quasi-native POSIX programs, really. They are doing things like fork, waitpid, dup2 and whatever almost directly. And suppose that in the Windows version of that language, programs use functions that mimic CreateProcess or WaitForSingleObject. Then, regardless of the language being interpreted, it's really a native programming language.

klibertp 10y ago

> I don't think that just because Emacs contains an Elisp interpreter, The number of lines of Elisp my Emacs uses (counting plugins, but also built-ins) is actually more than twice the number of lines of C. It's not that "Emacs contains an interpreter", rather it's "Emacs has all these features written in Elisp [...a looong list here...] Oh, and it also has an interpreter to execute it all".