21–30 of 51 posts
That's neat, but without closures I don't really see how you could do much with it outside of toy examples. Going off the examples -- how often do you write something like a foreach or a map or reduce that doesn't reference its enclosing scope?
You wouldn't need full blown closures. Inner procedures that can't escape their scope, like they had in Pascal are already useful but don't come with the extra memory management requirements of closures.
That's neat, but without closures I don't really see how you could do much with it outside of toy examples. Going off the examples -- how often do you write something like a foreach or a map or reduce that doesn't reference its enclosing scope?
You could do closure conversion, but then you run into problems with the lifetimes of things, oh and then you're basically reimplementing lisp.
That's neat, but without closures I don't really see how you could do much with it outside of toy examples. Going off the examples -- how often do you write something like a foreach or a map or reduce that doesn't reference its enclosing scope?
As long as the stack frame is still active, the local variables are still alive and valid. So you could pass a local function as a parameter, but you could not return it. I think jwz called these "downward funargs". GCC supports it http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
If you use clang, blocks are another approach. [0] http://en.wikipedia.org/wiki/Blocks_(C_language_extension) [1] http://clang.llvm.org/docs/BlockLanguageSpec.html
Earlier quoted context omitted.
A closure is syntactic sugar for a function plus a struct. Sometimes I think they would be a useful addition to C. But these kinds of things never turn out to be as useful as they seem at first.
That's true in a hand-wavey sense, but it ignores that function+struct means you have to define new types, include those types everywhere your closure is used, manage the lifetime and scope of those types, etc. etc. I would argue the opposite: these things are actually way more useful than they seem at first. The fewer things the language makes you think about, the more you can focus on what you're trying to actually…
If you want a language with closures, and all you have is C, the time-honored solution is to write an interpreter and give the interpreted language closures. That is a good way to go.
Earlier quoted context omitted.
You could do closure conversion, but then you run into problems with the lifetimes of things, oh and then you're basically reimplementing lisp.
Not really; C++ now has closures and I'm not going to say it's ideal, but it's not that awful either. The whole "reinventing lisp" argument really only applies to macros at this point (ie: something that fundamentally would require a Lisp to do properly), the other features have been scavenged by other languages without being a lisp just fine.
Some high praise, that. C++ closures: they're not that awful.
If you use clang, blocks are another approach. [0] http://en.wikipedia.org/wiki/Blocks_(C_language_extension) [1] http://clang.llvm.org/docs/BlockLanguageSpec.html
The problem with clang blocks is they're represented as a Objective-C object, this makes them unusable in APIs that expect a function pointer, the only way you can cast them to a function pointer is to define the structure which represents the block and mmap executable code pages to marshal the call. Such a library exists that binds them to libffi here https://github.com/mikeash/MABlockClosure This feat alone makes b…
I think the problems you're describing are ones that are going to be faced in any attempt at C closures. Closures have memory attached, that's the appeal of them and also the source of all the problems.
Earlier quoted context omitted.
Nope, clang can be used on BSD, Linux, and Windows as well. http://clang.llvm.org/get_started.html
I'm aware of that, but do you get blocks?
Blocks are supported for programs developed for Mac OS X
10.6+ and iOS 4.0+,[1] although third-party runtimes
allow use on Mac OS X 10.5 and iOS 2.2+.[2]
Earlier quoted context omitted.
Compound literals in C are awesome like it's 1999: Assuming you have this: struct point { float x, y, z; }; void do_something_with_point(struct point *p); You can do this: do_something_with_point(&(struct point){.x = 1.5, .y = 1.5, .z = 3.5});
You can take the address of a literal? Being able to specify a literal for a struct is useful. You can, for instance, put the literal in a macro and use the macro to initialize or reset a struct. It's better than having to write additional functions to do something trivial.
Earlier quoted context omitted.
Anonymous functions are a way of de -obfuscating code that is heavy in callbacks. Instead of having the logic flow indirectly to some external method that might be far away, the logic can live within one function body.
Callbacks are inherently going to make a program harder to follow. Without seeing the code, it's hard to suggest other solutions.
I haven't used LambdaPP, but I'm guessing you can get around the lack of closures the same way you do with callbacks, by passing a void* with necessary data.