11–20 of 84 posts
This seems convoluted compared to say moving the Lisp implementation from Emacs Lisp to Common Lisp, of which several native code compiling implementations exists.
Great job all around!
Earlier quoted context omitted.
Depends on how difficult it is to integrate Common Lisp into Emacs. Or would you just be rewriting Emacs in Common Lisp?
The issue is the importance of all the existing packages — invalidate them and nobody will use your implementation. There are small syntactic differences between Emacs lisp and Common Lisp so a lexer that handled those would suffice. There are some small semantic differences but they could be handled by porting code. And the Emacs c code could be rewritten in lisp or ported into the Common Lisp implementation, depend…
> There are some small semantic differences but they could be handled by porting code. I suspect there are more than just small differences. And someone would have to do the work to port the code. I suspect that if packages that people use don't work, they will just avoid using the new version of Emacs, as opposed to abandoning the package.
It's not an impossible project, but it's not clear to me it's easier/better than the proposed solution.
Earlier quoted context omitted.
You don't need to rewrite packages if you have a layer where Emacs Lisp is compiled/interpreted as Common Lisp. You can easily hack the readtable in Lisp, and rewrite Emacs Lisp sexps as Common Lisp sexps. Some interesting things to consider are file-local variables, buffer-local variables, dynamic-scope/lexical-scope, how to handle floating point (-0.0e+NaN in Emacs Lisp, custom floating point rouding modes/traps in…
Emacs contains a quarter million lines of C. What do you do with all the elisp that calls into it? Maybe that could be turned into a "libemacs" and used from FFI.
Earlier quoted context omitted.
The issue is the importance of all the existing packages — invalidate them and nobody will use your implementation. There are small syntactic differences between Emacs lisp and Common Lisp so a lexer that handled those would suffice. There are some small semantic differences but they could be handled by porting code. And the Emacs c code could be rewritten in lisp or ported into the Common Lisp implementation, depend…
The existing package ecosystem is one of the main value propositions of Emacs. Otherwise a re-implementation with a different extension language could have replaced it a long time ago. > There are some small semantic differences but they could be handled by porting code. I suspect there are more than just small differences. And someone would have to do the work to port the code. I suspect that if packages that people…
Earlier quoted context omitted.
You don't need to rewrite packages if you have a layer where Emacs Lisp is compiled/interpreted as Common Lisp. You can easily hack the readtable in Lisp, and rewrite Emacs Lisp sexps as Common Lisp sexps. Some interesting things to consider are file-local variables, buffer-local variables, dynamic-scope/lexical-scope, how to handle floating point (-0.0e+NaN in Emacs Lisp, custom floating point rouding modes/traps in…
Emacs contains a quarter million lines of C. What do you do with all the elisp that calls into it? Maybe that could be turned into a "libemacs" and used from FFI.
Any kind of rewrite of Emacs is going to be a lot of work, I am not denying that. But if we assume there is a layer where everything works as it currently does (the C primitives), the Emacs Lisp defined on top of that needs not be defined in C, as far as I know.
Also, the last time I checked, there were a ton of legacy stuff in the configure script for different platforms.
Earlier quoted context omitted.
Rewriting thousands of packages (some of which have had man-decades of work poured into them) would also be rather convoluted.
You don't need to rewrite packages if you have a layer where Emacs Lisp is compiled/interpreted as Common Lisp. You can easily hack the readtable in Lisp, and rewrite Emacs Lisp sexps as Common Lisp sexps. Some interesting things to consider are file-local variables, buffer-local variables, dynamic-scope/lexical-scope, how to handle floating point (-0.0e+NaN in Emacs Lisp, custom floating point rouding modes/traps in…
As for compilation to Common Lisp, I don't know how feasible it would be. Apparently they tried something similar with Guile and it ran into problems.
Earlier quoted context omitted.
You don't need to rewrite packages if you have a layer where Emacs Lisp is compiled/interpreted as Common Lisp. You can easily hack the readtable in Lisp, and rewrite Emacs Lisp sexps as Common Lisp sexps. Some interesting things to consider are file-local variables, buffer-local variables, dynamic-scope/lexical-scope, how to handle floating point (-0.0e+NaN in Emacs Lisp, custom floating point rouding modes/traps in…
Emacs contains a quarter million lines of C. What do you do with all the elisp that calls into it? Maybe that could be turned into a "libemacs" and used from FFI.
This implies you have either to convert back and forward everything or you just can't use the native datastructures of the new programming language (making the whole operation often quite pointless).
I must confess that most of the comments in this thread seems to start from the assumption that people working on this in the last two+ decades are probably dumb, and this is sad.
Earlier quoted context omitted.
You don't need to rewrite packages if you have a layer where Emacs Lisp is compiled/interpreted as Common Lisp. You can easily hack the readtable in Lisp, and rewrite Emacs Lisp sexps as Common Lisp sexps. Some interesting things to consider are file-local variables, buffer-local variables, dynamic-scope/lexical-scope, how to handle floating point (-0.0e+NaN in Emacs Lisp, custom floating point rouding modes/traps in…
I would expect that an ELisp interpreter written in Common Lisp would likely be slower than the existing ELisp interpreter written in C. As for compilation to Common Lisp, I don't know how feasible it would be. Apparently they tried something similar with Guile and it ran into problems.
This seems convoluted compared to say moving the Lisp implementation from Emacs Lisp to Common Lisp, of which several native code compiling implementations exists.
Rewriting thousands of packages (some of which have had man-decades of work poured into them) would also be rather convoluted.
Refactor the existing emacs to work headless and become the legacy-core, while also establishing channels to attatch any other core and frontend.