Hans Hübner hans.huebner@gmail.com writes:
Parallelism is something that requires proper abstractions. Some say that these can be just on the library level, but my experience tells me a different story. I find it difficult to create robust parallel solutions in languages like Lisp, as the language itself assumes a single thread of control in how it makes variable bindings accessible and how information is passed between invocations of functions by reference.
If "how information is passed between invocations of functions by reference" is the problem, then it sounds like you really do not want a Lisp, but Lisp Flavoured Erlang.
You have to ask: is parallelism the problem, or concurrency?
Good approaches to parallelism have already been worked out for Lisp a long time ago: Connection Machine Lisp, *Lisp, Paralations, NESL. What is not here now is an implementation of any of those for GPUs.
Kelly Murray worked on a multi-processor Common Lisp (Top Level Common Lisp) in the late 1980s/early 1990s, and I think his opinion about Common Lisp is still true today:
"This is one reason why I believed Common Lisp was good for multiprocessing, since you can use macros to create new higher-level parallel constructs, which is not possible with C/C++. Stuff like parallel-do's and parallel-maps, and sequence operations can be macros that expand into "low-level" code."
-- Vladimir Sedach Software engineering services in Los Angeles https://oneofus.la