[overgard]

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?

[billsix]

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

[mtdewcmu]

GCC's nested functions are implemented with trampolines, so there will be a performance penalty. For the amount that you gain, they seem like a bad idea. Tying your code to GCC for the sake of a small amount of convenience is a bad idea.

[graphitemaster]

With things like PaX the trampoline method won't work, gcc now creates thunks, which are essentially heap allocated thunks of memory (hence the name) with PROT_EXEC.

[billsix]

The question to which I responded did not inquire about performance nor about portability

http://tirania.org/blog/archive/2011/Feb-17.html

[mtdewcmu]

My comment was about GCC's local functions. It wasn't really about your comment, so I regret if you took it personally.

[billsix]

Thank you. Much respect, sorry if I was harsh.

[anaphor]

You could do closure conversion, but then you run into problems with the lifetimes of things, oh and then you're basically reimplementing lisp.

[overgard]

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.

[mtdewcmu]

"C++ now has closures and... [they're] not that awful"

Some high praise, that. C++ closures: they're not that awful.

[graphitemaster]

If you look at Redroid (a project which makes extensive use of lambdapp) you'll see how map/list/etc can take advantage of this https://github.com/graphitemaster/redroid hashtable.c and list.c look for [hashtable|list]_foreach. Another good example is config_save in config.c.

[mtdewcmu]

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.

[overgard]

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

[mtdewcmu]

It's true literally.[1] If the language was designed around closures that's one thing. In C, it would be one language paradigm too many.

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.

[1] http://matt.might.net/articles/compiling-scheme-to-c/

[ufo]

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.

[overgard]

Yeah, those would be nice to have in C.