Antoniotti Marco antoniotti.marco@disco.unimib.it writes:
As good as they are, they are not “specifications”. I.e., I cannot write a separate (as buggy as you want) implementation of them. Neither I can write a separate bordeaux-threads. In fact, as an example, lparallel is just one of the “concurrency” libraries “out there” (cfr., http://www.cliki.net/concurrency).
How many man-years of lisp experts would you fund to quibble over language lawyering vs actually improving those libraries?Language lawyering is not necessarily a bad thing IMHO, moreover, it may lead to better designs and shared knowledge. Your question may be turned around and asked in the following way:
How many man-years of lisp experts have gone into building all the concurrency libraries listed on http://www.cliki.net/concurrency? How many man years should we devote to debating how to choose which one to improve on?
Note that I do not think that those years spent on building concurrency libraries are lost (and I say that from the vantage point of a person who suffers from a severe case of NIH-syndrome :) ), but instead of picking a winner, it may be best at this point to stand back, take a deep breath and maybe produce something that at least a few of the actors can recognize as a good specification. If the specification will be based on the parallel API, hey! more power to it!
Of course this is a general statement that applies, in my intentions, especially to all the dark corners of the ANSI spec before everything else. At least that would be my priority (i.e., the :external-format thingy is just an example).
I think we should be careful to distinguish system libraries providing fundamental services, from framework libraries.
A portability library, such as Bordeaux-threads or Closer-Mop, is mostly a system library, since it provides only a common API for services already provided by the various implementations.
Other libraries, that may seem functionally redundant, are more often in the framework category. They may not be available on all platform or implementations, they may provide a strong structuring to the project.
For those frameworks, you very definitely may want to avoid them and re-invent your own subset framework. Or adopt them and exploit them.
http://codeisbeautiful.org/why-the-not-invented-here-syndrom-is-often-a-good... http://www.joelonsoftware.com/articles/fog0000000007.html
Sometimes, it's more important to know entirely the code of a library or application you've written yourself, to be able to make it evolve swiftly (evolve, not grow), rather than reusing a big framework library with hundreds of dependencies, possibly written in unfamiliar programming styles, where you would spend weeks to find bugs or implement simple changes for the sheer complexity and size of the body of code it represents.
That said, I'm definitely in favor of (sub-)standardizing the API of system-level services. Last century, I even started a cl-posix project to define a Common Lisp POSIX API on sourceforge (which unfortunately has been garbage collected by sourceforge for lack of activity a long time ago). Two years ago, I reported on the behavior of CL implementations on handling logical pathnames on POSIX systems. AFAIK, this hasn't moved implementers to improve the situation, I should have followed up with a CDR to let users require it from implementors with a simple message: please implement CDR-x. I may do that eventually.