Interesting. Even if you don't care about monads per se, if you know C# 
syntax, this explains what they are, why they are, why you want them, etc. 
It's really little to do with functional programming after all. Or at least, 
certainly not only functional programming.

What is a monad, in terms an OOPL programmer would understand:

http://stackoverflow.com/questions/2704652/monad-in-plain-english-for-the-oop-programmer-with-no-fp-background

Also, how monads are already part of C# and you didn't know it:

http://blogs.msdn.com/b/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 30/06/2011 09:25 PM, Darren New wrote:
> It's really little to do with functional programming after all.

Lots of people seem to have this idea that monads are something that 
only exist in functional programming. (And, further, that it only exists 
as some sort of "hack" to get around the fact that functional programs 
aren't supposed to have side-effects, yet the entire point of running a 
computer program is to produce side-effects.)

That's a bit like saying that monoids are only important in FP. Or that 
only FP cares about rings or fields. This is of course nonsense.

(For those that don't know, a "monoid" is simply anything that's 
combinable. So numbers are monoids. Anything supporting arithmetic is a 
monoid. Anything supporting concatenate or append is a monoid. Anything 
that transforms data (to the same result type) is a monad. And so on and 
so forth. Similarly, a "field" is, loosely, anything that supports 
number-like arithmetic.)

> What is a monad, in terms an OOPL programmer would understand:

> Also, how monads are already part of C# and you didn't know it:

A monad is just a particular way of chaining commands together. I 
imagine it's quite common around the place.

What's perhaps telling is that Haskell calls something "Maybe" when C# 
apparently calls it "Nullable", and Haskell calls it "Functor" when C# 
calls it "IEnumerate"...

(Not to mention "Monoid" verses "Composable"...)

Post a reply to this message

On 7/1/2011 1:48, Invisible wrote:
> A monad is just a particular way of chaining commands together. I imagine
> it's quite common around the place.

Yes. But this blog post tells you *what* particular way, as well as why 
you'd care, in a way one can understand without functional programming.

> What's perhaps telling is that Haskell calls something "Maybe" when C#
> apparently calls it "Nullable",

In C#, you have some types that are value types (like integers) and some 
types that are reference types (like strings, user classes, etc.). 
"Nullable" is a generic that lets you take a value type and also let it be null.

The real use of nullable in C# isn't for "Maybe" cases, but for SQL. If you 
have a SQL column holding "INT NOT NULL", that's an integer in C#. If you 
have a SQL column holding "INT", what is that in C#?  Nullable<int>. (Which 
you can also write as "int?")

 > and Haskell calls it "Functor" when C# calls it "IEnumerate"...

IEnumerable says "I can give you back an object that you can use to iterate 
over this collection of values one at a time." It's not the collection, it's 
not the enumeration itself. It's the thing that holds the state telling you 
how far you have gotten, basically.

> (Not to mention "Monoid" verses "Composable"...)

I don't know what "Composable" is. I don't think C# is meta enough to have 
that as a specific language-level concept.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 01/07/2011 06:55 PM, Darren New wrote:
> On 7/1/2011 1:48, Invisible wrote:
>> A monad is just a particular way of chaining commands together. I imagine
>> it's quite common around the place.
>
> Yes. But this blog post tells you *what* particular way, as well as why
> you'd care, in a way one can understand without functional programming.

Sure. I get that.

>> What's perhaps telling is that Haskell calls something "Maybe" when C#
>> apparently calls it "Nullable",
>
> In C#, you have some types that are value types (like integers) and some
> types that are reference types (like strings, user classes, etc.).
> "Nullable" is a generic that lets you take a value type and also let it
> be null.
>
> The real use of nullable in C# isn't for "Maybe" cases, but for SQL. If

Fair enough. But the net effect appears to be similar.

>> and Haskell calls it "Functor" when C# calls it "IEnumerate"...
>
> IEnumerable says "I can give you back an object that you can use to
> iterate over this collection of values one at a time." It's not the
> collection, it's not the enumeration itself. It's the thing that holds
> the state telling you how far you have gotten, basically.

And a Functor isn't necessarily a container. It's just anything you can 
enumerate over, loosely speaking.

>> (Not to mention "Monoid" verses "Composable"...)
>
> I don't know what "Composable" is. I don't think C# is meta enough to
> have that as a specific language-level concept.

It's something you sometimes find implemented in specific application 
programs. Write a class with an abstract "combine()" method. Write 
subclasses which implement this. Works for strings and containers 
[although you'd probably have a more specific name], coordinate 
transformations, product orders, command objects...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 7/1/2011 15:15, Orchid XP v8 wrote:
> Sure. I get that.

You realize that of all the people who might read that, you're pretty much 
the bottom of the list of target audience, right? :-)

