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



Forum: X3J13 Letter Ballot

References: ISO SC22/WG16 Committee Draft

Category: CHANGE

Edit history: 16-Jun-93, Version 1 by Pitman

Status: Proposal ADD-SUBSTRATE passed 8-3 on letter ballot 93-304.

Problem Description:

The ISO specification for ISLISP contains features which cannot be

straightforwardly implemented in ANSI Common Lisp, but that with

minor changes could be.


1. Add a new macro:

DEFINE-SYMBOL-MACRO name form [Macro]

Globally defines a symbol macro named <name> which expands

to <form>.

2. Add a new macro:

LAMBDA lambda-list &body declarations-and-forms [Macro]

The form (lambda ...) is shorthand for #'(lambda ...).

Test Case:

Sample code to better illustrate the issue goes here.


This makes it possible to implement ISO's ISLISP dialect entirely

in portable code.

1. DEFINE-SYMBOL-MACRO can be used to define global lexicals,

by having a global lexical be a symbol macro that expands

into a reference to a globally allocated cell that is not

subject to dynamic binding.

DEFINE-SYMBOL-MACRO can also be used to define the ISLISP

notion of a compiler constant, which is a variable that

cannot be assigned but that CAN be bound. The implementation

is the same as for global lexicals, except that the expansion

form is not SETF-able.

2. A LAMBDA, although conceptually trivial, cannot be defined by

users because issue LISP-SYMBOL-REDEFINITION places restrictions

on users' ability to add definitions to symbols in the CL package.

Also, each of these features is independently useful in its own right.

1. DEFINE-SYMBOL-MACRO has been requested by some users.

For example, see Public Review comment Pitman #10.

Some users have also requested global lexicals,

especially those from the Scheme community.

For example, see Public Review comment Loosemore #30.

Some users have also requested ISLISP-style constants,

especially those from the Eulisp community.

For example, see Public Review comment Dalton #4.

2. A LAMBDA macro has been requested by many users,

especially, but not at all exclusively, those from the

Scheme and Eulisp communities.

Issue LAMBDA-FORM previously failed before this committee,

however at a time when the compatibility issue with other

Lisp standards was not as great a concern. It's appropriate

that the concept be reconsidered again here in this new light.

Current Practice:

1. Symbolics Genera provides DEFINE-SYMBOL-MACRO as an

implementation-depednent extension.

2. Symbolics Genera has long provided a LAMBDA macro, which was

permitted as an extention under CLtL, but not the dpANS. Users

were upset when this was not only taken away from them, but they

were forbidden from creating it anew. (It's quite a complicated

symbol to be shadowing.)

Most Lisp dialects don't provide a LAMBDA macro since doing so

would be a violation of the spec.

Cost to Implementors:

1. Relatively small.

2. Very small.




Cost to Users:

1. None. (This change is upward compatible.)

2. Very small. (Mostly the need to remove any compatibility definition

they might already have, in spite of warnings that they should not

have such a thing.)

Cost of Non-Adoption:

The relation of ANSI CL to ISLISP would be difficult to explain. Neither is

a subset of the other, so they would appear as competing dialects and it might

be a hassle for some vendors to explain off the lack of coordination.


If we can say that ANSI CL is capable of implementing ISLISP,

then ISLISP becomes a substantially reduced threat in some situations.

Editorial Impact:

Relatively small.

1. Changes to the description of how symbol macros are processed.

A new dictionary entry for the DEFINE-SYMBOL-MACRO macro.

2. A new dictionary entry for the LAMBDA macro.


1. Having DEFINE-SYMBOL-MACRO as a companion to SYMBOL-MACROLET seems

to make things simpler to explain, since users often expect there

to be both definers and binders for things in the environment.

2. People are mixed on the aesthetics of this:

- Some people think a LAMBDA form is massively more aesthetic.

- Some people think LAMBDA is something primitive, not something

to be layered on as an afterthought with macro technology.

- Some people think having both (LAMBDA ...) and #'(LAMBDA ...)

is extra baggage that look silly.

- Some people think having both (LAMBDA ...) and #'(LAMBDA ...)

provides expressional flexibility to two camps who won't be

content to settle on a single solution.

- Some people think having (LAMBDA ...) brings them uncomfortably

close to having to fight the Lisp1/Lisp2 battle over again.

- Some people think having (LAMBDA ...) only makes sense in the

Lisp1 context.

- Some people think having (LAMBDA ...) ameliorates one of the

aggravating problems seen by Lisp1-fans, which is the need to

write #' in front of things. It doesn't get rid of all of them,

but it does get rid of many.

- Some people think that not having to write #'(LAMBDA ...) may

lead to further confusion down the road in understanding why the

car of a form is treated differently than other parts of the form.

There is not likely to be consensus from an absolute point of view

on this. It is clear that there is no way to optimize aesthetic

criteria related to LAMBDA in a way that satisfies everyone.

Pitman thinks this means that people should prefer to add the macro

since it permits maximal flexibility of style to users at extremely

low cost to implementors.


This comment addresses the following Public Review comments:

Dalton #4

Pitman #10

Pitman #32

Loosemore #30

Pitman strongly supports this proposal.

The data for this proposal was generated from an experiment:

As a test, since the dialects were similar, Pitman implemented an

approximate version of ISLISP in Common Lisp. The exercise took

only a few hours to code up. In a few places, Pitman had to use

implementation-specific techniques to compensate for missing

functionality. The items mentioned in this proposal are the things

he would have needed in Common Lisp in order not to have needed

implementation-specific substrate.

It's arguable that things like QUASIQUOTE, UNQUOTE, and

UNQUOTE-SPLICING should appear in this proposal as well. However,

technically, those can be written straightforwardly in CL, so they

were omitted for reasons of minimalism in order to improve the

likelihood of this passing. However, we might want to seriously

consider them separately since they did get mentioned in other Public

Review comments as a compatibility issue for Scheme users.

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