3 ms·

A lot of people seem to be reading this as if Emacs is choosing between switching languages to Scheme (Guile) or Common Lisp. Switching to Guile DOES NOT IMPLY

by tedks 12y ago

A lot of people seem to be reading this as if Emacs is choosing between switching languages to Scheme (Guile) or Common Lisp. Switching to Guile DOES NOT IMPLY switching to Scheme. There is 0 need for compatibility layer or what have you with Guile. Guile is a language-agnostic virtual machine. It has an implementation for Scheme, but also one for Emacs Lisp. Guile already runs Emacs Lisp faster than Emacs: https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00665.html https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00... The main issue the Emacs developers seem to have with Guile is that it will give developers choices as to whether to write Emacs extensions in Scheme, Elisp, or Javascript/Python/Whatever else Guile supports.

rthomas6 12y ago
>The main issue the Emacs developers seem to have with Guile is that it will give developers choices as to whether to write Emacs extensions in Scheme, Elisp, or Javascript/Python/Whatever else Guile supports I don't understand why they care? Why would the Emacs developers feel the need to debug compatibility if someone else wrote a shitty extension? The onus would be on the extension developer to fix the extension.
- flatline 12y ago
  Sure the problem defaults to the package maintainer, but historically popular and/or useful packages have seen their way into the main GNU distribution. Just leaving the possibility open has some long-term consequences for the project.
- tedks 12y ago
  I think it's largely a cultural objection, and one I feel is pretty valid. I would hate to see Emacs turned into a javascript playground.
- babarock 12y ago
  Quoting the linked email: So if we go for Guile-Emacs, we'll be stuck with Guile, i.e. we'd have (old and new) packages that use Elisp, new packages that use Scheme, maybe yet other new packages that use, say, Javascript (or some other language support by Guile). That would make the work of Emacs (and GNU ELPA) maintenance harder.
  - Steltek 12y ago
    So don't accept packages into the Emacs core that don't meet their standards? It's okay to have project standards but limiting how other people use your tool seems terribly misguided for a GNU project.

by tedks 12y ago

rthomas6 12y ago

>The main issue the Emacs developers seem to have with Guile is that it will give developers choices as to whether to write Emacs extensions in Scheme, Elisp, or Javascript/Python/Whatever else Guile supports I don't understand why they care? Why would the Emacs developers feel the need to debug compatibility if someone else wrote a shitty extension? The onus would be on the extension developer to fix the extension.

flatline 12y ago
Sure the problem defaults to the package maintainer, but historically popular and/or useful packages have seen their way into the main GNU distribution. Just leaving the possibility open has some long-term consequences for the project.
tedks 12y ago
I think it's largely a cultural objection, and one I feel is pretty valid. I would hate to see Emacs turned into a javascript playground.
babarock 12y ago
Quoting the linked email: So if we go for Guile-Emacs, we'll be stuck with Guile, i.e. we'd have (old and new) packages that use Elisp, new packages that use Scheme, maybe yet other new packages that use, say, Javascript (or some other language support by Guile). That would make the work of Emacs (and GNU ELPA) maintenance harder.
- Steltek 12y ago
  So don't accept packages into the Emacs core that don't meet their standards? It's okay to have project standards but limiting how other people use your tool seems terribly misguided for a GNU project.