EQ? on pointers to functions

[Perry Wagle <wagle%indiana.csnet@CSNET-RELAY.ARPA>]

re:  the great EEEK! (I mean EQ?) debate, or

  Is "(EQ? (call/cc (lambda (k) (k k))) (call/cc (lambda (k) k)))" true?

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

  The generic LISP semantics I carry around in my head says that if an
expression terminates, it returns a pointer.  The things pointers point to
have types (like "function", "integer", "string", etc).

  Therefore my functionality equations are meta Will Clinger's equations.
That is, where he has "integer", I have "pointer to integer".  As what I
deal with are pointers, my semantics are very simple if I ignore type.  I
can well imagine that Will's semantics wants to barf when it tries to
incorporate the wierdness of EQ? on its level.

  EQ? is very natural in my semantical domain.  I resist "flattening" as
then we get Pascal, where we can't talk about eval, interpreters, and all
those powerful meta tools that made LISP better.  Yeah, Pascal is simpler
and more tractable to our puny proof methods, but watching SCHEME backslide
to Pascal is horrifying to watch from here on the outside (I do CogSci).

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

  The problem is not that you shouldn't have the type "pointer to function",
but that the collapsing of the same or different texts at different times to
an identical pointer is very complex and potentially unpredictable to a user
(unlike symbol or number collapsing).  I don't see that this is cause to
spaz and declare EQ? undefined on pointers to functions, or to remove EQ?
altogether (?!?), as I can still write useful and correct programs that EQ?s
on pointers to functions.  (I use ASSQ a lot).

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

  Proposal:  Expressions that evaluate to a pointers to functions return
UNIQUE pointers.  How this is done is up to the implementation.  My
abstraction is that a function consists of a unique head, and a potentially
shared body.  The head might be a cons cell with some sort of unique
timestamp in the CAR and a pointer to the body in the CDR, or the head might
be a box pointing to the body; these two methods would allow EQUAL? to work
on functions.  Another way is the have the head be a "jump body" machine
instruction, but this would kill EQUAL?, though one could keep a pointer to
body in the type info of the function...

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

  Another proposal would be to be to have a way to tell the compiler that
"HEY!, this is a UNIQUE function, dammit!  Don't you dare try to point
something else here!".  This might be part of a more general facility to
prevent sharing of environment tails, etc.

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

  I am trying more to be provocative here than "here's the solution!"ish.