Talk:First-class function
"Most modern programming languages support functions defined statically at compile time. C additionally supports function pointers, which can be stored in data structures and passed as arguments to other functions. Nevertheless, C is not considered to support first class functions, since in general functions cannot be created dynamically during the execution of a program. The closest analog in C is that of a dynamically compiled function created by a just-in-time compiler, which is compiled as an array of machine language instructions in memory and then cast to a function pointer. However, this technique is specific to the underlying hardware architecture and is therefore neither general nor portable."
I have problems with this. The main thing is that the attempt to find an analog in C seems pointless to me. I wouldn't try to find an analog of 'break' in Lisp, although I'm sure I could find something not too dissimilar if I strained hard enough. In turn, I don't think it's conducive to understanding of the first class function to compare it to something like int (*f)(). Of course it is perfectly feasible to write C code to write a bit of C, compile it, put it into a dynamically linked library, open the library and execute it--in fact, this was even easier in BCPL, one of C's percursors, which had extensive dynamic module load and execution capabilities built into its standard library. However this isn't really a first class function, it's just a neat programming trick.
Well, I was trying to pre-empty a potential argument that the presence of function pointers in C is the same as having first class functions. What are the crucial properties a function object has to have in order to qualify as first-class? You can pass function pointers as arguments to other functions, and you can store them in memory and other data structures; in these respects function pointers and first class functions are indeed similar. What distinguishes function pointers from first class functions is that the only values a function pointer can take on are the addressed of functions defined at compile/link time. However, due to the presence of casts (nothing stops you from casting arbitrary pointers to function pointers), this is not literally true, but those casts are really only useful for in-memory compilation. Since C directly supports function pointers and casts in the language, it makes sense to point out that these features don't add up to first class functions, with which they nevertheless share some properties. --MarkSweep 07:08, 13 Nov 2004 (UTC)
- I agree with the garbage collector guy. When reading the page, you insintictively have the urge to say "hey but C...", yet the text corrects you in time. Wouter Lievens 21:40, 3 Apr 2005 (UTC)
The notion of "dynamically creating functions" is grossly inaccurate.
The languages mentioned, for the most part, do not have the explicit ability to create functions but to create closures. Functions consist of code, which is typically not dynamically generated or modified. Closures capture the (usually lexically) contectual environment existing at the time of the closure's creation, along with whatever function is associated with the closure. This is, unfortunately, more than a semantic issue - it is explicitely being confused with dynamic code generation, which is given as a comparative example. This technique has nothing in common whatsoever with first order functions.
Of course, removing this "requirement" from the list also means that C DOES have first class functions. If you don't agree with this, I'd recommend including closures as mentioned (which, IMO, are a somewhat different beast), and perhaps anonymous functions as well.
I'd make these changes myself but I don't want to so majorly overhaul this node without some further input. —The preceding unsigned comment was added by 74.128.168.38 (talk) 22:36, 18 January 2007 (UTC).
I agree here. Maybe a mention of the eval() statement (or equivalents) would help to make the difference more obvious? --80.135.123.126 16:22, 26 January 2007 (UTC)
I think that the definition as given here isn't really accurate. As far as I understand the term, the point is just that there is no difference between a function and a data type in the things you can do. This implies that you can assign local variables to functions, and then call those local variables in exactly the same way as you'd call a function. It implies that you can pass functions as arguments to other functions. Creating a function at runtime seems to me to be a completely different thing. In particular, you can achieve similar effects in every language I know of - even if you have to compile the code yourself into memory. I don't think that passing a function pointer around as in c, or wrapping the code in an inner class (java) or a Proc (ruby) qualifies as first-class functions. The point is that they are 'first-class' - that they don't need special treatment. 88.96.214.6 10:25, 22 March 2007 (UTC)
Does Ruby really have first class functions?
It seems to me that if you have to wrap a function in a 'proc' object in order to assign it to a variable, then your functions are second-class citizens. Something else I would expect to be able to do in a language that supports first class functions:
def f(x)
x+4
end
g = f
g(2)
This doesn't work in ruby either. You can't assign a function using = (the normal assignment operator), you have to use def, or wrap the function in an object. That's not first-class.88.96.214.6 12:26, 20 March 2007 (UTC)