[EMAIL PROTECTED] (William Harold Newman) writes: > Still, though, sometimes useful things resist elegant implementation > in CL. For example: > * I doubt CL can be customized to support a thread library nearly > as gracefully as languages designed around threading from the > ground up.
All CL implementations I know of have some kind of thread support. Some have only green threads, some have native threads with an internal big lock but AFAIK at least Corman Lisp and SBCL have real native threads without an internal big lock. Threre are also quite some libraries around (for Erlang like distributed multiprocessing and some multithreading libraries that hide the different vendor APIs). Although the ANSI Common Lisp standard says nothing about threads all vendors seem to use the same semantics (i.e. for handling of special variables in the context of multiple threads). I'm not a big multitheading fan but I would say there is quite some good support in Common Lisp for threads. > * For complicated code where a very expressive static type > system for higher order functions is a good fit Not for me. :) I would say that strict static typing in the sense of the ML family of languages (especially Haskell) is a question of personal preference. These languages favour a completly different style of development than languages of the Lisp family. If you are a static type, you will never be really happy with CL. If you are a dynamic type you will never be really happy with Haskell. If you are in between, use both. :) -- Until the next mail..., Stefan.
pgpCSGhYfDzDp.pgp
Description: PGP signature
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
