What's practical?

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?