Functional C Programming: Higher order functions, closures, lifted types
blog.charlescary.com
blog.charlescary.com
[0: http://www.boost.org/doc/libs/1_49_0/libs/range/doc/html/ran...
If I understand correctly, though, your implementation leaks memory. In my case I use a GC to free the thunks when they are no longer accessible.
Adding a GC is a separate task and several exist for C. Though if you were using C++, you could put together some RAII sugar or smart pointers around it all, but in that case you have std::bind1st and functors available anyway (although this is still the only way to meet the raw-pointer use case).
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.
tbh that's the first time i've seen something quite like that. i am not sure this is so common a pattern (usually, imho, you can be more explicit and have a struct that associates a known callback type with named, typed values).
Although a straight-up Google search for "g_closure_invoke" is amusing. I did add the "as long as you can get the memory management right on it" for a reason... page after page after page of "segmentation fault in g_closure_invoke" stack traces....
NSInvocation has a signature of the variable types of the method it represents, so it can retain the object ones without trying to retain plain integers.
Modern Obj-C uses blocks to make closures, which the compiler changes into structs holding all the variables referenced. It knows the types of these as well, so it writes code to retain any object types and releases them as it is released. They haven't got a cycle collector in the runtime, so programmers still make mistakes by accidentally making strong cyclic references.
Assuming the reference-counting GC, it's not hard, but you can still make mistakes.
Uh. Every large C code base I've worked with has had this in some form, usually fairly pervasively. I've mentioned glib as a library that exercises this heavily. In the Windows world this would also include COM. Kernel mode stuff on various platforms tends to do a lot of refcounting as well.
Note that "reference counted object" is just a fancy word for "struct with an integer" - I feel like your phrases like "if you have objects" and "GC" strikes me as confusing this with other features in other languages, a sign that we're not entirely talking about the same thing.
Edit after more time spent away from it: I guess to restate the original comment, what I was trying to say is that to an experienced C programmer closures don't make anything "more hard" - it's just the same memory allocation strategies that you'll be dealing with anyway, and there are already well understood solutions (such as having one of your struct fields be a reference count).
I agree with you, reference counting is not something that would confuse an experienced programmer, but you do have to be aware of what's happening with your objects.
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.
Probably that an Haskell programmer values strong static typing just as much as functional programming.
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).
They're jus programming paradigms. Take what you need and get the job done. Anything else is just a buzzword.
(It's also wrong, or over-simplified, in that all programming doesn't really fit into those little boxes.)
BTW, downvotes are as meaningless as i--.
No, they aren't, and a simple web search would've revealed others, such as Dataflow[1].