3 ms·

Your link 0 is cool, but is fairly different from the new stuff here. Some key differences are that the paper uses a conservative garbage collector (so enjoy ra

Your link 0 is cool, but is fairly different from the new stuff here. Some key differences are that the paper uses a conservative garbage collector (so enjoy random memory leaks) as a way to get around the problems of interop with C. Also, while that paper supports multithreading, as far as I can tell, it meant n-thread to 1 core (i.e. concurrent) multithreading (which is what the term usually referred to before multicore cpus were common), while Julia supports n threads to m cores (see Java's long awaited project Loom) which has a bunch of additional challenges. The last thing to mention is that the paper required a near complete rewrite of the lisp compiler. While that's an option for a simple language like Lisp, it's not as feasible for more complicated languages.

medo-bear 3y ago
Multithreading is handled by C so N-M should be no problem because the key thing is N. If threads are managed from ECL instead then, if available, it will use pthreads [0] ECL is not a rewrite of some THE compiler, it is a whole implementation. This actually goes toward your point that Julia cant do this because the language is not seperate from its compiler, but it is not because julia is more complicated than common lisp Common Lisp has been called many things, rarely simple. Its spec is over 1000 pages [0] https://ecl.common-lisp.dev/static/manual/Native-threads.html#Native-threads https://ecl.common-lisp.dev/static/manual/Native-threads.htm...