>>40
No. Supporting nested functions does not necessitate supporting closures.
Name:
Anonymous2010-07-17 0:24
>>41
The GCC nested functions extension support closures, which is what we're talking about.
Name:
Anonymous2010-07-17 0:27
>>42
Well, arguably clang could support closures without supporting nested functions but I don't know how much use that would be.
Name:
Anonymous2010-07-17 0:30
>>43
Oddly enough, Clang supports both Objective-C style blocks (lambda functions and closures) and C++0x lambda functions with closures, but both are implemented through different mechanisms, and both aren't language extensions.
Name:
Anonymous2010-07-17 0:43
>Write a function foo that takes a number n and returns a function that takes a number i, and returns n incremented by i.
a=parseInt(prompt("Enter a number",0));;
eval("function newf(i){return a+i}")
newf(10);
>>45 function foo(n){return function(i){return n+i}}
foo(pareInt(prompt('Enter a number', 0)))(10);
Name:
Anonymous2010-07-17 1:35
>>46
You can't reuse that function without declaring it with a name outside function scope. Observe:
function check(){
a=parseInt(prompt("Enter a number",0));;
eval("function newf(i){return a+i}")}
check()
newf(10);//Error: newf is not defined
>>52
Why would you do that?
OOP and closures are somewhat equivalent.
A class with a (possibly private) member called i, a constructor which takes i, and an add method which takes n is enough.
Usage would be like:
Adder adder = new Adder(i);
int newValue = adder.Add(n,i);
It's not exactly what OP requested for, but the concepts are somewhat equivalent. It's easier to implement OO systems if you already have closures and macros, but it's harder to implement closures if you only have classes, but aside from that the functionality they present is somewhat equivalent.
>>53
I was trying to go for a "nested functions" feel and this was the only way I could think of achieving that.
I suppose I could the Java Method class in some way too but that would be a ridiculous amount of work compared to the simplicity of the request.
Name:
Anonymous2010-07-17 4:08
Any solution which manipulates function pointers is very messy.
(return *func_pointer)(execute_from) vs setting global variable x=n; and using standard function calls
#include <stdio.h>
#include <stdlib.h>
int n=0;
int getn(i){return n+i;}
int main(int agrc,char**argv){
n=10;printf("%i",getn(6));
return 0;
}
>>55
Any solution involving globals isn't a real solution as you can't just "make as many functions/closures" as you'd like. You can only "generate" one such function. "Making" another invalidates the previous one.
Name:
Anonymous2010-07-17 5:05
JESUS FUCK PEOPLE WHAT THE FUCK IS WRONG WITH THIS THREAD
>>4
1) would work, except it's more complicated than you make it seem; for instance malloc'd memory is execution-protected on modern operating systems. Honestly to make it portable, your best bet is probably to compile it with llvm. You still have to manage the memory containing the closure though, so it's still not like a closure in a typical HLL.
2) does not work because your funcall macro can't be passed around as a function pointer. there's no real way to do it other than return a struct (the closing environment) and pass in that struct in the function call.
In other words it's certainly not possible in standard C, but possible with runtime code generation or compiler extensions.
>>76
You wouldn't need any semicolons for that in Perl but you'd use them anyway.
For some reason I find keeping it on a single line helps me remember the semicolon after curlies. It's also the only excuse I sympathize with for instancing typedefs with their definitions.
Name:
Anonymous2010-07-18 5:32
perl: sub foo{eval"sub{@_+pop}"}
javascript (1.8+): foo = function(n) function(i) n + i;