Actually, the C/C++ programmers I know think nothing can be done with functional programming languages because they are sooooo used the concept of a "C" function, that they think that Haskell functions are just that, functions like in C. C# does not have function pointers, only the concept of a delegates (which was copied from Delphi's "closures", the official name?), and that is much closer to FP's "functions" If people would see that Haskell functions are *not* that silly kind of C functions, but actually little "objects" that *can* carry immutable state, they would look differently at functional programming languages I guess. So I think the word "function" means different things depending to which community you talk... Before I knew Haskell, the OO community started to embrace the concept of "interfaces" more and more (aka purely abstract classes). Furthermore in OO, many bugs are caused IMO by keeping track of mutable state and caches (which is often premature optimization). So for complicated tasks, I tended to use more and more immutable objects, e.g. objects that could be constructed once, but not mutated. And then I noticed that it was often not needed to precompute all the values that got passed to the constructor, so I added C# "properties" that computed the inner cached values once, lazily. IMO Haskell embraces the above ideas and much more, with the difference it encapsulates these ideas nicely and concisely, so you need only a fraction of the lines of code :) So I guess if an OO programmer gets at this level, he should *not* look at Haskell, because he will not want to go back to his messy imperative programming languages :) Peter -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Jules Bean Sent: Saturday, December 22, 2007 1:09 PM To: Cristian Baboi Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Functions are first class values in C Cristian Baboi wrote:

Let me show you an example to prove it.

That's not C. That's the C preprocessor, which is a textual substitution macro language. Macros certainly aren't first class (you can't pass a macro to a function, only its expansion). C does support function pointers, which are something like first class functions. The main things C lacks which people associate with true first-class function is: The ability to construct anonymous/local functions. The ability to capture local variables and return a function with some variables bound. The ability to write type-safe functions with polymorphic arguments. Jules _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Lazy constant in C:

int C1 (){ return 7; } C1 is computed only when you apply the operator () to it.

But that's not the point of lazyness. Lazy value is computed only ONCE.

Cristian Baboi wrote

Lazy constant in C: int C1 (){ return 7; }

Not really, this is not lazy, since it always recomputes the value "7". To have "lazy" values in C you would have to do something like: struct ValueInt { int IsComputed; union { int Value; struct { int (*ComputeValue)(void *args); void* Args; }; }; }; int GetLazyInt (ValueInt* v) { if( !v->IsComputed ) { v->Value = v->ComputeValue(v->Args); v->IsComputed = true; } return v->Value; } But this of course, is totally useless in C and very bulky. It's also impossible to know when to call freemem on the Args (hence garbage collection in FP), when *not* to use lazy values but strict values instead (hence strictness analysis in FP), etc... I must say I had the same opinion as you had for many many years. I always thought "functions as first class values" where just function pointers, so what is it these Haskell/FP guys are so excited about? But if you dig deeper, you'll see the magic... Notice you will have to give yourself some time; it is very hard to get out of the imperative blob. E.g. I'm still being sucked into the imperative blob after my first year of Haskell hacking :) PS: As I'm relatively new to Haskell, don't take the above C code too seriously; it certainly will not reflect the way a real Haskell system works. Peter