The future of Haskell discussion

[S. Alexander Jacobson]

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
>