4 ms·
https://github.com/CodyReichert/awesome-cl#parallelism-and-concurrency https://github.com/CodyReichert/awesome-cl#parallelism-and-c... https://github.com/theze
by medo-bear 3y ago
https://github.com/CodyReichert/awesome-cl#parallelism-and-concurrency https://github.com/CodyReichert/awesome-cl#parallelism-and-c...
https://github.com/thezerobit/green-threads https://github.com/thezerobit/green-threads
edit:
static typing
https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton
- pdimitar 3y agoThanks, that looks promising. Will check out some of the links.
- Blackthorn 3y agoThe first two links, when it comes to green threads, have nothing that fit the bill. They are not transparent. They have all the problems of clojure's core.async. What you need is to be able to call existing blocking code and have the runtime take care of it. A macro based solution cannot do this, because macros are purely source to source transforms. If it can't access the source, it can't modify it. It must be done by the runtime.
- medo-bear 3y ago> They are not transparent what does this mean?
- Blackthorn 3y agoI mean "can it call blocking code without bringing everything to a screeching halt".
- medo-bear 3y agohonnest question, can rust? i very much doubt that there is anything in lisp that can prevent that from being implemented at a library level (library because lisp is ANSI standardized). if you can prove that lisp is inherently unable to do what you call transparent threads im pretty sure it would be a significant cs journal paper anyway it seems to me that this discussion evolved from lisp doesnt support multicore/ concurrency/parallelism (false) to "lisp aint erlang" (truism) if you want erlang just use erlang, or a lisp version of it https://lfe.io/ https://lfe.io/