
Monads in Scheme - amirouche
http://okmij.org/ftp/Scheme/monad-in-Scheme.html
======
nicklaf
Oleg's entire site is a veritable gold mine of Scheme and Haskell treasures.
Poke around--you won't be disappointed.

------
davexunit
This was a helpful article for me because I am more familiar with Scheme than
I am ML, which most monad articles use.

For those that want to see a Scheme monad implementation that is being used
for real work on a regular basis, check out the (guix monads) module in GNU
Guix:

[http://git.savannah.gnu.org/cgit/guix.git/tree/guix/monads.s...](http://git.savannah.gnu.org/cgit/guix.git/tree/guix/monads.scm)

------
kenko
There are several monad libraries for Clojure---mine (of which I'm fond) is
here: [https://github.com/bwo/monads/](https://github.com/bwo/monads/)

------
fierycatnet
Since it's a LISP, does that mean it would be useful in Clojure as well? Any
thoughts on this?

------
lispm
but why?

~~~
davexunit
Because they are a very useful abstraction?

~~~
sago
> Because they are a very _useful_ abstraction?

Doesn't that beg the question? Saying they're useful just invites another 'but
why?'.

Other than being familiar to Haskell programmers, what do monads allow a
programmer to do in scheme that isn't more simply implemented in another way?

(Not passive aggressive rhetorical questions, genuine ones).

~~~
bunderbunder
I think that Haskell has maybe done a bit of a disservice by making so much
hay about using monads for side effects. That's super-important in the context
of Haskell, of course, but it gives the unfortunate and false impression that
that's what they're really about.

I don't know that I'm feeling up to banging out a concrete example in Scheme,
but I'd strongly encourage anyone who'd like to see monads being put to good
use outside the Haskell space to take a look at the .NET ecosystem. Monads are
the soul of LINQ, and F#'s workflows are essentially just monads wearing
Groucho glasses.

For a concrete example of where they can be useful, let's say you've got the
following LINQ query (C# code):

    
    
      var sum = Enumerable.Range(1, 10000)
                          .Select(SomeInterestingCalculation)
                          .Where(SomeInterestingPredicate)
                          .Sum();
    

and you want to parallelize it. It's pretty easy to do because some clever
folks have already done all the hard work and encapsulated the whole mess in
an easy-to-use package:

    
    
      var sum = Enumerable.Range(1, 10000)
                          .AsParallel()
                          .Select(SomeInterestingCalculation)
                          .Where(SomeInterestingPredicate)
                          .Sum();

~~~
_delirium
> I think that Haskell has maybe done a bit of a disservice by making so much
> hay about using monads for side effects. That's super-important in the
> context of Haskell, of course, but it gives the unfortunate and false
> impression that that's what they're really about.

I don't think this is just due to Haskell's specific needs. Monads were
originally introduced into computer science as a tool for denoting delimited
effects, and many researchers have commented on the close correspondence
between monads and effects (in both directions). If you take any given piece
of monadic code, you can interpret it as a typesafe way of specifying an
imperative computation in a delimited part of the program. Haskell's do-syntax
particularly emphasizes this by even making it "look" imperative, but you
could still interpret it that way even without the syntax helping you.

Even in the C# example you use, what is .AsParallel() denoting, if not an
effect?

