Re: [Caml-list] Two types of efficiency (Was Efficiency of 'a list)

[John Max Skaller <skaller@ozemail.com.au>]

Yaron M. Minsky wrote:

> You're kidding, right?  You're making a classic "best is enemy of the
> good" mistake here.  


With due respect, there is always the other side of the coin.
What is thought to be "good enough" often enough turns out later
to be ill-considered and a major disaster. Indeed one could
make a hypothesis that this is *necessarily* the case,
since "good enough" really means "we don't really understand
the requirements".

I'm not trying to flame, so much as suggesting that
"when in doubt leave it out" isn't such a bad principle.

As an example: functorial set interface vs. one using
type variables. Well, most of us seem to think
that the type variable interface is more convenient
most of the time.

But before the Ocaml team rushes ahead and provides
it *in addition* to the existing functorial interface,
it might be a good idea to enquire about how the two
are related on a theoretical level. It might be an idea
to devise some principle for deciding which kinds of
interfaces to provide in a library, since the issue is
likely to arise again.

It may even be an idea to figure out if the theoretical
relationship between the two representations can somehow
be connected with language syntax so the transformation
from one kind to the other can be done easily by
a dumb user (like me), obviating the need for
providing an exponential set of interfaces.

The same applies to classes, since some data structures
are mutable enough one wonder why classes weren't used,
since dynamic binding to abstractions seems to provide
some advantages over both type variables and functors
in some circumstances.

As an example: streams. Well, there WAS built in support
for streams, but it was removed -- you can get the code
to work now using camlp4, which is now part of the standard
distribution.

So just maybe strengthening camlp4 is better way forward
then providing built-in syntactic support for more
data structures: rather, it may be better to *eliminate*
existing support, for example, for arrays (by delegating
the job to camlp4).

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
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