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


Issue SETF-METHOD-VS-SETF-METHOD Writeup

Issue:        SETF-METHOD-VS-SETF-METHOD

Forum: Editorial

References: DEFINE-SETF-METHOD (CLtL, p106),

GET-SETF-METHOD (CLtL, p106),

GET-SETF-METHOD-MULTIPLE-VALUE (CLtL, p107),

"setf method" (27.1 Glossary, page 27-27, Draft 8.81)

Category: CHANGE

Edit history: 08-Mar-91, Version 1 by Pitman

15-Mar-91, Version 2 by Pitman (merge much discussion)

08-Apr-91, Version 3 by Pitman

(GET-SETF-EXPANDER => GET-SETF-EXPANSION, per X3J13)

Status: X3J13 passed option RENAME-OLD-TERMS on 10-3 vote, March 1991.

(Note that option +ADD-ACCESSOR was not voted upon,

and so it is not in effect.)

Problem Description:

The terms "@bold(setf) @italic(method)" and "@italic(setf method)"

mean two different things. The former means a CLOS method defined

using DEFMETHOD, which among other things might be used by SETF.

The latter means a macro-like entity defined by DEFSETF or

DEFINE-SETF-METHOD, data about which can be retrieved by

GET-SETF-METHOD[-MULTIPLE-VALUE].

Verbal confusion will almost surely result from the similarity of

these two terms.

Visual confusion will almost surely result if people don't happen to

notice the font, or to realize the important distinction which it

seeks to make.

Proposal (SETF-METHOD-VS-SETF-METHOD:RENAME-OLD-TERMS):

Rename DEFINE-SETF-METHOD to DEFINE-SETF-EXPANDER.

Remove GET-SETF-METHOD.

Rename GET-SETF-METHOD-MULTIPLE-VALUE to GET-SETF-EXPANSION.

Rename the glossary term "setf method" to "setf expander".

That is, a "setf expander" is a function which tells how to

store into a generalized reference.

Create a glossary term "setf expansion" to refer to the five

magic values returned by a "setf expander".

Clarify that the glossary term "setf method" is to be synonymous

with "SETF method" That is, a "setf method" is a CLOS method

named (SETF <something>).

Rationale:

Avoids massive terminological confusion.

Simplifies the language by promoting GET-SETF-METHOD-MULITPLE-VALUE,

the general purpose routine, into active duty and removing its

simpleton pal GET-SETF-METHOD.

Proposal (SETF-METHOD-VS-SETF-METHOD:+ADD-ACCESSOR):

Add a new function:

SETF-EXPANDER-FUNCTION name &OPTIONAL environment [Function]

If <name> has a SETF expander function (defined with DEFSETF or

DEFINE-SETF-METHOD), and the global functional binding of <name> is

not lexically shadowed within the <environment>,

SETF-EXPANDER-FUNCTION returns that function. Otherwise NIL is

returned.

A SETF expander function is a function which accepts two arguments,

the "place" form and an environment, and returns the five values

representing the SETF expansion for that "place".

SETF may be used with SETF-EXPANDER-FUNCTION. The value must either

be a SETF expander function or NIL (which removes any existing SETF

expander function associated with the <name>). [The consequences of

supplying an environment other than NIL when using SETF of

SETF-EXPANDER-FUNCTION are not defined.]

Rationale:

This is symmetric with having MACRO-FUNCTION and

COMPILER-MACRO-FUNCTION.

Current Practice:

Presumably no one already does this.

Cost to Implementors:

RENAME-OLD-TERMS: Small. Trivial renaming of functions.

Old names can be retained as an extension for compatibility

if necessary to ease transition.

+ADD-ACCESSOR: Probably small. Implementations have to represent

this information somehow already, so this just provides access to

what is already there.

Cost to Users:

RENAME-OLD-TERMS:

Small. It's clearly incompatible, but hopefully the motivation is strong

enough that users will realize that the change is needed. A simple

find-and-replace operation is likely to fix these, or compatibility names

can be trivially established locally by users for code that can't easily

be changed in implementations that don't already provide the compatibility

support for old names.

+ADD-ACCESSOR: None.

Cost of Non-Adoption:

Risk of a `fonto' in the spec causing major havoc.

Risk of implementors getting confused.

Risk of confusing new users.

Either some places in the spec could be harder to word unambiguously,

or else glossary terms might have to be chosen which do not match

function names in the language itself.

Benefits:

Much easier to have casual verbal discussions.

Aesthetics:

RENAME-OLD-TERMS: Major improvement in aesthetics.

+ADD-ACCESSOR: Language is slightly more uniform.

Discussion:

Pitman supports this proposal but is not fussy about the specific

term that's used as long as it's not the status quo (`method').

The terms "strategy", "technique", "macroexpander", "macro expander",

"expander", and "transformer" were discussed after v1. Eric Benson,

JonL, Sandra, and Pitman all seemed happy with "expander", so it

v2 was changed to use that.

There was also support (from Moon and Sandra) for merging

GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE back into one,

so v2 added that as well.

Sandra asked for SETF-EXPANDER-FUNCTION.


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