Compile-time typing good. [LWN.net]

Compile-time typing good.

Posted May 2, 2007 18:10 UTC (Wed) by ncm (subscriber, #165)
In reply to: What, again? by dcoutts
Parent article: The Rise of Functional Languages (Linux Journal)

Yes, Haskell has a very powerful type system. (Of course that's nothing to do with its being a functional language, so we are drifting off topic a bit, but what the hell.) VSIPL++, by the way, also fuses array operations, probably by very similar means. Recently it demonstrated a 3x FFT performance on IBM Cell vs. IBM's own library and custom compiler.

I met somebody back in Massachusetts working on something he called Eager Haskell. People laugh, but it's much faster than regular Haskell, making it practical, at least for pure computational work. Probably Darcs should be rewritten in Eager Haskell.

Somebody else demonstrated a Haskell compiler as a C++ library. It compiles (rather slowly) to fast native code.

(Log in to post comments)

What's practical?

Posted May 3, 2007 0:14 UTC (Thu) by shapr (subscriber, #9077) [Link]

What's practical?

Some Haskell applications that I consider to be practical are: a Quake clone Frag, a fast as Apache webserver HWS, and an operating system named House.

You mentioned darcs already, it also seems practical to me.

You also mentioned that Haskell compilers produce fast native code, so what about Haskell do you perceive to be impractical?

What's practical?

Posted May 3, 2007 18:03 UTC (Thu) by ncm (subscriber, #165) [Link]

Haskell's garbage collector and the language primitives that depend on it makes it impossible to implement the features needed to abstract management of non-memory resources. Its inability to abstract resource management also makes it impossible for exception facilities to safely centralize error handling. In this it is like other languages that have failed, and will continue to fail, to unseat C++ from serious industrial applications. That's unfortunate because C++ needs serious competition.

By "practical", in context, I meant "practical for industrial use". For pure computation Haskell (well, Eager Haskell) verges on the practical already.

Looks practial to me.

Posted May 4, 2007 0:09 UTC (Fri) by shapr (subscriber, #9077) [Link]

Haskell's garbage collector and the language primitives that depend on it makes it impossible to implement the features needed to abstract management of non-memory resources.

I think this is incorrect.
First of all, non-memory resource management is already abstracted. File handles, sockets, etc are garbage collected when they are no longer reachable.
Second of all, if you want to be able to explicitly de-allocate a resource before the GC reaches it, you can use an RAII-style wrapper, like withSocket or withHandle.

Haskell doesn't really need explicit destructor support in the language. Because they can be written in a library, they don't need to be part of the core.

Its inability to abstract resource management also makes it impossible for exception facilities to safely centralize error handling.

I'm not really sure what you mean here. Haskell exceptions can be caught anywhere further up in the scope. That means you can catch an exception thrown deep in the code and handle it in your top level code. That sounds like centralized error handling to me. Perhaps I misunderstood?

It sounds like your concern is about putting resources inside other structures (assuming proper use of those structures) and getting semi-automatic management, with an option to have more explicit management.
I've already mentioned GC and RAII-style (block scope) destructors. For other custom schemes (pools, regions, etc), you can use monads.

By "practical", in context, I meant "practical for industrial use".

Haskell is already used in the industry. What's your definition of industrial use?

For pure computation Haskell (well, Eager Haskell) verges on the practical already.

In my experience, non-strictness in Haskell dramatically simplifies the logic of a program, I wouldn't want to return to writing strict languages. Why do you think non-strictness is impractical?