On 29/11/2008, at 10:47, Claus Reinke wrote:
But I don't want Perl, I want a well designed language and well
designed libraries.
I think it's find to let libraries proliferate, but at some point you
also need to step back and abstract.
-- Lennart
Especially so if the free marketeers claim there is something
fundamentally wrong with the standard libraries and language, as in
the case of arrays. When someone did that nice little survey of the
last bunch of array libraries (Bulat, I think? now in the wiki
book), I was hoping there would be a grand unification soon.
Instead, it seems that those who have worked most with Haskell
arrays recently have simply abandoned all of the standard array
libraries.
Okay, why not, if there are good reasons. But can't you document
those reasons, for each of your alternative proposals, so that
people have some basis on which to choose (other than who has the
loudest market voice;-)?
I think so far, it's always been the same two reasons: efficiency and
ease of use. H98 arrays are inherently inefficient and IMO not very
easy to use, at least not for the things that I'm doing.
And would it be difficult for you all to agree on a standard API, to
make switching between the alternatives easy (if
it is indeed impossible to unify their advantages in a single library,
the reasons for which should also be documented somewhere)?
Yes, it is very difficult. A sensible API for a standard array library
is something that needs more research. FWIW, I don't know of any other
language that has what I'd like to see in Haskell. C++ probably comes
closest but they have it easy - they don't do fusion.
And what is wrong about Simon's suggestion, to use the standard
array lib APIs on top of your implementations?
Again, IMO H98 arrays are only suitable for a very restricted set of
array algorithms.
Roman
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
