#

## 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.

Copyright 1996-2001, Xanalys Inc. All rights reserved.