 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
|
|
