Some good-hearted criticism (Was: Biggest Haskell unit in the world)

[Alastair David Reid]

Juan Carlos Arevalo Baeza <jcab@roningames.com> writes:
>     And it's a good quest. I see three problems that prevent me from
> seeing Haskell as a "Real World" language. 

> First, compiler support.
> Second, debugging tools.

I agree these could be much better (though I don't think people really
whacked on your code with their debugging tools).

Unfortunately, research groups (the people who develop the compilers)
don't have the resources to both do research and push hard enough on
portability, ease of installation, documentation, etc.

It'd be great to have people whose full time job was to tie up all the
loose ends in the tools (portability, error messages, documentation,
etc., etc.), help people use the tools effectively, develop cool
libraries, provide consulting services, etc.  In other words, it'd be
nice to have a Cygnus-like company to support Haskell developers the
way Cygnus supports C/C++ developers.  Is there a market out there
that would make a Cygnus-like company viable?  (There are definitely
skilled people who would like to form such a company.)

>     Third, it lacks expressiveness. I know it's all meant to make it
> a simple and robust language, but still, to make "Real World"
> applications you have to care more for what the programmer needs
> than what the language needs. A certain amount of controlled and
> documented ambiguity is a good thing if it enhances the
> possibilities for the programmer.

Can you give some examples of what you mean?

[I felt our semantics for exception handling had all the ambiguity you
could ever want in a language and then some :-)]

> A parallel meta-language, even a limited one, would be even better.

If you mean "parallel" as in multi-processor?  The work of
Hans-Wolfgang Loidl, Kevin Hammond, Phil Trinder, SimonPJ and others
on separating "algorithms" from "strategies" seems to be just what
you're asking for.

> Better scoping wouldn't hurt either (after C++, I just
> cannot live without those nifty nested namespaces).

Haskell has had qualified names (roughly corresponding to C++'s
foo::bar) for a while now.  When is this not enough?  (I'm curious
about the answer, not just trying to flip you off.)

btw Java-style hierarchial module names are coming to Haskell
(implemented in GHC, NHC and Hugs).  See the libraries mailing list
for some details.

> And explicit performance-tuning constructs would be a blessing,
> rather than having to hack them in in some indirect way (i.e. the
> "force" function for monadic parsers, etc...).

The force function is very, very domain specific.  It doesn't even
make sense to talk about it if you're not talking about parser
combinators (maybe only monadic parser combinators).  So the best
thing to do is to use a well-tuned parser library (or a parser
generator) and let the implementor worry about it.  Apart from
providing good libraries and a nurturing environment in which those
libraries can live (see libraries mailing list), there's really not
much that the language can do.

That said though, it'd be great to be able to add strictness
annotations to functions and to be able to use unpointed types (like
GHC's Int#).  Anyone who has looked at the ugly hacks I added to Hugs'
Pretty library (to overcome Hugs' lack of Int#) will see just what I
mean.

[To be more precise, what I want is that values of type Int# should be
strictly evaluated (like Int# in GHC) - I don't care whether Int# is
boxed or unboxed (a representation detail).]

There's probably a few other things that could be done (suggestions
welcome).

> my FP background is indeed limited, and therefore I might "still" be
> missing some points here.

There's a risk that you might view the Haskell'98 report as defining
the state of the language.  In fact, many Haskell programmers rely on
extensions like:

- multi-parameter type classes
- functional dependencies
- existential types
- overlapping instances
- implicit parameters
- concurrency support
- exception handling (both synchronous and asynchronous)
- the foreign function interface (i.e., ability to call back and forth
  from C, Java, .net)  (The C story is very well developed, Java and .net
  are starting to become available.)
- the "hslibs" libraries (which work on GHC, Hugs and, I believe, NHC)
  and include support for Posix, Win32, X11, HTML, XML, parser combinators,
  building test harnesses, and a lot, lot more.

Unfortunately, we seem to be stuck between Haskell'98 whose explicit
design goal was to be stable and Haskell 2 in which backward
compatability (which lead to increasingly unfortunate design decisions
in Haskell 1.0--98) would be largely ignored.  

We don't seem to be ready for Haskell 2 yet: some of the above ideas
clearly need revised before being standardised, some are too new to
even know if they need revised, some ideas (like those in O'Haskell)
haven't even made it into a mainstream implementation.

In the meantime, different compiler groups are adding features
according to their particular research interests and standardising
between themselves as the need arises.  (I'm not sure that this is a
bad thing - compatability between compilers is limited more by lack of
manpower than by lack of agreement or by misunderstanding and
communication.  The only bad thing is that newcomers might reasonably
expect the language standard to reflect the state of the art.)

> The FP way of thinking has hit hard on me, though. I just coded a
> bunch of parametric functional parsers in C++ using template
> metaprogramming

  A language that doesn't affect the way you think about
  programming is not worth knowing.

                     -- the 'fortune' program

-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/