Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] [ANN] The Missing Library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] [ANN] The Missing Library
On Sun, 2004-04-25 at 21:50, Benjamin Geer wrote:
> Are you joking?  Have you ever tried to write a program using several 
> mutually incompatible libraries?
> 
> Before C++ had STL, everyone wrote their own string class.  Surely you 
> can imagine the resulting contortions when libraries with different 
> string classes had to be used together.  

I was an active member of the C++ committee at that time.

There was a set of classes in the Working Draft. 
A string class, IOstreams, some other things.
All independently designed and voted on.

It was a mess. A Standard string class. Better than no 
Standard. Then Alex Stepanov gave a brief talk on a library
being developing at HP, based on an older Ada library.

The ideas were new (to the C++ committee). But there was
a coherent design, and stated design *principles* based
on mathematics, built by researchers.

Almost the *whole* Standard C++ library was overturned
at the next meeting in a single vote in favour of STL,
and what wasn't thrown out completely was modified to
conform to the container-iterator-algorithm framework.

Changes in the C++ language itself were then almost
exclusively driven by the requirements of STL,
partial specialisations in particular.

The committee actually did a very good job firming
up the details, discarding non-essential components,
and writing detailed specifications -- although
they made a few very serious mistakes, developing
allocators being the worst disaster (they should have
been thrown out completely).

The result is, in my opinion, the best CS library
EVER built. Its just a pity the C++ language doesn't
have what it takes to drive it (lexical scoping 
like ML has).

My conclusion from this process is: a loose community
is no more capable of designing a coherent library
than a high level programming language. A small high
power research team is needed for that.

But a small research team is just as incapable of
industrialising a library: filling out the details,
following the principles layed down, enriching
and refining, testing and debating. That requires
a larger community.

A brief note on the theory behind STL: we don't 
understand it. I have an inkling. STL does two things
that you can't do in Ocaml.

(1) It provides functorial polymorphism.
Iterators generalise over data structures
themselves, not merely their value type.

(2) Iterators provide control inversion.
Compare the functional 'iter' and 'map'
like HOF's of Ocaml, where the user 
supplies a callback, with the control inverted 
algorithms of STL, which use iterators to 
demand the data.

I'm not criticizing Ocaml or it's library here,
rather I'm making a point about process.
The Ocaml library is a loose collection
of things, like the C++ library before STL came along.
Turning the Ocaml library over to the community before
the reseachers have a coherent design will be a disaster.

Holding onto it afterwards will be too.

IMHO: the Ocaml team is doing the right thing.
The Standard library is being kept small, being
upgraded slowly, whilst the main emphasis is
where it needs to be to support a new, coherent,
library design.

The type system.

I think it's time to say thanks for the good work!
Keep it up! .. and to ask: how can we help better?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners