[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.