[Openmcl-devel] Re: Standardization, ho!

[Hamilton Link]

> > One thing I would be interested in is a slightly nebulous cooperation
> > between at the very least the "free" implementors; for instance, in the
> > sphere of extensions, it may be that interfaces can sensibly be shared
> > across implementations. As a concrete example of this, consider Unicode
> > support; work is ongoing to add Unicode to CMUCL; SBCL will probably
> > acquire support eventually; Rainer wants support in OpenMCL; CLISP has
> > it already, as do ACL and SCL; we might be able to save ourselves (and
> > our users, if that's a distinct set) some pain if we hash out the issues
> > involved, even if we end up not being 100% compatible in the end...
> >
> 
> A few weeks ago, a colleague and I got ourselves fairly psyched about
> this sort of collaborative effort. I still think that it's a good idea,
> and wonder how best to proceed.
> 
> CLOCC makes some effort to define a portable extension layer; though
> it's probably not as broad as one might like, it seems to me to be
> mostly at about the right depth.  I wonder if some or all of it would
> be a good starting point ?
> 
> I'm certainly interested in exploring this further, and if we get it
> off the ground, to committing time and effort to the process.  I think
> that it's worth remembering that language design is a hard problem, and
> even if we keep our aims fairly conservative it can be a time-consuming
> process (see X3J13 and similar efforts.)
> 
> I think that it would be extremely desirable for implementors to
> commit to providing this "common portability layer" as part of their
> implementations (either builtin to the initial image or easily REQUIREd
> in some fairly standard way.)

Fwiw, I'm the aforementioned colleague. Personally I think it would be
good for not only the open-source lisps to have a set of common APIs for
certain things, but for lisp in general to be able to say we have
standard libraries for XYZ commonly needed modern functionality. From a
world domination point of view, the first step is making standardized
extensions to ANSI CL (in large part making explicit reasonable versions
of the currently-implicit existing semi-standard things) for
portability's sake, the second step is developing "good" public
libraries for data structures and algorithms (MFC-killers and the like).

The spectrum that Gary and I were contemplating for standardization
could be described as "standards committee" vs. "benevolent
dictatorship" (also "slow" vs. "fast"), but in either case people
knowledgable about the impact of decisions on implementations and
language design in general would be needed. 
I have been following some of the development effort of SVN
(http://subversion.tigris.org/), and their development effort can best
be described as a "cabal" -- open to input from the public but mostly a
coordinated effort by a small group of experts. They agreed on a
technical approach initially, picked their allies, and got to work. For
day-to-day things they use a simple voting system on the mailing list to
make some of their decisions when it's appropriate.

If select developers of the lisp world formed a cabal, a sourceforge (or
whatever) project, and a mailing list, that might be a good starting
point, and we (um, they?) could start organizing the effort. There's
APIs to pin down, implementations and compatability layers to write,
maybe a test suite, documentation... anyway it's not a short list; maybe
the *first* thing to do would be to write a manifesto and identify what
APIs should be included and the manner in which applications test for or
get at them, cobble together a consensus evaluating existing starting
points like CLOCC, write a to-do list and a partial ordering thereof...
**wanders away rambling deliriously**

OK, I'm back. I don't want to bog the endeavor down in bureaucracy, but
IMHO a few key people quickly agreeing on a reasonable way of organizing
the effort and setting it up without a lot of debate might let the
project quickly get inertia and lobby key strategic allies (like the
people managing CLOCC for starters -- this project would ideally
assimilate pre-existing efforts and portable things).

hamilton


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel