Xref: utzoo comp.object:581 comp.lang.c++:5800
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Continuations
Message-ID: <11049@goofy.megatest.UUCP>
Date: 6 Dec 89 03:13:03 GMT
References: <1713@odin.SGI.COM>
Organization: Megatest Corporation, San Jose, Ca
Lines: 62

From article <1713@odin.SGI.COM>, by shap@delrey.sgi.com (Jonathan Shapiro):
> In article <10008@june.cs.washington.edu> peterd@june.cs.washington.edu (Peter C. Damron) writes:
>>4. C and C++ have first class functions.  Functions can be passed as
>>   parameters, returned as function values, and assigned to variables.
> 
>>Hope this helps to clear up any mis-understandings,
>>Peter.
> 
> Actually, Peter, it creates one.

Oh, gimme a break. I think the only misunderstanding is in the definition
of the value-charged adjectival phrase, "first class". If by "first class",
you mean "variable", then C's function-names are not "first class", but that
certainly does not make them second or third class! For most purposes,
constant-names for functions are to be prefered over function-valued variables.

>  C and C++ do not have fist class
> functions.  Functions cannot be passed as values.  Function pointers
> can, whcih is a somewhat different thing.  To be first class, it must
> be possible to treat functions as *values* rather than as *labels*.

What is a function's "value", if not a label?  What other candidates
are there? The only issue here is whether the name always refers to the
same function: Is the name effectively a label, or does it refer to a
variable which can contain any of a number of different labels? That is
the choice.

There are benefits to constant function-names. I can recall some awful,
XDR-related debugging sessions, struggling to figure out whether this or
that function-variable was bound to this or that procedure. It's best to
use constants when possible, reserving the use of variables for the
few occasions when they are really needed. Besides, on most machines, the
procedure call will be quicker if the name is a constant, resolved by
the linker, rather than at runtime.

> For example, the following is a syntax error:
> 
> int foo(int);
> int bar(int);
> 
> foo = bar
> 
> If functions were first class, this would be altogether legal.
> 

Then we would have to add something like ...

   constant int foo(int);

... to recover the lost functionality. I would much prefer that
function-names be constants in the default case.

Here's how you can have it both ways, constants and variables, in
plain old K&R C.

  extern int bar();    /* "bar" names an external constant. */
  int (*foo)();        /* "foo" names a variable. */

  void foozle()
  {
     foo = bar; /* What could be simpler? */
  }