4 ms·
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 som
by overgard 12y ago
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?
- graphitemaster 12y agoIf 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 https://github.com/graphitemaster/redroid hashtable.c and list.c look for [hashtable|list]_foreach. Another good example is config_save in config.c.
- anaphor 12y agoYou could do closure conversion, but then you run into problems with the lifetimes of things, oh and then you're basically reimplementing lisp.
- overgard 12y agoNot 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 12y ago"C++ now has closures and... [they're] not that awful" Some high praise, that. C++ closures: they're not that awful.
- ufo 12y agoYou 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 12y agoYeah, those would be nice to have in C.
- mtdewcmu 12y agoA 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 12y agoThat'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 12y agoIt'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/ http://matt.might.net/articles/compiling-scheme-to-c/
- billsix 12y agoAs 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 http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
- mtdewcmu 12y agoGCC'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.
- billsix 12y agoThe question to which I responded did not inquire about performance nor about portability http://tirania.org/blog/archive/2011/Feb-17.html http://tirania.org/blog/archive/2011/Feb-17.html
- graphitemaster 12y agoWith 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.