Invisible wrote:

> 
> 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. :)

> 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.

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

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)));



> 
> 
> Interestingly, while Haskell doesn't allow named arguments, optional 
> arguments or default arguments, it does give you something let is 
> arguably similar / more useful: a flexible syntax for constructing records.
> 
> For example, instead of PrintMyStuff() having a bazillion parameters 
> specifying portrate/landscape, paper size, base font, margins, etc., you 
> have a record structure describing all the printing options. 
> PrintMyStuff() now takes two arguments: the printing options and the 
> stuff to print. (Remember, Haskell is *not* object-oriented.)
> 
> 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!" };

> What this *doesn't* have is default values; any field you don't specify 
> is undefined. (In C, that means you don't know what it will contain, but 
> in Haskell it means accessing it throws an exception - which can be 
> caught.) But what you *can* do is define a default_print_options value, 
> and then use the incrimental modification syntax:

>   PrintMyStuff(default_print_options {orientation = Landscape}, stuff)
> 
> This gives you the options in default_print_options, except that the 
> orientation (only) is modified. All others remain at defaults.
> 
> Of course, as soon as your printing options are a *data structure* 
> rather than a huge list of function arguments, it's possible to write 
> *functions* to generate useful common combinations, and so on and so 
> forth...

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)


> But sometimes, sure, it's probably easier to just have a damned default 
> argument! ;-)

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.


-- 
~Mike

Post a reply to this message