I don't know that it is possible for Haskell98 to have industrial strength libraries (even if the authors wanted to finish and support them). * Library namespace issues are not resolved There is no guarantee that a library with a given name will not conflict with another library of the same name. There have been various discussions of creating nested namespaces but they are not part of Haskell98. Without a clean namespace, libraries cannot rely on and integrate with each other. (Note: the related issue of library version management also needs some resolution). * Parametrized libraries There have been various discussions of importing libraries in ways that allow the importer to control which types and classes the library actually uses. I think this issue may have been dropped but it creates some uncertainty for library authors w/r/t firming up library structure. * Library interfaces This is going more over my head. But I believe that there is an issue of choosing a standard library interface. If I understant things correctly, whether a library interface is a Monad (and which monad) or an Arrow (and which arrow) or an X substantially constraints what libraries can be used with it. It is perhaps the case, that these constraints lighten considerably in the presence of existential types (or fundeps?) and that Arrows are more viable in the presence of Proc syntactic sugar, but none of these are part of Haskell98 even if they are really likely to be part of Haskell2. Unless I am wrong about all of the above, it seems more important to converge Haskell to a language that can support industrial strength libraries and that is Haskell2 rather than Haskell98. -Alex- ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm) On Sun, 16 Sep 2001, Bill Halchin wrote:
Jeff has hit the nail on the head .. thanks Jeff. You said eloquently what I was hinting at
or saying very implicit (because I didn't know how to say it eloquently). The "Haskell
library" seems to be contributions by individuals (who should be commended!!), but as
an "industrial" programmer who writes in imperative languages everyday (and sees
them as many times getting in the way, e.g. C++, and not modeling a particular
problem very elegantly!), with Haskell I would like to see a library API part of the
Haskell Report, i.e. a nice list of type signatures by topic, e.g. numeric. (maybe this
is already the situation ... I unfortunately have not had a lot of chance to write
Haskel code even though I like FPL's and Haskell in particular). The haskell library API
should be part of the Haskell standard just as the standard C library is part of the
ANSI C standard!
Regards, Bill Halchin
From: Jeffrey Palmer To: haskell@haskell.org Subject: Re: The future of Haskell discussion Date: 14 Sep 2001 17:06:49 -0500
On Fri, 2001-09-14 at 15:12, Mark Carroll wrote:
On Fri, 14 Sep 2001, Bill Halchin wrote:
Probably this question has been brought before. Besides the Preludes, why doesn't
Haskell have libraries like Java, Squeak (Smalltalk). I found this: (snip)
I'm puzzled - it does! - see http://www.haskell.org/libraries/ for some of them.
I think the question is more along the lines of "Why doesn't Haskell come bundled with complete, useful and _supported_ libraries?"
For example, the Edison home page describes the library in this way:
"in its current state, the library is mostly a framework. That is, I provide signatures, but not yet very many implementations..."
This is not the type of thing that your standard software engineer wants to hear. Professional software developers need to be highly productive, and are often unwilling to invest time learning libraries that aren't part of the core language environment. However you feel about the design of the Java Collections API, at least it's a supported part of the language. Developers feel comfortable that any time spent learning the how to use these APIs is worthwhile.
I felt this very recently when looking for a quality GUI framework for Haskell. There appear to be many(!) libraries available, and all seem to be in various states of completion. Personally, I would like to see someone complete the port of the Clean library that was attempted, as that library seems to have been pretty battle-tested, and there are lots of good, real-world examples.
That, I suppose, is the key point. Whatever libraries are chosen for final inclusion in the Haskell environment, they should be treated as integral to the language experience. Extensive documentation and examples should exist, perhaps of book length (I really liked Hudak's text for this reason, and only wish that it had been written with the "standard" Haskell GUI libs). Finally, any libraries should be beaten upon to such an extent that there is a solid guarantee that they are "safe" for production use.
Thoughts?
- j
-- Jeffrey Palmer Curious Networks, Inc. http://www.curiousnetworks.com e: jeff@curiousnetworks.com
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
__________________________________________________________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell