FYI, there are multiple python implementations out there. See http://starbase.neosoft.com/~claird/comp.lang.python/python_varieties.html Of particular note here is Vyper implemented in OCAML, which adds tail calls, list comprehensions, lexical scoping, full garbage collection, and pattern matching to Python... -Alex- ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm) On Mon, 2 Apr 2001, Julian Seward (Intl Vendor) wrote:

S. Alexander Jacobsen wrote:

| Although I think Haskell is a beautiful language, Jelovic is right on his | core points, Haskell implementations don't meet the needs of | the working programmer. [...]

I also largely agree with Jelovic, and I take what he says as constructive criticism.

One observation at least as regards Perl and Python is that Haskell has a very much more academically-intense heritage, whereas Perl and (guessing here) Python were motivated more by end-user need. GHC and Hugs suffer from tensions between being research vehicles and being practical implementations suitable for end-users. I'd guess that Perl and Python don't suffer from such tensions, so their implementors can concentrate more directly on providing excellent implementations suitable for widespread use.

I say nothing about Ruby because I know nothing about it.

A second observation is that Perl and Python are both single -implementation languages, which makes it easier to have a coherent set of libraries. Haskell, by contrast, isn't -- there are at least 4 available implementations (hbc, hugs, nhc, ghc). The core language (Haskell98) is supported by all of these, but there isn't a coherent story on the libraries. We are working on that. This plurality of implementations has worked well for the diverse research interests centered around Haskell. I think there is now a growing feeling that we need to standardise the libraries more and put more emphasis on end-user issues -- the kind of things Jelovic mentions -- if Haskell is to have a long-term future.

Here at GHC HQ we are trying hard to make GHC into a suitable vehicle for widespread use. The upcoming GHC version 5 should go some way to addressing issues of installability, library coverage and speed of compilation.

As Simon Marlow pointed out, if you feel motivated to help us work on the libraries, that would be excellent.

I think it's worth clarifying a couple of potential misunderstandings with the original posting:

-- The current version of Hugs is called hugs98 not because the implementation was last revised in 1998 but because it implements the language as standardised in 1998. Hugs is actively maintained.

-- Hugs is not the only Haskell implementation. Ours, GHC, strives hard to provide a coherent, complete set of libraries in the standard distribution. NHC is also moving in that direction. We are not yet there, but are, at least, proceeding.

J

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe