Re: Solutions to Name/Object Mapping for Generic Functions

[Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>]

     THE PROBLEM AND PROPERTIES OF A GOOD SOLUTION
     
     
     The following are some possible solutions:
     
     1) The symbol function cell could be eliminated as a global object and
     the name to funcallable object mapping could be maintained within the
     environment, as is the case in Scheme.
     
     2) The generic function slot accessor functions could take an
     environment argument and return information accordingly. This 
     was the solution I believe Patrick proposed. 

     3) We could simply leave it up to implementors to supply these
     hooks, if they so choose.


If you are talking about name-to-generic-function mapping, 2 is not what
I have proposed.  Name-to-generic-function mapping shouldn't depend on
the metaclass protocol since it should behave the same as
name-to-regular-function.  Not being affected by the metaclass protocol,
it can be left to the implementation.  The hook should be specified
though.  If some implementations decide to ignore the environment,
that's fine.  Since the environment is going to be passed explicitly(see
Moon's reponse to my proposal), we either need a new primitive for that,
or change SYMBOL-FUNCTION to accept an environment argument.  A new
primitive for metaclass programmers is probably the best thing to do.
However I object to 3 since it will make serious metaclass programming
non portable.
     

Patrick.