[Haskell] Mixing monadic and non-monadic functions

Sean E. Russell haskell at ser.fdns.net
Tue Mar 23 17:54:07 EST 2004

On Tuesday 23 March 2004 17:04, you wrote:
>   * Memory management (allocation and deallocation) is effortless.
>   * Creating lexical closures is very easy.
>   * You don't have to declare the types of all your functions and local
>     bindings, because the implementation can figure them out for itself.
>   * You don't have to ensure that values are computed before they're used,
>     because the implementation handles that too.
> If you were learning C instead of Haskell, you'd be complaining (and
> rightly so) about the effort required to do these things in C.

Actually, most of these things are pretty easy in Ruby, too.  Everything is 
easy in Ruby :-)  But what I like about Haskell is stuff like pattern 
matching and list comprehension.  I also particularly like the effortless 
strong typing.  Before Haskell, I thought strong typing meant variable type 
declarations, which are tedious.

When I find myself doing design and writing pseudocode, and having it look a 
lot like a language I use, I decide that the language is Good.  So far, this 
has happened to me with both Haskell and Ruby -- Haskell at a higher level, 
when I'm thinking about functions that I'll need, Ruby when I'm sketching out 
algorithms.  In eight years of coding Java professionally, I *never* found 
myself writing any pseudo-code that looked anything like Java.

> We'd all love to make the lifting implicit, but no one knows how to do it
> without breaking the whole language.

I've heard people talk about the functional "purity" of Haskell -- you'd have 
to break this purity to add implicit lifting?

> A related problem which was discussed here recently is Haskell's lack of
> per-type namespaces, something which even C programmers take for granted.
> Again, the problem is the tricky interaction with type inference.

Augh!  Yes!  I've hit that as well.  Well, in my case, it was constructors.  I 
was trying to do:

	data Effort = Easy | Middle | Hard
	data Impact = Low | Middle | High

Effort and Impact aren't related (in any useful ontological sense that I can 
think of), so I don't want to make them instance of the same type -- but I 
can't reuse Middle without it (AFAIK).  So I had to fudge, and call the 
Impact constructor "Medium", which sort of grates, as you can imagine.

Yeah, that's something I'd like a work-around for, too.

> Unless/until these problems are resolved, all you can do is learn a bunch
> of different languages and use the one which is most convenient for a
> particular task. Haskell, for all its problems, is a strong contender for
> many tasks.

What I use Haskell for are those tasks where I really want something compiled.  
What surprised me, after I'd used it for a few weeks, was that my 
applications were more robust than I expected, given the novelty of the 
language to me.  If I were to write any software (in a language that I know) 
upon which lives depended, it'd be in Haskell.

I find that, with Ruby, I don't struggle -- the code just flows -- but I 
*liberally* use unit testing, and even so I spend a fair amount of time 
debugging .  With Haskell, I spend some effort figuring out how to solve the 
problem and some time getting it to compile, but once it does, it generally 
works as expected.  Very rarely do I need to debug code that compiles.  With 
Java, I spend a fair amount of time getting stuff compiled and running, and 
then even more time debugging, and then more time fixing stuff later.  

The most amazing thing to me about Java is how little the compilation phase 
contributes to making code more robust.  My Ruby is no more buggy than my 
Java, and it is loosely typed and entirely interpreted.  In fact, I generally 
trust Java applications less than Ruby applications.

But, I fear I'm wandering off-topic.  Thanks to everybody for the feedback 
about my problem; I have a working solution using the visitor pattern, and 
while I'm still concerned about IO monads (yes, just IO; other monads -- such 
as Maybe -- are less troublesome), it is "good enough".

### SER   
### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido
### http://www.germane-software.com/~ser  jabber.com:ser  ICQ:83578737 
### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg

More information about the Haskell mailing list