[pro] CDR for UTF* and UNICODE handling in :element-type (Re: write-char vs. 8-bit bytes)

[Pascal J. Bourguignon]

Antoniotti Marco <antoniotti.marco at 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-thing/
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.



-- 
__Pascal Bourguignon__
http://www.informatimago.com/
"Le mercure monte ?  C'est le moment d'acheter !"