Talk:First-class object

From Wikipedia, the free encyclopedia

Overheard:

> While you can't create new functions and unbound methods in C++ at
> runtime,
> you can take their address and pass that around as a first class
> object. 

True, though that usually devolves into a semantic issue about whether
functions are first-class if you can only manipulate pointers to them. 
I usually say C has first-class functions if you squint.  C++ doesn't
have first-class bound member function pointers, as you point out, and
another obvious example in C++ is the lack of first-class classes -- a
feature in Python that is extremely powerful, since it almost makes the
"factory" pattern automatic in Python (the class object itself is just a
callable type that creates instances).

[link]

Not being a programmer, I am not sure what to make of this in regards to the statement in the article relating to C not having first class functions... --Lenehey 22:59, May 4, 2005 (UTC)

I think this just means -- as far as C goes -- that while the functions themselves aren't first-class, you can usefully refer to them with objects that are first-class, which means that you get most of the "first-class-ness" except the creatability. C++ still doesn't allow the creation of new functions, but with templating and/or operator overloading, it's possible to create new objects that both syntactically and semantically act like closures of existing functions at runtime and thus get a bit closer to "real" first-class functions. I'll rewrite the statement to say something about this. --Tardis 21:26, 20 July 2005 (UTC)

Just goes to show that "First class object" is a loaded term. There's nothing about C functions that isn't "First Class". They're not pretty to work with, but that's an entirely seperate issue. A pointer to a function is an identity seperate from its name. That it doesnt need to have extra arbitrary information on top of it to be useful doesn't make it any less useful. Perhaps to be "first class", an object needs to be alterable using the same type of language syntax used to initially create it? I've been trying to understand what Lispers are going on about. --vstarre 21:54, 31 January 2007 (UTC)

Also, C++ does not support closures, which I find an important tool. Not sure if that is a requirement to first-class functions or not. --Spoon! 02:36, 1 September 2006 (UTC)

[edit] Is it is, or is it aint?

The article basically defines a first-class object as an entity which can be used in programs without restriction (when compared to other kinds of objects in the same language), in the context of a particular programming language.

And then gives this a a list of possible usages for a first-class object:

1. being expressible as an anonymous literal value
2. being storable in variables
3. being storable in data structures
4. having an intrinsic identity (independent of any given name)
5. being comparable for equality with other entities
6. being passable as a parameter to a procedure/function
7. being returnable as the result of a procedure/function
8. being constructable at runtime

Now isn't this too loose? I've got some problems or at least questions about at least two of these;

1 - It's not clear to me that being able to construct an object with a literal is a pre-requisite. I'm taking literal here in the common sense that there is a syntax which the compiler understands to construct an instance/data value at compile time. This really excludes way too many objects, I think.

5 - I'm not sure what this means. Maybe if we mean identity comparison, but to my mind equality usually has to do with some kind of 'state' equivalence, and not all first-class objects are so comparable.

Is there a reference to the source of this list? or did it just come about here?

Since it's often a topic of dispute whether or not a programming language supports certain constructs as first-class, I'm troubled that this definition seems to make things so language dependent. Since, C doesn't allow functions to be constructed at run-time, BUT the definition is language dependent, we might as well say that functions in C are first class. But are they? --Rick 14:59, 23 August 2006 (UTC)

The definition has to allow for the wide range of things that can and can't be done with values considered unarguably first-class in a language - for example, a language might not have any literal forms and might not support equality on 'most' values (Haskell, for example, only allows equality on types belonging to the Eq class, which is just a typeclass like any other). In comparison, being at least as constructable at run-time as numbers (computing 1+1 constructs 2, for example) is a hard and fast requirement in any turing complete language, as it's impossible to have a language that's turing complete but won't encode constructing new natural numbers in some shape or form.86.10.90.136 (talk) 15:19, 8 December 2007 (UTC)

C doesn't allow structures to be defined at runtime, but it does allow you to make new ones to your heart's content. The same should hold true for functions -- and indeed, in C one may multiply function pointers without limit. Intuitively, however, this misses the point. There's something Haskell, O'Caml and even Python all offer here, that C doesn't -- closures. In C, you can not rebind the free variables in a function, make a pointer to it and pass it around. -jsnx (talk) 05:06, 9 December 2007 (UTC)

C does allow structure values to be defined and passed around at runtime since at least ANSI 89. They are first class. This has nothing to do with the definition of structure types. Also, function pointers are first-class, but they aren't functions. Indeed, C does not have first-class functions precisely because it does not have closures - they are the standard implementation technique for first-class functions. 77.11.133.252 (talk) 09:13, 9 December 2007 (UTC)

To illustrate the point about closures, I would have a hard time considering a language to have first-class functions if it does not have the ability to write versions of the K combinator. (It doesn't have to have polymorphism, but it should be possible to write a version of the combinator for each combination of input types). That is to say, you should be able to write a unary function K which returns unary functions, such that if you store the return value of K(x) in a variable, and then later apply that variable to an argument, you will always get back the original x. C's function pointers don't give you the natural ability to do this. -Chinju (talk) 01:39, 16 December 2007 (UTC)

I would really like to see more citations in this article. It seems to me that the text here is really just hypothesis and conjecture rather than hard facts. --Boyton 13:47 24 September 2007 (UTC) —Preceding unsigned comment added by Boyton (talk • contribs)