Issue GENERIC-FLET-POORLY-DESIGNED Writeup

Status:         Proposal DELETE accepted 12/91

Issue:          GENERIC-FLET-POORLY-DESIGNED

References:     CLtL2 p.844-846

Related issues: WITH-ADDED-METHODS

Category:       CHANGE

Edit history:   22-Aug-91, Version 1 by Barmar

                10-Sep-91, Version 2 by Barmar - minor RPG-suggested

                           changes

                10-Jan-92, Version 3 by Barrett - remove GENERIC-FUNCTION,

                           per X3J13 ammendment

                10-Feb-92, Version 4 by Barrett - put back GENERIC-FUNCTION

                           symbol mistakenly removed; fix Current practice


Problem description:


  Very few, if any, CLOS implemementations implement GENERIC-FLET and

  GENERIC-LABELS.


Proposal (GENERIC-FLET-POORLY-DESIGNED:DELETE):


  Remove the operators GENERIC-FLET, GENERIC-LABELS, and GENERIC-FUNCTION from

  the language.  Delete the symbols GENERIC-FLET and GENERIC-LABELS from the

  COMMON-LISP package.


Rationale:


  The current form of lexical generic functiona is inadequate for

  general use, and therefore there is no existing compelling reason to

  retain them. Because they are poorly designed, it would be better to

  remove them from the language hoping for research and better designs

  than to prejudice the case for them by retaining a bad design.


  The symbol GENERIC-FUNCTION is retained because it also names a class.


Current practice:


  Apple Macintosh Common Lisp 2.0 provides the listed operators.


  Lucid CL 4.0 and Symbolics Genera 8.1 both export GENERIC-FLET and

  GENERIC-LABELS from their CLOS packages, and Lucid imports it into

  the implementation-dependent package that USER inherits from.  Neither

  of them defines them, though.


  Preliminary Symbolics Genera 8.2 and Chesnut Lisp-to-C Translator 2.0

  provided the listed operators at the time of the December meeting.  Since

  then they have deleted from both implementations, in deference to the

  committee's decision.


  Symbolics CLOE does not provide them.


Cost to Implementors:


  Very little.  For many implementors, no work at all is involved.

  Any implementors that export these symbols from COMMON-LISP will have

  to change their package specification, but that's it.


Cost to Users:


  Since this is a new feature that not everyone implements, programs

  that use them are not currently portable, so there should be little

  effect on users.


Cost of non-adoption:


  It will probably take longer for complete CLOS implementations to

  appear.


Performance impact:


  None.


Benefits:


  See Esthetics and Cost of non-adoption.


Esthetics:


  Since no one really understands what these special forms are for, this

  clearly simplifies the language.


Discussion:


  From RPG:


    The reason that lexical generic functions are relatively less useful

    than lexical functions is that with a generic function you are

    expecting that someone will extend it when they extend the ontology of

    the world, and you want to get a hold of those extensions for free.

    The mechanism for the for-freeness is the global namespace for generic

    function names. When you make those names lexical you lose this

    feature. Presumably this is the primary nice feature of OOP.

    

    The use of lexical generic functions is to create private operations

    within a scope, which can be larger than the scope of a function. The

    purpose of generic-flet/labels is to allow folks to write these

    private functions. The point of with-added-methods was to allow these

    local functions to be extended within the larger lexical scope. 

    

    With-added-methods had the flaw that it did not allow one to extend a

    global generic function within its dynamic extent, which I believe was

    the intent of its proposer. That is, it couldn't be used to add a

    method to a generic version of print such that that extended version

    would be used by all free references to it dynamically within the

    extent of the with-added-methods.

    

    Still, it had a use within the scenario I outlined above.

    

    The real flaw with the whole design is that one would like to have

    lexical class definitions, which would render lexical generic

    functions more useful, because then the lexical environments provide a

    possible worlds mechanism. So, one would like to create an environment

    with a locally extended hierarchy within which the lexical generic

    functions are used.

    

    A minor flaw with lexical generic functions are specified is their

    stupid syntax. If I were in a catty mood, I would ascribe the bad

    syntax.

    

    I believe there are a number of other operations one would like to

    perform with generic functions that are now not possible, such as

    explicitly combining separately defined generic functions. This along

    with lexical generic functions would allow people to do

    encapsulation.  But that's another story.

    

    Right now I would advocate removing lexical generic functions so that

    someone can do a proper design.


  Barmar:


    What about GENERIC-FUNCTION?  If lexical generic functions are

    useless, maybe anonymous ones are as well.