Sometimes I worry that software, because you can do this, also let's you do similarly bizarre things obfuscated under a layer of complexity.
Imagine a car company announcing they'd built a perfectly cuboidal car entirely out of (say) tungsten — it only does 3mph and is expensive but we value engineering time over performance!
An operating system inside a text editor inside an operating system maybe inside a vm inside another operating system. Wait I forgot nested virtualization.
Cool. Why, though? I mean, it's not like this project has any practical value anyway, but wouldn't it be actually easier and more efficient to actually implement a C compiler in VimScript? Or is the vimscript ELVM backend the actual end-goal here, and C-compiler at question is basically just a proof that it works?
Thanks, at first I thought someone had written it in vim script, then I inspected the README in detail and learned it's only transpiled from C to vim script, which is not particularly exciting or impressive compared to a human wielding such a degree of vim script fu.
I wonder how much faster a manually written C compiler in Vim script would be.
The current code is essentially assembly instructions running as Vim script, this gotta be incredibly slow, probably not much faster than an x86 emulator written in Vim script:
Funny because neovim supports LuaJIT for it's lua init files by default. I wonder if there would be a way to compile vimscript to lua and have it everything inside the lua IR. Probably very hard, given the DSL nature of vimscript
This was tried by ZyX-I when the Neovim project was started. AFAIK they managed to create an alternative parser for Vimscript, but the transpiler was never finished (or productionized?), I think due to incompatibilities that are hard to avoid. Some relevant issues:
The difference is, that with Vim script it will either happen unexpectedly or unexplicably, while in Elisp it will/might happen later, but will be in the realm of understandable things.
Back in the 1970s, I was told that somebody had written a FORTRAN compiler as a TECO macro just to prove it could be done.
(TECO means Text Editor Charactor Oriented, a line editor that had a macro capability. EDLIN was a line editor for MS-DOS.)
Sometimes I worry that software, because you can do this, also let's you do similarly bizarre things obfuscated under a layer of complexity.
Imagine a car company announcing they'd built a perfectly cuboidal car entirely out of (say) tungsten — it only does 3mph and is expensive but we value engineering time over performance!
Can you use the ELVM backend to compile Emacs into Vim script?
An operating system inside a text editor inside an operating system maybe inside a vm inside another operating system. Wait I forgot nested virtualization.
It looks like they're just taking the entire eightcc compiler and stuffed into vim buffer memory.
No. It is a C compiler compiled to Vim script. So it is actually a C compiler written in Vim script.
I think a more accurate way to describe it is that it's a C compiler written in C and then automatically transpiled to VimScript.
No human hand-authored this giant pile of VimScript: https://raw.githubusercontent.com/rhysd/8cc.vim/master/autol...
Yes. It is compiled to Vim script using ELVM[1]. Though the author of Vim script backend of ELVM is me :)
[1]: https://github.com/shinh/elvm
That is very cool! So with ELVM one could put together a C compiler in TeX too? Or transpile Vim into Vim script to self-host it?
Cool. Why, though? I mean, it's not like this project has any practical value anyway, but wouldn't it be actually easier and more efficient to actually implement a C compiler in VimScript? Or is the vimscript ELVM backend the actual end-goal here, and C-compiler at question is basically just a proof that it works?
Thanks, at first I thought someone had written it in vim script, then I inspected the README in detail and learned it's only transpiled from C to vim script, which is not particularly exciting or impressive compared to a human wielding such a degree of vim script fu.
Ah - my impression went from 'this is pure masochism' to just 'this is slightly insane'.
I wonder how much faster a manually written C compiler in Vim script would be.
The current code is essentially assembly instructions running as Vim script, this gotta be incredibly slow, probably not much faster than an x86 emulator written in Vim script:
https://raw.githubusercontent.com/rhysd/8cc.vim/master/autol...
Time for JIT-compiled vimscript, I guess? Why should Javascript have all the fun.
Funny because neovim supports LuaJIT for it's lua init files by default. I wonder if there would be a way to compile vimscript to lua and have it everything inside the lua IR. Probably very hard, given the DSL nature of vimscript
This was tried by ZyX-I when the Neovim project was started. AFAIK they managed to create an alternative parser for Vimscript, but the transpiler was never finished (or productionized?), I think due to incompatibilities that are hard to avoid. Some relevant issues:
- https://github.com/neovim/neovim/issues/170
- https://github.com/neovim/neovim/issues/387
- https://github.com/neovim/neovim/issues/392
- https://github.com/neovim/neovim/issues/801
Vim9script is already compiled (which is why it’s much faster), so there’s no need to go via Lua if you’re on ”normal” Vim :)
I wonder how much faster it would be if it was written in Vim9 script.
There's only one way to find out, bubba! You're gonna have to write an x86 emulator in vimscript for us, and tell us how it compares...
I'd love to use vim to compile vim lolz
I always suspected Emacs would achieve sentience before vim. Maybe I'll be wrong.
The difference is, that with Vim script it will either happen unexpectedly or unexplicably, while in Elisp it will/might happen later, but will be in the realm of understandable things.
Just keep adding closing parenthesis to the end of the file. Eventually Emacs will greet you in HAL 9000 style.
Checkmate, athiests.