[Haskell-beginners] computation vs function

[Andrew Wagner]

I kind of like the term "monadic action" myself. Here's another perspective
that may help you out:
I really like the idea of the "programmable semicolon". That is, in your
typical programming languages, you're really working in an implicit State
monad. All the in-scope state is carried over from line to line, and each
line is separated by a semicolon.

In Haskell, we first get rid of this. We don't like the idea of being able
to modify state without being explicit about the types. But of course we
still allow you to carry state around. You use >>= to bind "lines" together
to use the same state. That's when you get to really take things a step
further, though: because state isn't the only "side effect" which you can
capture and hide away in a >>=. You can do it with IO, non-determinism,
potential failure, etc., etc. And that's where monads come in. It's an
interface for gluing together actions with "side effects" in a way in which
the actual effects are explicit, but hidden away in the class instance.

Hope this helps!

On Wed, Apr 22, 2009 at 5:06 PM, Daniel Carrera <
daniel.carrera at theingots.org> wrote:

> Brent Yorgey wrote:
>
>> "Computation" does not really have any technical meaning, it's just
>> supposed to be an intuition.  But the term "computation" is often used
>> to refer to things of type (m a) where m is a Monad.  You can clearly
>> see from the types that something of type (m a) is different than
>> something of type (a -> b).  The former takes no inputs and somehow
>> produces value(s) of type a; the latter takes something of type a as
>> input and produces something of type b as output.
>>
>> However, you could also legitimately thing of things of type (a -> b)
>> as "computations"; more interestingly, you can think of things of type
>> (a -> m b) as "parameterized computations" which can be composed in
>> nice ways.
>>
>> Don't rely too heavily on the "computation" idea; monads certainly
>> don't "revolve around computations", it's only one particular way of
>> giving intuition for monads which does.
>>
>
> Thanks. That helps a lot.
>
> It looks to me that one could replace the word "computation" everywhere in
> the article with "monadic type" (where again, "monadic type" is just an
> intuition for "m a" where m is a Monad) and the article would be equally
> correct. Am I right?
>
> The Wikipedia article seems to use "monadic type" for the same things that
> ertes calls "computation".
>
> I can't decide which term gives better intuition. The term "computation"
> makes binding more intuitive: The computation (m a) returns a value of type
> "a" can then be fed into a function of type (a -> m b). On the other hand,
> "monadic type" is more intuitive when you write "Maybe Int" or "IO String".
>
> Anyways, thanks for the help. I'm (slowly) making progress.
>
> Cheers,
> Daniel.
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/beginners/attachments/20090422/da872308/attachment.htm