Paolo Capriotti wrote:
> 
> That's not quite right, imho. An IO monad encapsulates a sort of "IO
> operation", and IO routines are not monads themselves. Instead, they
> _return_ IO monads.
> In spite of monads, I think that Haskell code can still be considered
> without side effects. Something like
> main = do c <- getChar
>           putChar c
> should be thought as a manipulation of abstract "IO operations". It
> produces side effects only because the resulting monad is finally
> evaluated (i.e. executed), and that cannot be done inside the Haskell
> domain.
> 

Exactly.

> Anyway, monads are not just for IO. There are plenty of monadic
> classes in the ghc library which have nothing to do with IO. A list is
> a monad, for example, as well as a parser.
> 
> I'm still considering the monad subject from the point of view of Ruby
> programming. It may seem that monads belong to the pure functional
> world only, and Ruby does not need them, but...
> when we write ary.map{|i| i+1}, aren't we using the fact that Array is
> a functor (in the mathematical sense)? To some extent, inject can be
> considered as a way to exploit the monadic properties of the Array
> functor.
> 

In some sense. However, I think monads can really be implemented in a 
language that uses a type system like the one used in Haskell, where one 
can have operations *on types* (that's basically what monads, with their 
type constructors, are). This can probably be done in Ruby through 
operations on classes, but that doesn't really feel like the Ruby Way 
(although it may be fun to implement ;) ).

> However, can the monad concept be defined in Ruby in some generality?
> 

Thanks to Ruby's dynamicity, it is definitely possible. I'd have a hand 
at it if I had some time (which I haven't) and if I felt I had a good 
enough understanding of monads (which I don't). And then I'd probably 
make a fool of myself anyway ;) .
-- 
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.