>> The real use of nullable in C# isn't for "Maybe" cases, but for SQL. If
> Fair enough. But the net effect appears to be similar.

Yeah. You just use it for different things. More like, it's similar in SQL 
to Maybe, and you use C#'s Nullable to talk to SQL, so ...

>>> (Not to mention "Monoid" verses "Composable"...)
>>
>> I don't know what "Composable" is. I don't think C# is meta enough to
>> have that as a specific language-level concept.
>
> It's something you sometimes find implemented in specific application
> programs.

That's what I'm saying. "Composable" is a design pattern, not something 
actually in the language or libraries.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Interesting. Even if you don't care about monads per se, if you know C# 
> syntax, this explains what they are, why they are, why you want them, etc. 
> It's really little to do with functional programming after all. Or at least, 
> certainly not only functional programming.

> What is a monad, in terms an OOPL programmer would understand:

>
http://stackoverflow.com/questions/2704652/monad-in-plain-english-for-the-oop-programmer-with-no-fp-background

> Also, how monads are already part of C# and you didn't know it:

> http://blogs.msdn.com/b/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx

  Even after reading those, I still don't understand what a "monad" is,
and how it's different from plain inheritance. The articles talk about
composition as if it was some kind of magic trick. I don't get it.

  It's a bit like the magical term "currying". There seems to be something
very special about it, but I just fail to understand what it is.

  In neither case do I fully understand what exactly is the problem they
are solving, how they are used or why they are useful. In fact, they are
both the strange feature that they seem to be both trivial and extremely
hard to comprehend, at the same time.

  And then some people wonder why functional programming isn't more popular.
How can it be, when it's full of trivial-sounding concepts which are, somehow,
almost impossible to understand at the same time?

-- 
                                                          - Warp

Post a reply to this message

On 02/07/2011 08:19 AM, Warp wrote:

>    Even after reading those, I still don't understand what a "monad" is,
> and how it's different from plain inheritance. The articles talk about
> composition as if it was some kind of magic trick. I don't get it.

And if you sat and read a text on abstract algebra, you would probably 
come away thinking that a "field" is some very special, really complex 
entity that's almost incomprehensible. And yet actually, you use fields 
all the time.

The formal specification of what makes a field is very technical and 
abstract. Fields and the theory behind them are of fundamental 
importance in a wide range of mathematical disciplines. To say that 
"fields are important" is a major understatement.

And yet, lots of people *use* fields all the time. Actually using a 
particular field usually isn't complicated at all. (It's the theory 
concerning /all possible fields/ which is complicated.)

>    It's a bit like the magical term "currying". There seems to be something
> very special about it, but I just fail to understand what it is.

Currying is a simple short-cut, which also allows you to handle 
functions of varying numbers of arguments polymorphically. Anyone who 
claims it's something more magical than that is just over-excited.

>    In neither case do I fully understand what exactly is the problem they
> are solving, how they are used or why they are useful. In fact, they are
> both the strange feature that they seem to be both trivial and extremely
> hard to comprehend, at the same time.

Like one guy said, LINQ is a monad. LINQ solves a real-world problem. 
Point is, you don't have to actually *care* that it's a monad in order 
for it to be useful - any more than you need to care that Int forms a 
subset of a ring with unity, or that Double spectacularly fails to be a 
field.

In Haskell it's slightly different, since you can actually define the 
concept "this is a monad", and then write functions which work for /any 
possible monad/. As far as I can tell, C# can't do that, so knowing that 
something is a monad isn't quite so useful. (It doesn't enable you to 
apply a whole army of existing functions to something just because it's 
a monad.)

>    And then some people wonder why functional programming isn't more popular.
> How can it be, when it's full of trivial-sounding concepts which are, somehow,
> almost impossible to understand at the same time?

This is approximately like saying "The Turning machine makes no sense to 
me. I have no idea what its purpose is. It seems trivial-sounding and 
yet somehow impossible to understand. No wonder computers aren't more 
popular!"

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >    And then some people wonder why functional programming isn't more popular.
> > How can it be, when it's full of trivial-sounding concepts which are, somehow,
> > almost impossible to understand at the same time?

> This is approximately like saying "The Turning machine makes no sense to 
> me. I have no idea what its purpose is. It seems trivial-sounding and 
> yet somehow impossible to understand. No wonder computers aren't more 
> popular!"

  Monads and currying come up all the time when discussing haskell.
Turing doesn't come up when using computers.

-- 
                                                          - Warp

Post a reply to this message

