Comment by chlorion | Hacker News Reader

Comment by chlorion | Hacker News Reader

Parent Full thread

That's a very good question and the same thing I ask myself whenever I consider using some lisp (for hobby purposes mostly).

I came to the conclusion that scheme is a better language from a technical standpoint and I enjoy using it more, but the primary issue is that lisp is already sort of niche, and scheme is like a niche inside of a niche, which in practice results in the "ecosystem" being very weak.

By ecosystem, I mean how much activity there is on the implementations, but moreso the available libraries and the quality of the available libraries!

An example of the ecosystem thing would be elisp. elisp has a ton of libraries available, there "s.el" for string manipulation, dash for lists, "f.el" for files and paths, "ht" for hashtables, and a lot more. Vanilla Emacs comes with around 5 million lines worth of Elisp OOTB too, this includes stuff like regex, a custom sexpr based regex DSL called "rx", json and xml parsers, sqlite bindings, etc. Very rarely do I feel like I'm missing something in elisp, with the exception of concurrency support!

When I used scheme, I was not able to find alternatives to many of these things and felt pretty limited. Schemes do tend to have better "native" support for some things like list manipulation, so it's at least usable without something like dash.

Anyways, Guile scheme seems like the most usable scheme to me right now and gets a bit of attention thanks to guix, but I think common lisp gets a bit more attention right now, and neither can compare to something like ruby or python sadly! So this could be one reason one might prefer common lisp over scheme I guess.

So for me personally, common lisp feels too old and clunky to comfortably use, scheme is nice but lacks support in a lot of areas, so in practice I end up not using either of them. I have yet to try racket though and it looks like it addresses most of my issues.

> Very rarely do I feel like I'm missing something in elisp, with the exception of concurrency support!

I have some good news for you, then! Cooperative threading was added in Emacs 26:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...

https://www.emacswiki.org/emacs/NoThreading

I've never used it, but the big disadvantage seems to be that unless you're going to do some super advanced macrology, any function you run within a thread needs to explicitly call `thread-yield` in order to yield back to the scheduler so other threads can run. I don't know of any library or anything that makes it so you can just take a function that isn't thread-aware, run it concurrently with other possibly not thread-aware functions, and have it all work sensibly, but at least the building blocks are there.

---

If that doesn't suit you, Emacs 25 introduced generators!

https://www.gnu.org/software/emacs/manual/html_node/elisp/Ge...

Generators have some funky interactions with `unwind-protect`, so handle with care.

---

Finally, there's also a (really old and probably won't work as is anymore, but also probably fun to poke at) coroutine library available:

https://www.emacswiki.org/emacs/CoRoutines

---

I'm sure one of those (probably emacs threads) will meet your needs nicely. :)

Didn't emacs add actual support for OS threads recentishly?

Not to my knowledge. Apparently, according to https://www.emacswiki.org/emacs/NoThreading, dynamic scope makes it devilishly difficult to implement os-level threading. It is, apparently, possible to automatically translate elisp into a lexically scoped lisp dialect, and rebuilt emacs on that foundation, but, again, to my knowledge, nobody's done that. And, there are occasional mutterings about making a new, natively multithreaded emacs, but nothing's ever made it into the GNU emacs repo, AFAIK.

It does have process-based concurrency, which is basically where you spawn off a whole new emacs, then run your code within that. I've never used it, so I don't know how it works, other than the obvious disadvantage of having a large startup time and potentially memory use to start up another instance of emacs.

You are indeed right. I had understood that actual preemptive threads had been added, but it seems that for now it is still cooperative and requires explicit yields.

Note that elisp has lexical scoping now, but it will be years of course before all packages will have been updated (and for many things you still want dynamic scoping).

You might want to check out Racket. It's not immediately obvious that it's a Scheme, but it has a much more vast ecosystem of libraries than any other Scheme I know of.

Racket is no longer called PLT-Scheme because its not a Scheme, though it includes some and is still closely related.

What about Racket makes it not a Scheme?

Here’s the piece they wrote explaining the decision to rename:

https://racket-lang.org/new-name.html

Racket qua Racket (and PLT Scheme before the rename) didn't conform to any of the existing Scheme specs (it was something like R5RS minus some things it didn’t like, plus some things from R6RS, plus a whole bunch of its own stuff.)

After looking at the Racket website, from the POV of someone who wants to use or learn Scheme, that doesn't sound like a useful distinction. They have R5RS and R6RS implementations that look to have reasonable conformance with the corresponding standards. I don't see how the fact that the language called "Racket," which is a lispy language that implements (among other things) R5RS, R6RS, and mzscheme even matters. It sounds an awful lot like like saying "foo-scheme isn't a scheme because it's implemented partly in C."

Reply on news.ycombinator.com