Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Why aren't CL functions 1st class objects?
Message-ID: <3450@skye.ed.ac.uk>
Date: 25 Sep 90 20:07:07 GMT
References: <1990Sep13.202219.21047@oracle.com> <3437@skye.ed.ac.uk> <3806@goanna.cs.rmit.oz.au>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 81

In article <3806@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>In article <3437@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>>    - All objects can be the arguments of procedures.
>>    - All objects can be returned as the results of procedures. 
>>    - All objects can be the subject of assignment statements.
>>    - All objects can be tested for equality.

>As far as I'm aware, "modern" "functional" languages like ML and Haskell
>do not define equality for functions (or for data types that contain
>functions as elements).  I think that the Haskell people would be very
>upset if you told them functions weren't 1st class in Haskell.

And no doubt they wouldn't be very happy with the assignment clause
either.

To some extent, different languages have different notions of "first
class".  If there's no assignment, for example, it doesn't make much
sense to say 1st-class values have to be subject to it.

However, I'm not trying to find the One True Definition of
"1st-class", just noting that functions in Common Lisp do satisfy a
number of definitions that were not cooked up just to discredit
Common Lisp and that any definition that does show Common Lisp
not to have 1st-class functions needs some independent justification.

Indeed, let's try another one.  A somewhat different definition of
"1st-class" was given by Will Clinger in his "Semantics of Scheme"
article in the February 1988 issue of Byte:

  All Scheme objects are endowed with certain inalienable rights:

    - Objects have the right to remain anonymous.
    - Objects have an identity that is independent of any
      names by which they may be known.
    - Objects can be stored in variables and data structures
      without losing their identity.
    - Objects may be returned as the result of a procedure call.
    - Objects never die.

This too is true of functions in Common Lisp (with a possible quibble
on identity as in the FLET and EQ example in my previous article).

>However, there is something clearly wrong with this list, because C can
>satisfy it, and functions aren't first-class in C.  In C, a pointer to
>a function can be passed to a procedure, returned from a procedure,
>assigned to a variable, or compared for equality to another pointer of
>the same type.

This argument concerns pointers to functions rather than functions,
but I think that's fair because in Lisp, after all, everything is
essentially a "pointer to".  It's just that, since this is true of
everything, we get to factor it out.

>What's C missing?  The ability to create (possibly) new functions at
>run time.  From another perspective, *closures* as 1st-class values.

I think you are right.  However, someone in a later message says:

   That's not enough.  There is no ability in Lisp to create "new"
   integers at run time; conceptually all the integers already exist.
   Ditto with all the characters.

Perhaps that is the right way to think of integers and characters,
but there is still a difference between a language in which the
number of functions is known at compile time and a language where
that is not the case.

When related issues have come up in the past, some people have argued
that new functions aren't created in Lisp: all of the code was always
there (modulo EVAL, LOAD, and friends) even when "different" closures
are created.  This seems a somewhat strange way to look at it, at
least to me, because you can certainly return functions that give
different values for the same arguments, and if those aren't different
functions I don't know what is.

Anyway, I don't feel up to arguing about this right now, except to say
that, somewhere in there, we can find a significant difference between
languages such as Scheme, Common Lisp, ML, etc. and languages such as
C.

-- Jeff