On Apr 12, 2014, at 24:37 , Faré <fahree-***@public.gmane.org<mailto:fahree-***@public.gmane.orgm>> wrote:
I am aware of all the things ³out there², and yet, having a number of
libraries or even a single library is not the same as ³having a standard².
If there were a single open-source go-to library, and it were stable,
that would be a *de facto* standard that you could then codify.
But then, the advantages of the codification would be dubious,
since you already have the library, and all the codification creates
is opportunity for divergently buggy reimplementations.
Yes. But if a consensus is there about the meaning of a particular API there will be something to discuss about.
IETF requires two independent interoperating implementations
before it declares a standard adopted. What does interoperating means here?
The two libraries must use the same package? That's conflict.
Different packages but the same symbol names? That's not interoperation.
There's no way to win this standardization game.
There are several point of view about who wins and who loses.
About the request for two different interoperable implementations, you could, in principle, deal with it at the package level, thanks to the nickname facility (well, it would work better if it were more standardized :) ).
If you can't convince the community to choose between babel and
cl-unicode and whichever other alternatives may exist, what makes you
think you can get yet another incompatible standard widely adopted?
https://xkcd.com/927/
I am not advocating the proverbial 15th incompatible standard. Since by
now people should know what they are doing, it would be nicer to have a
document that summarized things up. Didn¹t the ANSI spec essentially came
about in that way?
CL was standardized by trying to compromise between existing implementations;
that was both its success (starting from something that exists, and
making it converge a bit)
and its limitation (with the horrible practice of underspecified
functionality, which creates
as many portability land mines).
Yes. Exaclty. And moping up these land mines is not something that can be done at the library level alone.
If you want to restart a similar process, good luck trying to put the
developers of these implementations on the same mailing-list:
maintained: abcl allegro ccl clisp cmucl lispworks mkcl sbcl
semi-maintained: ecl gcl scl
in development: clasp mocl sacla
unmaintained: corman genera mcl xcl
I am in no position to restart" a similar process. I am posting here because this is where - I believe - most people interested in such things may be listening. If the thing gets restarted, good. If not, it will not hurt me individually.
Back in the days, there was were big customers and the threat of
reduced DARPA funding that put everyone in the same room. No such
incentive today.
Yes. But this argument has been circulated many times before, as I said. Maybe some collaborative effort can be put together nevertheless.
PS: all implementations that accept unicode accept :external-format
:utf-8... except clisp, that requires you to use 'charset:utf-8. If
you want to work towards a common external-format, start here
I said ³any takers?². I am just the customer telling the market what it
would be nice to have :) and that is the reason why I will not build the
15th ³standard² (or the next library external encoding library). The
question I am posing to the authors of the libraries you mentioned is why
they don¹t sit down and write such a summary collaborative document and
agree on a common interface. Of course the usual responses may be put
forth (time, money or both) so my request may be moot. I am aware of
that. And yet, why not asking?
Well, given enough million dollars, I'm sure you can convince people
to sit in the same room. Not that I would recommend that as a good
investment.
Nobody has million of dollars for such a thing. We all know that (although Google may pour a couple of million into it, hint, hint :) :) ).
P.S. Networking anybody? Multiprocessing?
iolib? lparallel?
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).
Cheers
MA
