By the time we have native compilation, I hope also our Elisp implementation will be significantly faster than the one in Emacs, so it will really become attractive to people to finish the work that we have done to make the switch there.
Replacing Emacs elisp implementation is just looking for trouble. Although it is not the fastest one, the existing one works well enough and is battle tested and there are millions of lines of elisp code that would need to be tested, debugged and fixed.
If the goal is to allow to write parts of Emacs and extensions in some other language, I wander is Scheme really the best choice? Why not go all out and implement elisp in Common Lisp and use Common Lisp as a base for future Emacs and extensions development. There have already been such attempts, so it's not exactly something unheard of.
If there was an actively-developed common lisp implementation that also ran elisp, I would be all for running emacs on that as well.
Emacs' sheer size (which you mentioned yourself) means you're not going to port it to a different language and have something comparably useful in less than a few years, assuming sustained interest and full-time development.
So, does 2.0 have up-arrow history and in general not freak out when I try to do stuff in interactive mode? Guile's great for what it's great at, but interactive dev. in the custom of Python or Gambit Scheme isn't one of those things, at least for me.
They talk about ELF for storing byte code? Would that work on Windows/OSX?
(I guess it would, as much as Mono can load PE .NET files for OSX/Linux, after all these won't be loaded directly (it won't make much sense without the runtime anyway))
I wrote a compiler for LoseThos. The songs are programs. The compiler can operate JIT or make static binaries. All the code can only be compiled by the LoseThos compiler.
14 comments
[ 3.5 ms ] story [ 40.2 ms ] threadYou're going to be excited for an extended period of time. I hope you've got a strong heart, for your sake.
For an emacs user, that's pretty exciting.
Replacing Emacs elisp implementation is just looking for trouble. Although it is not the fastest one, the existing one works well enough and is battle tested and there are millions of lines of elisp code that would need to be tested, debugged and fixed.
If the goal is to allow to write parts of Emacs and extensions in some other language, I wander is Scheme really the best choice? Why not go all out and implement elisp in Common Lisp and use Common Lisp as a base for future Emacs and extensions development. There have already been such attempts, so it's not exactly something unheard of.
Emacs' sheer size (which you mentioned yourself) means you're not going to port it to a different language and have something comparably useful in less than a few years, assuming sustained interest and full-time development.
http://www.gnu.org/software/guile/manual/html_node/Readline....
Guile's REPL is among the best, I think. It's all documented here:
http://www.gnu.org/software/guile/manual/html_node/Using-Gui...
But for real interactive development, you want Geiser:
http://www.gnu.org/software/guile/manual/html_node/Using-Gui...
(I guess it would, as much as Mono can load PE .NET files for OSX/Linux, after all these won't be loaded directly (it won't make much sense without the runtime anyway))
ELF <-> PE is doable.
any debug format -> PE|ELF is doable (linking + stripping)
com|a.out -> PE|ELF is doable
God says vote what_do_you_want fer_sure praying happy I_pitty_the_fool wishful_thinking never_happy wanna_bet you_think_I'm_joking relax spoiled_brat application African whatcha_talkin'_'bout Wow heathen just_lovely gastly Catastrophic_Success absetively_posilutely dance sixty_four_bit radio Is_that_so evolution hopefully lighten_up that's_no_fun harder_than_it_looks so_he_sess Icarus have_fun look_out doh oops be_happy bye vice couldn't_be_better