5 ms·

For anyone interested in guile, guile 3.0 will have a JIT, making it even faster than 2.2 (by quite a large margin). Guile is becoming really nice, and I find

by bjoli 8y ago

For anyone interested in guile, guile 3.0 will have a JIT, making it even faster than 2.2 (by quite a large margin). Guile is becoming really nice, and I find myself reaching for other lisps less and less.

logicchains 8y ago
How far along is it towards becoming the underlying runtime for Emacs lisp?
- bjoli 8y ago
  With the bikeshedding we see for much less controversial changes in the Emacs codebase, I suspect it will be released around the release of Duke Nukem forever II. Elisp code runs fine under guile, but it has seen virtually no optimisation work and does a lot of unnecessary work. I suspect there is an lot of low hanging fruit, but since there is virtually no interest in guile-emacs apart from in comments on HN and Reddit I doubt the situation will get much better. The guile VM is getting better and better though. Maybe they'll come around by guile 4 :)
  - yepguy 8y ago
    I've always thought someone should use guile to add support for elisp plugins to vim & neovim using their rpc interfaces. Then maybe if something like that existed the org-mode authors could be convinced to cleanly separate out the emacs-specific code, and we could have org-mode on vim using the same codebase as emacs. I have no idea how viable that is, but it would be pretty sweet. Too much for me to take on right now, but the idea has been rattling around my brain for a few years.
- equalunique 8y ago
  https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs
zeveb 8y ago
Scheme is a neat little language, but it's really not ideal for writing full software systems. Indeed, Guile & Racket (back when it was PLT Scheme) are perfect exemplars of Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. E.g. GOOPS is similar to CLOS, but missing a bit and unsupported other than in Guile. Meanwhile, implementations like SBCL are free, compile to machine code and are competitive on some benchmarks with C/C++. Common Lisp — while it does have some warts — is intended for building long-lived, durable, full-featured systems. It's a really good language, and it standardises quite a lot. Often, what look like warts are actually useful features in large systems. It really saddens me that so much effort has been expended trying to make Scheme a reasonable language for large systems, when there already exists one which is. That doesn't even get to the bits of Scheme which I believe are mistakes (e.g. a single namespace, making NIL, () & #f different).
- bjoli 8y ago
  I find many common lisp users' attitude towards scheme condescending. It is as if we are completely oblivious to the CL ecosystem or outright stupid to prefer something else. I assure you, we look in envy at CL and what a standardised module system, portable networking and CFFI achieves. However, we still prefer scheme. Some of us actually like a single namespace, and don't mind the difference between false and nil (I have never really met a case where that distinction mattered much).
  - zeveb 8y ago
    > I find many common lisp users' attitude towards scheme condescending. Are you familiar with the Blub Paradox[0]? I contend that the things you dislike about Common Lisp or don't mind about Scheme having or not having are precisely the things which make Lisp better for real-world systems. My opinion — a professional, educated & considered opinion, but an opinion nonetheless — is that Scheme is simply not suitable for large-systems work, and that all attempts to take a Scheme core and make it suitable founder on the shoals of Greenspun's Tenth. The Scheme maintainers agree, because in R6RS they tried to build a more capable language. The Scheme community agrees, because it rebelled against R5RS, deeming a more capable Scheme an un-Scheme-like Scheme. I like Scheme. It's a pretty, elegant language, with an exciting model. But the language as it exists simply isn't ready for systems work, and (due to its underlying philosophy) probably never will be. That's not a bad thing. Scheme is great for what it is. It's great for teaching; great for reasoning about computation; great for learning evaluators & compilers. But it isn't great for building systems like an OS, emacs, a distribution, a package manager, an init system or a window manager — and the effort spent working on making its inadequacies tolerable could instead be spent on implementing features in a more-than-adequate language. Also, Lisp doesn't have portable networking. That's one of its warts (I did say it has them — and plenty of them! Lisp is not perfect!). It does have portable streams (and I think all implementations make sockets available as streams), but Scheme's ports are analogous. Neither is CFFI standarised. 0: http://paulgraham.com/avg.html http://paulgraham.com/avg.html
civodul 8y ago
Guile 3 is truly exciting indeed. See the latest news at https://lists.gnu.org/archive/html/guile-devel/2018-09/msg00018.html https://lists.gnu.org/archive/html/guile-devel/2018-09/msg00... .
pjmlp 8y ago
Are there any plans to support AOT as well?
- bjoli 8y ago
  Yeah. Well, guile already does AOT, but not to native code. Now it compiles to guile bytecode that is then jitted. The plan is to use the JIT as a first step to do AOT compilation to native code and thus come a bit closer to the speed of chez. Hopefully quite a bit closer. This is what I have gathered from Andy Wingo's mailing list posts, so grains of salt for everyone!
xfer 8y ago
How good is the concurrency support? a lot of schemes have poor support for it(basically roll your own via libev), except racket.
- bjoli 8y ago
  Pthreads and guile-fibers (a parallel concurrent ML implementation). If you never used CML you should try it out.
