>> First, I would like to begin by pointing out that that was a "joke". 
>> It wouldn't really solve the problem you're talking about.
>>
>> However...
>>
>> If you have a function like PrintMyStuff() which takes a bazillion 
>> arguments, the first on which is a portrate/landscape setting, you 
>> could "curry" that function like so
>>
>>   DefaultPrintMyStuff = PrintMyStuff(PS_LANDSCAPE);
>>
>> Now the new function DefaultPrintMyStuff() is just like the original 
>> PrintMyStuff(), except with the first parameter locked to landscape-mode.
> 
> A joke, but very apropos. :)

Hmm. ;-)

Of course, in Haskell it's used more like this...

* You have a function called foo which takes two arguments - a function, 
and a list - and processing the list in some way based on what the 
function is.

* You make a list processing function by saying

   bar = foo my_function

(Remembering Haskell's unauthodox function-call syntax.)

* This is why, if a Haskell function takes any functions as arguments, 
they invariably come *first*, and any data structures come *last*. ;-)

>> Heh, well OK. Of course, the problem isn't so much function pointers, 
>> but rather that the syntax C uses for function pointers is clinically 
>> insane! :-D
>>
>> Haskell, on the other hand, passes functions around all over the place 
>> routinely. But it has a far more sane syntax for them. ;-)
> 
> C# has delegates, instead of function pointers.. which use a bit cleaner 
> syntax.

Haskell has... well, sort-of function references, if you will. Haskell 
doesn't have *pointers* (that can be null and that do arithmetic) 
anywhere, only references (which are never null, always point to 
something valid, can't be pointed to something else because they're 
immutable). Oh, and Haskell is rigidly typed. There is no typecast 
construct in the language.

> Delgates have sort of evolved from named, to anonymous, to lambda.

I don't know anything about it. I've only seen "delegates" in other 
languages, where they're used because "callback functions are really 
useful, but we don't want actual function pointers, so..."

> Lambda expressions are darned convenient. I used them in my little FFT 
> toy app:
> 
> RealInput.Data = GenerateWave(x => cos((Math.Pi*2*x)/(DataLen-1)));

They're also damned useful when you want to curry a function:

   bar = foo (...my random lambda function that I only just here...)

>> Record values can be constructed like this:
>>
>>   PrintOptions {orientation = Portrate, paper_size = A4}
> 
> C# does that, too...
> 
> // Behold the Anonymous Type.
> var val = new { foo= 123, bar = 4.56, baz = "Hello world!" };

Yeah, Haskell doesn't allow that. Types *must* be fully defined before 
you can use them. But once defined, the syntax is the same.

>> What this *doesn't* have is default values; any field you don't 
>> specify is undefined.
> 
> Accessing a field not defined above results in a compile error. Of 
> course, if you have an already defined type, you can set 
> properties/fields in much the same way
> 
> FooBarBaz fb = new FooBarBaz() { foo = 123, bar = 4.56 };
> 
> Baz takes on the default value of "" (assuming its a string)

Yeah, I meant more if you have a type that has fields X, Y and Z, and 
you construct a value of that type but don't specify the value for Z, if 
you try to access Z an exception is thrown.

> I can't believe how similar the syntax is on that. C# is getting to be 
> more and more a C-like language with some functional stuff sprinkled in 
> here and there.

Yeah, looks like in about 8 years or so C# or Python or Ruby will have 
stolen everything that is cool about Haskell, and Haskell itself *still* 
won't be popular. :-(

Which is a pitty, really, because few things can match the beauty and 
simplicity of Haskell...

Post a reply to this message