3 ms·

It's not nonsensical, but if you were writing emacs in rust, you hopefully would use a typed language instead of elisp

by vatsachak 12d ago

dismalaf 12d ago
Why? There's no point having a typed config/scripting language...
- vatsachak 12d ago
  You're assuming that the scripts are small. e-lisp code is massive!
  - kazinator 11d ago
    Where is the fire? Is the Emacs ecosystem collapsing because of type errors undiagnosed when .el files are scanned?
    - vatsachak 11d ago
      I mean emacs has way more bugs than modern editors. Types would help you fix that and let you optimize code more since they help with "proving" that your code is correct. I feel like emacs could be way better if e-lisp was typed but I write Rust for a living and Haskell/Lean for fun so maybe I'm biased
      - iLemming 5d ago
        > has way more bugs than modern editors That's just factually untrue. Emacs core is not obviously buggier than, let's say, VSCode, which has tens of thousands of open issues and is written in Typescript. What differs is visibility. Emacs throws a backtrace in your face; VSCode swallows extension errors into a log nobody reads. And every Emacs user runs a unique build with like 350 packages nobody tested together; try to even start VSCode with half that number of plugins. The bugs that actually hurt in Emacs are state bugs, not type bugs. Two packages advise the same function. A buffer-local variable is set in one mode and read in another. Dynamic binding leaks. None of that is a type error in the Haskell sense. The dynamism is the product, not an accident. Redefining any function at runtime, advising anything, inspecting live state - that is why people use Emacs instead of an editor with a plugin API. Strong static types plus separate compilation cut against late binding everywhere. You're not "biased", you just seem to be unfamiliar with the type dynamism in Lisp systems. Dynamic types are not equally bad everywhere; don't take what you know about Python and apply it the same way to things built in, e.g., Clojure.
neutronicus 11d ago
If you're re-writing emacs at all, it's because you believe that a Lisp interpreter is the best way to extend a text editor. Or, at the very least, you want to execute pre-existing elisp. I can see moving some core functionality currently implemented in elisp into Rust (or whatever typed intermediate implementation language). But there is a cost to having stuff in the core - user can't step into C functions with the elisp debugger.
- vatsachak 11d ago
  Given how fast computers are these days there is probably not much overhead in having emacs run as the interpreter for an incrementally compiled language with HM types
iLemming 5d ago
You're spitting nonsense. Emacs cannot exists without running inside a Lisp REPL loop. Emacs is not a text editor, technically it's a Lisp REPL with the built-in editor. Dynamism and malleability on the live image is the point. That's the categorical feature of Emacs. Any attempt to build it differently; well, will end up being not Emacs - entirely something else.

It's not nonsensical, but if you were writing emacs in rust, you hopefully would use a typed language instead of elisp

dismalaf 12d ago

Why? There's no point having a typed config/scripting language...

vatsachak 12d ago
You're assuming that the scripts are small. e-lisp code is massive!
- kazinator 11d ago
  Where is the fire? Is the Emacs ecosystem collapsing because of type errors undiagnosed when .el files are scanned?
  - vatsachak 11d ago
    I mean emacs has way more bugs than modern editors. Types would help you fix that and let you optimize code more since they help with "proving" that your code is correct. I feel like emacs could be way better if e-lisp was typed but I write Rust for a living and Haskell/Lean for fun so maybe I'm biased
    - iLemming 5d ago
      > has way more bugs than modern editors That's just factually untrue. Emacs core is not obviously buggier than, let's say, VSCode, which has tens of thousands of open issues and is written in Typescript. What differs is visibility. Emacs throws a backtrace in your face; VSCode swallows extension errors into a log nobody reads. And every Emacs user runs a unique build with like 350 packages nobody tested together; try to even start VSCode with half that number of plugins. The bugs that actually hurt in Emacs are state bugs, not type bugs. Two packages advise the same function. A buffer-local variable is set in one mode and read in another. Dynamic binding leaks. None of that is a type error in the Haskell sense. The dynamism is the product, not an accident. Redefining any function at runtime, advising anything, inspecting live state - that is why people use Emacs instead of an editor with a plugin API. Strong static types plus separate compilation cut against late binding everywhere. You're not "biased", you just seem to be unfamiliar with the type dynamism in Lisp systems. Dynamic types are not equally bad everywhere; don't take what you know about Python and apply it the same way to things built in, e.g., Clojure.

neutronicus 11d ago

If you're re-writing emacs at all, it's because you believe that a Lisp interpreter is the best way to extend a text editor. Or, at the very least, you want to execute pre-existing elisp. I can see moving some core functionality currently implemented in elisp into Rust (or whatever typed intermediate implementation language). But there is a cost to having stuff in the core - user can't step into C functions with the elisp debugger.

vatsachak 11d ago
Given how fast computers are these days there is probably not much overhead in having emacs run as the interpreter for an incrementally compiled language with HM types

iLemming 5d ago

You're spitting nonsense. Emacs cannot exists without running inside a Lisp REPL loop. Emacs is not a text editor, technically it's a Lisp REPL with the built-in editor. Dynamism and malleability on the live image is the point. That's the categorical feature of Emacs. Any attempt to build it differently; well, will end up being not Emacs - entirely something else.