4 ms·
The 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.asyn
by Blackthorn 3y ago
The 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/