agumonkey 8y ago
who's working on guile 3.0 ? I thought wingo was too employed~ :) ps: well I was wrong, it's wingo as usual https://news.ycombinator.com/item?id=18077710 https://news.ycombinator.com/item?id=18077710

by bjoli 8y ago

logicchains 8y ago

How far along is it towards becoming the underlying runtime for Emacs lisp?

bjoli 8y ago
With the bikeshedding we see for much less controversial changes in the Emacs codebase, I suspect it will be released around the release of Duke Nukem forever II. Elisp code runs fine under guile, but it has seen virtually no optimisation work and does a lot of unnecessary work. I suspect there is an lot of low hanging fruit, but since there is virtually no interest in guile-emacs apart from in comments on HN and Reddit I doubt the situation will get much better. The guile VM is getting better and better though. Maybe they'll come around by guile 4 :)
- yepguy 8y ago
  I've always thought someone should use guile to add support for elisp plugins to vim & neovim using their rpc interfaces. Then maybe if something like that existed the org-mode authors could be convinced to cleanly separate out the emacs-specific code, and we could have org-mode on vim using the same codebase as emacs. I have no idea how viable that is, but it would be pretty sweet. Too much for me to take on right now, but the idea has been rattling around my brain for a few years.
equalunique 8y ago
https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs

zeveb 8y ago

Scheme is a neat little language, but it's really not ideal for writing full software systems. Indeed, Guile & Racket (back when it was PLT Scheme) are perfect exemplars of Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. E.g. GOOPS is similar to CLOS, but missing a bit and unsupported other than in Guile. Meanwhile, implementations like SBCL are free, compile to machine code and are competitive on some benchmarks with C/C++. Common Lisp — while it does have some warts — is intended for building long-lived, durable, full-featured systems. It's a really good language, and it standardises quite a lot. Often, what look like warts are actually useful features in large systems. It really saddens me that so much effort has been expended trying to make Scheme a reasonable language for large systems, when there already exists one which is. That doesn't even get to the bits of Scheme which I believe are mistakes (e.g. a single namespace, making NIL, () & #f different).

bjoli 8y ago
I find many common lisp users' attitude towards scheme condescending. It is as if we are completely oblivious to the CL ecosystem or outright stupid to prefer something else. I assure you, we look in envy at CL and what a standardised module system, portable networking and CFFI achieves. However, we still prefer scheme. Some of us actually like a single namespace, and don't mind the difference between false and nil (I have never really met a case where that distinction mattered much).
- zeveb 8y ago
  > I find many common lisp users' attitude towards scheme condescending. Are you familiar with the Blub Paradox[0]? I contend that the things you dislike about Common Lisp or don't mind about Scheme having or not having are precisely the things which make Lisp better for real-world systems. My opinion — a professional, educated & considered opinion, but an opinion nonetheless — is that Scheme is simply not suitable for large-systems work, and that all attempts to take a Scheme core and make it suitable founder on the shoals of Greenspun's Tenth. The Scheme maintainers agree, because in R6RS they tried to build a more capable language. The Scheme community agrees, because it rebelled against R5RS, deeming a more capable Scheme an un-Scheme-like Scheme. I like Scheme. It's a pretty, elegant language, with an exciting model. But the language as it exists simply isn't ready for systems work, and (due to its underlying philosophy) probably never will be. That's not a bad thing. Scheme is great for what it is. It's great for teaching; great for reasoning about computation; great for learning evaluators & compilers. But it isn't great for building systems like an OS, emacs, a distribution, a package manager, an init system or a window manager — and the effort spent working on making its inadequacies tolerable could instead be spent on implementing features in a more-than-adequate language. Also, Lisp doesn't have portable networking. That's one of its warts (I did say it has them — and plenty of them! Lisp is not perfect!). It does have portable streams (and I think all implementations make sockets available as streams), but Scheme's ports are analogous. Neither is CFFI standarised. 0: http://paulgraham.com/avg.html http://paulgraham.com/avg.html

civodul 8y ago

Guile 3 is truly exciting indeed. See the latest news at https://lists.gnu.org/archive/html/guile-devel/2018-09/msg00018.html https://lists.gnu.org/archive/html/guile-devel/2018-09/msg00... .

pjmlp 8y ago

Are there any plans to support AOT as well?

bjoli 8y ago
Yeah. Well, guile already does AOT, but not to native code. Now it compiles to guile bytecode that is then jitted. The plan is to use the JIT as a first step to do AOT compilation to native code and thus come a bit closer to the speed of chez. Hopefully quite a bit closer. This is what I have gathered from Andy Wingo's mailing list posts, so grains of salt for everyone!

xfer 8y ago

How good is the concurrency support? a lot of schemes have poor support for it(basically roll your own via libev), except racket.

bjoli 8y ago
Pthreads and guile-fibers (a parallel concurrent ML implementation). If you never used CML you should try it out.

agumonkey 8y ago

who's working on guile 3.0 ? I thought wingo was too employed~ :) ps: well I was wrong, it's wingo as usual https://news.ycombinator.com/item?id=18077710 https://news.ycombinator.com/item?id=18077710