[groovy2shoes]

From TFWikipedia: "Some programming language theorists require support for anonymous functions (function literals) as well."

I suppose I wasn't aware that that wasn't a universal requirement, but count me in with that group. I think it's useful to make a distinction between "higher-order" and "first-class" for this very reason (i.e., we can talk about languages that do make a distinction without resorting to overloaded terms).

I mean, consider a language where this is the case:

  > "hello," .. " world"
  ==> "hello, world"

  > 2 + 2
  ==> SYNTAX ERROR

  > def a = 2
  ==> #<number "a">

  > a + a
  ==> 4

Would you consider such a language to have first-class integers?

Sort of on a tangent, but while I'm reminded of it: as far as Python's "lambdas" go, they're brutally gimped compared to Python's notion of a function, since what is allowed (and even required) of a function body in Python is much different than what is allowed of a "lambda" body.

[ScottBurson]

> Would you consider such a language to have first-class integers?

Yes, I still would, because integers can be bound to variables, passed to and returned from functions, and stored in fields of objects.

I would think that the language had a silly syntactic restriction -- which is the same thing I think about Python -- but it wouldn't materially change how I would write programs. It's just that, before any expression using an integer literal, I would have to name the literal.

Well, same here. If you want to use a function too complicated to fit in Python's restricted lambda expression syntax, you have to use a named local function. I agree that it's silly, and I'd never design a language like that myself, but again it wouldn't materially change how I write programs -- it just means that what would have fit in one expression would now, in some cases, require multiple statements.

Trying to draw a fine distinction between "higher-order" and "supporting first-class functions" doesn't appeal to me; I think of the latter as the definition of the former. (I'm sure I would have trouble remembering which was supposed to be which.)

But again, I have no problem with criticizing the design decision -- just not using these terms :-)

[groovy2shoes]

Here's the thing, though: when some element of a language is subject to silly restrictions that other first-class elements of the language are not subject to, that element is, by definition, second-class. The reason being that you can't treat it the way you'd treat any other first-class element.

[ScottBurson]

I see where you're coming from, but still, after the function value is created, there's no restriction on its use. Contrast what some call second-class continuations, which can be invoked only once -- a much more severe restriction.

I could see saying something like, Python functions are semantically first-class but syntactically second-class. Or maybe we should just call them "business-class" :-)

(BTW your comment downthread about referential transparency is spot-on.)

[groovy2shoes]

"Business-class" -- I like that!

And I also see (now) where you're coming from. But it's hard for me to accept the "once the value has been created" exception, because in my mind the construction of a value is as important as any other operation on that value.

Anyway, I'm not going to argue this any further -- I think we understand each other's perspective and we can pretty much resolve to chalk this one up to the (rather unfortunate, imo) lack of precision that's so common to terminology in computation science (see also: any debate whatsoever about types ;) ).