🚀 go-pugleaf

In article <1991Apr23.032208.3264@news.cs.brandeis.edu> bs@chaos.cs.brandeis.edu (Benjamin Schreiber) writes:
>Closures are an excelant idea.  However, I think that they should be
>kept distinct from pointers to functions and pointers to member functions.
>My primary argument for keeping them distinct from normal pointers to
>functions has to do with functions of "C" linkage: if yoou attempt to
>give it a closure, it will choke.

Thanks for mentioning this; it's a serious problem that I hadn't fully
addressed.  It was part of the reason why I mentioned the possibility
that the closure types might be kept distinct, but the issue clearly
needs more discussion than I gave it.

(Note, by the way, that it would not make sense to propose, and I am
not proposing, that closures and pointers to *member* functions should
become the same thing.  -- The previous sentence demonstrates what a
mess some of this terminology has become!  "Pointers to members" not
only aren't pointers, but they aren't the same things as pointers that
point to members!  "Member pointers" would be a slightly better term;
as someone else has pointed out (so to speak), "member offsets" would
be even better.  So, let me say that again: I am not proposing that
closures and member function offsets become the same thing; that would
not make sense.)

The issue you raise comes up only when one tries to mix C-compiled
code and C++-compiled code in the same program.  Even if pointers to
functions became closures, a conforming ANSI C program which was
entirely compiled by a C++ compiler would still work (at least in this
particular respect); all that would happen is that the objects it
declared as pointers to functions would get larger.

However, in the mixed compilation case, the problems do, admittedly,
get fairly nasty, because pointers to functions wind up with different
sizes in C and C++.

I don't suppose C compiler vendors would be real enthusiastic about
provide "C++ compatibility mode", either.

So even though, from the point of view of elegance, I would much
prefer that pointers to functions become closures, this is a pretty
strong argument for keeping them distinct.

>If the  concepts are indeed kept distinct, a clearly distint syntax is
>necessary.  My suggestion would be to use a unary && (an extention of
>taking the address of a function).  This operator would also be used
>in the declaration.

Forgive me, but: yuck.

It seems to me that no distinct syntax is required for closure
creation or invocation.  We simply 1) say that the value of a member
function, with or without the `&', is a closure, and 2) define a
built-in conversion from function pointers to closures (but not the
other way!).  Then you write the same thing in either case, and which
one you get depends properly on context.  Since there's no automatic
conversion from closures to function pointers, one of the four cases
is an error, but the other three work fine.

That leaves us with the question of declaration syntax.  Hmm...  Well,
even though I think it's ugly, there is precedent for the use of the
`&' in place of the `*' in a declarator to declare "something sortof
like a pointer".  (Though I wouldn't want to use `&&'.)  Geez, I'm
really not too crazy about this but I can't think of anything better
offhand.  That leaves us with:

  class Foo {
    public:
       int f();
  };

  int g();

  bar()
  {
       int (&cl)(), (*pf)();
       Foo foo; 
       pf = g;               // okay
       pf = &g;              // likewise for this form
       cl = g;               // also okay
       cl = foo.f;           // also okay
       pf = foo.f;           // error!
       pf = (int (*)()) foo.f;
            // probably legal, but will crash when pf is invoked
  }

>If you don't want to take me seriously, you don't have to; I'm only an
>undergraduate with an enthusiasm for C++.

Oh, don't worry, even if you weren't an undergraduate, I could still
decline to take you seriously.

-- Scott
Gyro@Reasoning.COM