On 02/07/2011 05:12 PM, Warp wrote:
> Orchid XP v8<voi### [at] devnull>  wrote:
>>>     And then some people wonder why functional programming isn't more popular.
>>> How can it be, when it's full of trivial-sounding concepts which are, somehow,
>>> almost impossible to understand at the same time?
>
>> This is approximately like saying "The Turning machine makes no sense to
>> me. I have no idea what its purpose is. It seems trivial-sounding and
>> yet somehow impossible to understand. No wonder computers aren't more
>> popular!"
>
>    Monads and currying come up all the time when discussing haskell.
> Turing doesn't come up when using computers.

Currying, not so much. (Other than that it's something people often do, 
so they use the technical term for it. Rather like inheritance gets 
mentioned a lot in OO languages, even though it's just a short cut for 
duplicating code.)

Monads get mentioned quite a bit, and in fact there's an almost 
embarassing array of monad tutorials - most of them written by people 
who just figured out how it works, or by people who think that everyone 
understands category theory. There's general agreement that monads are 
over-hyped.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Currying, not so much. (Other than that it's something people often do, 
> so they use the technical term for it. Rather like inheritance gets 
> mentioned a lot in OO languages, even though it's just a short cut for 
> duplicating code.)

  The difference, to me, is that I understand what inheritance is and why
it's useful. I can't say the same about currying or monads.

  Btw, in the articles mentioned in the original post the example is
given of making an int "nullable" via a monad (or something along those
lines). I can't comprehend what this has to do with I/O (or, more precisely,
I can't understand what this kind-of "inheritance", which is what it looks
like to me, has to do with I/O), as the I/O monad seems to be one of the
main concepts of haskell.

-- 
                                                          - Warp

Post a reply to this message

On 7/2/2011 12:16, Warp wrote:
>    Btw, in the articles mentioned in the original post the example is
> given of making an int "nullable" via a monad

OK. In C#, the generic class "Nullable" takes a type argument.

Declaring X to be of type Nullable<T> means that X has the methods
   X = (T) Y;  // This lets you turn a T into a Nullable<T> in other words
   X.HasValue is a boolean that returns true.
   X = null;   // This makes X.HasValue return false
   X.Value returns a value of type T if and only if X.HasValue is true.

