Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.lisp
Subject: Re: Why aren't CL functions 1st class objects?
Message-ID: <3806@goanna.cs.rmit.oz.au>
Date: 24 Sep 90 08:32:42 GMT
References: <1990Sep13.202219.21047@oracle.com> <3437@skye.ed.ac.uk>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 26

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.

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.

What's C missing?  The ability to create (possibly) new functions at run time.
From another perspective, *closures* as 1st-class values.  In T I can
	(define (o f g) (lambda (x) (f (g x)) ))
and then
	((o car cdr) '(1 2 3)) ==> 2
In C, I cannot do this.  Seems like an important difference to me.

-- 
Heuer's Law:  Any feature is a bug unless it can be turned off.