Functional C Programming: Higher order functions, closures, lifted types

Doing functional programming in C reminds me of Greenspun's tenth rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp

I'm not really sure if this counts a functional programming <i>in</i> C but it does serve as a decent basis for teaching the implementation of functional languages <i>on top</i> of C. As always, the distinction between a library and a whole new language is never quite clear...

When reading this title my default reaction was "Oh God Why" I am happy to see the author agrees with me. As an intelectual excersize I think this is great showing that yes C is very very flexable ( You can do the same stuff with C++ and it will look nicer BTW[0]) but please don't do this, Its messy and hard to trace.<p>[0: <a href="http://www.boost.org/doc/libs/1_49_0/libs/range/doc/html/range/reference/adaptors/introduction.html" rel="nofollow">http://www.boost.org/doc/libs/1_49_0/libs/range/doc/html/ran...</a>

Here's my variation on bind() - generating executable code on the heap allows you to treat the bound function as a raw ordinary function pointer; <a href="https://gist.github.com/3154939" rel="nofollow">https://gist.github.com/3154939</a>

I wasn't sure what a "lifted type" was so I looked it up,<p><pre><code> A type is lifted iff it has bottom as an element. Closures always have lifted types: i.e. any let-bound identifier in Core must have a lifted type. Operationally, a lifted object is one that can be entered. Only lifted types may be unified with a type variable. </code></pre> <a href="http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/TypeType" rel="nofollow">http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler...</a>

Actually, the "closure" pattern shows up in real code; for instance I saw it a lot in libpurple. It's one of those things that's hard to do any sort of large-scale engineering without. As long as you can get the memory management right on it, it's great. (And I wouldn't say that's any more particularly difficult than a number of other useful C patterns.)

This illustrates the fundamental problems of C very well, which are the requirements to be very specific about types and manually manage memory.<p>Of course those things aren't a problem in cases where you need to do those things, but that isn't the case for most applications.

Why not to read the code of various advanced CL and Scheme implementations?) MIT Scheme and SCM and CMUCL are good candidates.)

I saw a similar post a few months ago. You can program functionally (not really) in C. There are certain theoretical assumptions that go along with it. But at its heart, C is still an imperative language. I'm not sure what the point is in making C good at doing things "functionally".

Of course, this skips negligible parts of C programming like memory management.

TFA says that was done answering an Haskell programmer.<p>Probably that an Haskell programmer values strong static typing just as much as functional programming.<p>I someone think that turning C from a weakly static type system to a strongly static one would prove quite more difficult... (but my C days are long gone so don't quote me on that).

1) imperative programming 2) functional programming 3) OOP 4) etc programming<p>They're jus programming paradigms. Take what you need and get the job done. Anything else is just a buzzword.