So, "Nullable<T>" is an "amplifier" of any type T that lets it also have a 
null value.  (Technically, it only works when T is a value type and thus 
doesn't already support being assigned a null value.)

(You could probably do the same thing with multiple inheritance in C++, but 
C# doesn't really have that.)

Turning it into a monad requires making every operation that works on a T 
also work on a Nullable<T>, with reasonable semantics. That's the "bind" 
part of the story.  So for Nullable<int> to be a monad, you have to be able 
to have two Nullable<int>s support addition, subtraction, printf, etc etc 
etc.  So the "bind" function takes a function F that needs a T and gives you 
back a function F2 that needs a Nullable<T>, for any function F.

> I can't comprehend what this has to do with I/O

I think it's more that since you can take the object (anything you'd want to 
print) and append it onto an IO stream, you wind up with a monad. I don't 
think the monad-ness is essential to the IO-ness. It's more that if you do 
IO the way Haskell does, the type of the IO stream winds up being a monad. 
In part because you need each I/O operation to take the result of the 
previous I/O operation, in order to force the I/O operations to be 
evalueated in the correct order.  So where in C you'd say
    printf("Hello"); printf("World");
and the sequencing would ensure they come out in the same order, in Haskell 
you have to say
    x = fopen("...", "w");
    y = printf("Hello", x);
    z = printf("World", y);
where "x" is the IO stream coming in from the outside world, either as 
stdin/stdout or via fopen. So to speak.  So that chaining of values, after 
each call, is what forces the evaluation order. You can't evaluate "world" 
there before you evaluate "hello", because you don't know what "y" to pass 
before the previous printf finished. Monad syntax is just a way of writing 
that without explicitly writing x and y and z. You just say
    fopen(...) -> printf("Hello") -> printf("world")
and it expands into the above sequence of stuff. And what the "->" means is 
going to change for each type.

So the I/O gets done in the specified order because each I/O statement takes 
as an argument the result of evaluating the previous I/O statement. And in 
the same way, each function that might throw an exception has to take the 
result of the previous function that might have thrown an exception and see 
if that previous function actually threw an exception or not. If the 
previous exception is supposed to keep you from evaluating, you have to 
finish the previous evaluation before you can start the next one.

And just like doing "+" on a series of Nullable<int> requires you to look at 
each Nullable<int> in turn to find out if you have a null before you proceed.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> OK. In C#, the generic class "Nullable" takes a type argument.

> Declaring X to be of type Nullable<T> means that X has the methods
>    X = (T) Y;  // This lets you turn a T into a Nullable<T> in other words
>    X.HasValue is a boolean that returns true.
>    X = null;   // This makes X.HasValue return false
>    X.Value returns a value of type T if and only if X.HasValue is true.

  What does X.Value return if X.HasValue is false?

> (You could probably do the same thing with multiple inheritance in C++, but 
> C# doesn't really have that.)

  I can think of two possible ways. Either multiple inheritance, like:

    class NullableInteger: public Integer, public Nullable
    {};

or using composition with a template class, like:

    template<typename T>
    class Nullable
    {
        T mValue;
        bool mHasValue;

     public:
        Nullable(): mHasValue(false) {}
        Nullable(const T& value): mValue(value), mHasValue(true) {}

        void setNull(bool b) { mHasValue = !b; }

        bool hasValue() const { return mHasValue; }
        T& value() { return mValue; }
        const T& value() const { return mValue; }
    };

  The latter could be used for example like:

    Nullable<int> value = 5;

> > I can't comprehend what this has to do with I/O

> [...]

  So it's all related to preserving the order in which I/O is performed?

-- 
                                                          - Warp

Post a reply to this message

On 02/07/2011 08:16 PM, Warp wrote:
> Orchid XP v8<voi### [at] devnull>  wrote:
>> Currying, not so much. (Other than that it's something people often do,
>> so they use the technical term for it. Rather like inheritance gets
>> mentioned a lot in OO languages, even though it's just a short cut for
>> duplicating code.)
>
>    The difference, to me, is that I understand what inheritance is and why
> it's useful. I can't say the same about currying or monads.

And how long have you been doing object-oriented programming?

When I first tried to learn Haskell, I didn't understand most of this 
stuff either. Much like when I first learned about OOP, it didn't make a 
lot of sense initially. (Of course, I wasn't helped by using a 
programming language with "OOP" splashed all over it which *isn't* 
actually object-oriented, but anyway...)

>    Btw, in the articles mentioned in the original post the example is
> given of making an int "nullable" via a monad (or something along those
> lines). I can't comprehend what this has to do with I/O

Absolutely nothing.

That's arguably the confusing thing about monads. Lots of completely 
different things that look nothing like each other all turn out to be 
monads. Even though this "sameness" is highly non-obvious.

> (or, more precisely,
> I can't understand what this kind-of "inheritance", which is what it looks
> like to me, has to do with I/O), as the I/O monad seems to be one of the
> main concepts of haskell.

The I/O monad is what makes I/O possible in Haskell today. (Previously 
it used a clunky solution with lazy lists which made it very easy to 
accidentally deadlock the entire program. Using a monad is a far 
superior technique.)

But, as pointed out, even in C#, where you don't need a monad at all 
just to do I/O, monads still exist and can still be useful. Because 
monads can do things *other* than just I/O...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 02/07/2011 09:52 PM, Warp wrote:

>    So it's all related to preserving the order in which I/O is performed?

In the case of the I/O monad, yes. Basically. (There's also the part 
about explicitly marking values which aren't statically guaranteed to be 
deterministic... but mainly it's about ensuring ordering.)

Note carefully that not all monads are about ordering things. Indeed, 
the "continuation monad" exists basically for the purpose of utterly 
obfuscating your program's ordering to the point where even /you/ can no 
longer understand what the hell it's doing. (This is probably why nobody 
ever uses it...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 7/2/2011 13:52, Warp wrote:
>    What does X.Value return if X.HasValue is false?

In C#, I believe it throws an exception.

>    I can think of two possible ways. Either multiple inheritance, like:
>
>      class NullableInteger: public Integer, public Nullable
>      {};

I don't think that works, because you need a way to get to the integer value 
from a nullableinteger.  Hmmm, well, maybe, now that I think about it, yes.

> or using composition with a template class, like:
>
>      template<typename T>
>      class Nullable
>      {
>          T mValue;
>          bool mHasValue;
>
>       public:
>          Nullable(): mHasValue(false) {}
>          Nullable(const T&  value): mValue(value), mHasValue(true) {}
>
>          void setNull(bool b) { mHasValue = !b; }
>
>          bool hasValue() const { return mHasValue; }
>          T&  value() { return mValue; }
>          const T&  value() const { return mValue; }
>      };

Wow. I actually understood all that. :-)

>    So it's all related to preserving the order in which I/O is performed?

While I'm certainly not the expert here ;-) I think that's correct. In order 
for I/O to happen in the right order in a purely functional language, you 
have to arrange for the result of your first I/O to go to the second I/O 
call. Otherwise, the two could go in either order. So doing I/O in the right 
order is the same mechanism as making sure the second thing in a sequence 
isn't evaluated if the first thing throws an exception, and etc.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 7/2/2011 14:23, Orchid XP v8 wrote:
> "continuation monad" exists basically for the purpose of utterly obfuscating

Known as "CPS" or "Continution passing style" for the rest of us.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 7/2/2011 13:52, Warp wrote:
>    What does X.Value return if X.HasValue is false?

Oh, and for what it's worth, "X = null;" does the same as setting 
"X.HasValue=false" and "X == null" is the same as "!X.HasValue". Just 
syntactic sugar the compiler puts in during one of the very early passes. 
Not something easy to do with C++ just that way, I suspect?

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 7/2/2011 13:52, Warp wrote:
> >    What does X.Value return if X.HasValue is false?

> Oh, and for what it's worth, "X = null;" does the same as setting 
> "X.HasValue=false" and "X == null" is the same as "!X.HasValue". Just 
> syntactic sugar the compiler puts in during one of the very early passes. 
> Not something easy to do with C++ just that way, I suspect?

  I suppose you could add an assignment and comparison operator to the
'Nullable' class that takes a void* as parameter, and which set the
'mHasValue' to false if that parameter is null. (An interesting question
is what should happen if the parameter is not null.)

-- 
                                                          - Warp

Post a reply to this message

On 7/2/2011 0:19, Warp wrote:
>    It's a bit like the magical term "currying". There seems to be something
> very special about it, but I just fail to understand what it is.

Currying isn't particularly magical, especially if you understand lambdas.

What currying means is that a function that takes 4 arguments is really a 
function that takes 1 argument and returns a lambda that takes 3 arguments. 
*That* returned lambda is really a lambda that takes one argument and 
returns a lambda that takes two arguments. *That* returned lambda is really 
in turn a lambda that takes 1 argument and returns a function that takes one 
argument. Currying just means you can write f(a, b, c, d) and the "returns a 
lambda that takes N-1 arguments" is handled automatically by the language.

The original reason for inventing the concept was to make it easier to 
formalize computation, i.e., for the same reason one invents Turing machines 
and lambda calculus and such. Currying let you build an entire language out 
of functions that only take one argument and only yield one result, while 
still letting you program (so to speak) as if you had multiple arguments and 
multiple return values. It's just mathematically easier to not have to deal 
with variable length argument lists.

You get the same benefits as if you had, in C++, a definition like
   int abc(int x, int y) {
      return x + y;
   }
and that the call abc(5) would return a lambda that took one integer 
argument and added 5 to it.

In practice, unless your language defines a function as "a lambda with a 
name" (instead of vice versa), they're not all that useful. You just don't 
use them a lot in a language that has multiple arguments to functions, 
overloaded functions, virtual dispatch, etc.

Currying probably seems "magic" because in a language where you have only 
single-argument functions, currying "magically" gives you multiple-argument 
functions that are more powerful than regular multi-argument functions. But 
if your language already has lambdas, the extra power is already easily 
available when you want it, so the answer is along the lines "Yeah, so?"

Oh, it also lets you deal with variable length argument lists (a la printf, 
say), because each call can return a lambda that can consume any number of 
arguments. But again, if your language already supports passing variable 
number of arguments (either in the C# style of packaging them into "really" 
being an array or the C style of iterating thru the list on the stack), it's 
really not impressive or "magical".

So, currying is really a way to unify various kinds of multiple-argument 
functions (multiple arguments, overloads, variable # arguments) in one 
syntactical mechanism that the other languages just handle as different things.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 7/3/2011 14:16, Darren New wrote:
> of functions that only take one argument and only yield one result,

Oh, and the same mechanism lets you return multiple results.

f(x, y)[z]     (in C syntax)
is really just f(x, y, z) in a functional language.
f(x, y) would, instead of an array or list, return a lambda that when you 
pass it an integer argument it would return the appropriate element of the 
result.  So you could assign the result of f(x, y) to a variable and treat 
it like an array, but in the math, it's just another function invocation. 
And obviously f(x) is similarly a 2-dimensional array, where f(x)(y,z) is 
accessing the 2D array at index y, z.

Basically, currying means that f(x,y,z) is identical to f(x)(y)(z). Sort of 
like the way C unifies 2D arrays as a 1D array of 1D arrays. C only has to 
state the rules of how a 1D array works, and then you can compose them up 
into as many dimensions as you want. With currying, you only have to state 
the rules for taking one argument and returning one result, and curry up as 
many arguments and return results as you want.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message