225 lines
12 KiB
HTML
225 lines
12 KiB
HTML
|
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
||
|
|
<HTML>
|
||
|
|
<HEAD>
|
||
|
|
<TITLE>CLHS: Issue ISO-COMPATIBILITY Writeup</TITLE>
|
||
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
||
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
||
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
||
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
||
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
||
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
||
|
|
<LINK REL=PREV HREF="../Issues/iss197_w.htm">
|
||
|
|
<LINK REL=UP HREF="../Issues/iss198.htm">
|
||
|
|
<LINK REL=NEXT HREF="../Issues/iss199_w.htm">
|
||
|
|
</HEAD>
|
||
|
|
<BODY>
|
||
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss197_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss198.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss199_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
||
|
|
|
||
|
|
<HR>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<H2>Issue ISO-COMPATIBILITY Writeup</H2>
|
||
|
|
|
||
|
|
<PRE><B>Issue:</B> <A HREF="iss198.htm">ISO-COMPATIBILITY</A><P>
|
||
|
|
<B>Forum:</B> X3J13 Letter Ballot<P>
|
||
|
|
<B>References:</B> ISO SC22/WG16 Committee Draft<P>
|
||
|
|
<B>Category:</B> CHANGE<P>
|
||
|
|
<B>Edit history:</B> 16-Jun-93, Version 1 by Pitman<P>
|
||
|
|
<B>Status:</B> Proposal ADD-SUBSTRATE passed 8-3 on letter ballot 93-304.<P>
|
||
|
|
<P>
|
||
|
|
<B>Problem Description:<P>
|
||
|
|
</B><P>
|
||
|
|
The ISO specification for ISLISP contains features which cannot be <P>
|
||
|
|
straightforwardly implemented in ANSI Common Lisp, but that with<P>
|
||
|
|
minor changes could be.<P>
|
||
|
|
<P>
|
||
|
|
Proposal (<A HREF="iss198.htm">ISO-COMPATIBILITY:ADD-SUBSTRATE</A>)<P>
|
||
|
|
<P>
|
||
|
|
1. Add a new macro:<P>
|
||
|
|
<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/m_defi_1.htm#define-symbol-macro"><B>DEFINE-SYMBOL-MACRO</B></A> name form [Macro]<P>
|
||
|
|
<P>
|
||
|
|
Globally defines a symbol macro named <name> which expands <P>
|
||
|
|
to <form>.<P>
|
||
|
|
<P>
|
||
|
|
2. Add a new macro:<P>
|
||
|
|
<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> lambda-list &body declarations-and-forms [Macro]<P>
|
||
|
|
<P>
|
||
|
|
The form (<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> ...) is shorthand for #'(<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> ...).<P>
|
||
|
|
<P>
|
||
|
|
<B>Test Case:<P>
|
||
|
|
</B><P>
|
||
|
|
Sample code to better illustrate the issue goes here.<P>
|
||
|
|
<P>
|
||
|
|
<B>Rationale:<P>
|
||
|
|
</B><P>
|
||
|
|
This makes it possible to implement ISO's ISLISP dialect entirely<P>
|
||
|
|
in portable code.<P>
|
||
|
|
<P>
|
||
|
|
1. <A REL=DEFINITION HREF="../Body/m_defi_1.htm#define-symbol-macro"><B>DEFINE-SYMBOL-MACRO</B></A> can be used to define global lexicals, <P>
|
||
|
|
by having a global lexical be a symbol macro that expands <P>
|
||
|
|
into a reference to a globally allocated cell that is not<P>
|
||
|
|
subject to dynamic binding.<P>
|
||
|
|
<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/m_defi_1.htm#define-symbol-macro"><B>DEFINE-SYMBOL-MACRO</B></A> can also be used to define the ISLISP<P>
|
||
|
|
notion of a compiler constant, which is a variable that<P>
|
||
|
|
cannot be assigned but that CAN be bound. The implementation<P>
|
||
|
|
is the same as for global lexicals, except that the expansion<P>
|
||
|
|
form is not SETF-able.<P>
|
||
|
|
<P>
|
||
|
|
2. A <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A>, although conceptually trivial, cannot be defined by <P>
|
||
|
|
users because issue <A HREF="iss214.htm">LISP-SYMBOL-REDEFINITION</A> places restrictions<P>
|
||
|
|
on users' ability to add definitions to symbols in the CL package.<P>
|
||
|
|
<P>
|
||
|
|
Also, each of these features is independently useful in its own right.<P>
|
||
|
|
<P>
|
||
|
|
1. <A REL=DEFINITION HREF="../Body/m_defi_1.htm#define-symbol-macro"><B>DEFINE-SYMBOL-MACRO</B></A> has been requested by some users.<P>
|
||
|
|
For example, see Public Review comment Pitman #10.<P>
|
||
|
|
<P>
|
||
|
|
Some users have also requested global lexicals, <P>
|
||
|
|
especially those from the Scheme community.<P>
|
||
|
|
For example, see Public Review comment Loosemore #30.<P>
|
||
|
|
<P>
|
||
|
|
Some users have also requested ISLISP-style constants,<P>
|
||
|
|
especially those from the Eulisp community.<P>
|
||
|
|
For example, see Public Review comment Dalton #4.<P>
|
||
|
|
<P>
|
||
|
|
2. A <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> macro has been requested by many users,<P>
|
||
|
|
especially, but not at all exclusively, those from the<P>
|
||
|
|
Scheme and Eulisp communities.<P>
|
||
|
|
Issue LAMBDA-FORM previously failed before this committee,<P>
|
||
|
|
however at a time when the compatibility issue with other <P>
|
||
|
|
Lisp standards was not as great a concern. It's appropriate<P>
|
||
|
|
that the concept be reconsidered again here in this new light.<P>
|
||
|
|
<P>
|
||
|
|
<B>Current Practice:<P>
|
||
|
|
</B><P>
|
||
|
|
1. Symbolics Genera provides <A REL=DEFINITION HREF="../Body/m_defi_1.htm#define-symbol-macro"><B>DEFINE-SYMBOL-MACRO</B></A> as an <P>
|
||
|
|
implementation-depednent extension.<P>
|
||
|
|
<P>
|
||
|
|
2. Symbolics Genera has long provided a <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> macro, which was<P>
|
||
|
|
permitted as an extention under CLtL, but not the dpANS. Users<P>
|
||
|
|
were upset when this was not only taken away from them, but they<P>
|
||
|
|
were forbidden from creating it anew. (It's quite a complicated <P>
|
||
|
|
symbol to be shadowing.)<P>
|
||
|
|
<P>
|
||
|
|
Most Lisp dialects don't <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> a <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> macro since doing so <P>
|
||
|
|
would be a violation of the spec.<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost to Implementors:<P>
|
||
|
|
</B><P>
|
||
|
|
1. Relatively small.<P>
|
||
|
|
<P>
|
||
|
|
2. Very small. <P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A> <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> (<A REL=DEFINITION HREF="../Body/03_dd.htm#AMwhole"><B>&WHOLE</B></A> FORM <A REL=DEFINITION HREF="../Body/03_da.htm#AMrest"><B>&REST</B></A> BVL-DECLS-AND-BODY)<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>DECLARE</B></A> (<A REL=DEFINITION HREF="../Body/d_ignore.htm#ignore"><B>IGNORE</B></A> BVL-DECLS-AND-BODY))<P>
|
||
|
|
`#',FORM)<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost to Users:<P>
|
||
|
|
</B><P>
|
||
|
|
1. None. (This change is upward compatible.)<P>
|
||
|
|
<P>
|
||
|
|
2. Very small. (Mostly the need to remove any compatibility definition<P>
|
||
|
|
they might already have, in spite of warnings that they should not<P>
|
||
|
|
have such a thing.)<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost of Non-Adoption:<P>
|
||
|
|
</B><P>
|
||
|
|
The relation of ANSI CL to ISLISP would be difficult to explain. Neither is<P>
|
||
|
|
a subset of the other, so they would appear as competing dialects and it might<P>
|
||
|
|
be a hassle for some vendors to explain off the lack of coordination. <P>
|
||
|
|
<P>
|
||
|
|
<B>Benefits:<P>
|
||
|
|
</B><P>
|
||
|
|
If we can say that ANSI CL is capable of implementing ISLISP, <P>
|
||
|
|
then ISLISP becomes a substantially reduced threat in some situations.<P>
|
||
|
|
<P>
|
||
|
|
<B>Editorial Impact:<P>
|
||
|
|
</B><P>
|
||
|
|
Relatively small.<P>
|
||
|
|
<P>
|
||
|
|
1. Changes to the description of how symbol macros are processed.<P>
|
||
|
|
A new dictionary entry for the <A REL=DEFINITION HREF="../Body/m_defi_1.htm#define-symbol-macro"><B>DEFINE-SYMBOL-MACRO</B></A> macro.<P>
|
||
|
|
<P>
|
||
|
|
2. A new dictionary entry for the <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> macro.<P>
|
||
|
|
<P>
|
||
|
|
<B>Aesthetics:<P>
|
||
|
|
</B><P>
|
||
|
|
1. Having <A REL=DEFINITION HREF="../Body/m_defi_1.htm#define-symbol-macro"><B>DEFINE-SYMBOL-MACRO</B></A> as a companion to <A REL=DEFINITION HREF="../Body/s_symbol.htm#symbol-macrolet"><B>SYMBOL-MACROLET</B></A> seems<P>
|
||
|
|
to make things simpler to explain, since users often expect there<P>
|
||
|
|
to be both definers and binders for things in the environment.<P>
|
||
|
|
<P>
|
||
|
|
2. People are mixed on the aesthetics of this:<P>
|
||
|
|
<P>
|
||
|
|
- Some people think a <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> form is massively more aesthetic.<P>
|
||
|
|
<P>
|
||
|
|
- Some people think <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> is something primitive, not something<P>
|
||
|
|
to be layered on as an afterthought with macro technology.<P>
|
||
|
|
<P>
|
||
|
|
- Some people think having both (<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> ...) and #'(<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> ...)<P>
|
||
|
|
is extra baggage that look silly.<P>
|
||
|
|
<P>
|
||
|
|
- Some people think having both (<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> ...) and #'(<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> ...)<P>
|
||
|
|
provides expressional flexibility to two camps who won't be <P>
|
||
|
|
content to settle on a single solution.<P>
|
||
|
|
<P>
|
||
|
|
- Some people think having (<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> ...) brings them uncomfortably<P>
|
||
|
|
close to having to fight the Lisp1/Lisp2 battle over again.<P>
|
||
|
|
<P>
|
||
|
|
- Some people think having (<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> ...) only makes sense in the<P>
|
||
|
|
Lisp1 context.<P>
|
||
|
|
<P>
|
||
|
|
- Some people think having (<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> ...) ameliorates one of the <P>
|
||
|
|
aggravating problems seen by Lisp1-fans, which is the need to<P>
|
||
|
|
write #' in front of things. It doesn't get rid of all of them,<P>
|
||
|
|
but it does get rid of many.<P>
|
||
|
|
<P>
|
||
|
|
- Some people think that not having to write #'(<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> ...) may<P>
|
||
|
|
lead to further confusion down the road in understanding why the<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/f_car_c.htm#car"><B>car</B></A> of a form is treated differently than other parts of the form.<P>
|
||
|
|
<P>
|
||
|
|
There is not likely to be consensus from an absolute point of view <P>
|
||
|
|
on this. It is clear that there is no way to optimize aesthetic<P>
|
||
|
|
criteria related to <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> in a way that satisfies everyone.<P>
|
||
|
|
<P>
|
||
|
|
Pitman thinks this means that people should prefer to add the macro<P>
|
||
|
|
since it permits maximal flexibility of style to users at extremely<P>
|
||
|
|
low cost to implementors.<P>
|
||
|
|
<P>
|
||
|
|
<B>Discussion:<P>
|
||
|
|
</B><P>
|
||
|
|
This comment addresses the following Public Review comments:<P>
|
||
|
|
Dalton #4<P>
|
||
|
|
Pitman #10<P>
|
||
|
|
Pitman #32<P>
|
||
|
|
Loosemore #30<P>
|
||
|
|
Pitman strongly supports this proposal.<P>
|
||
|
|
<P>
|
||
|
|
The data for this proposal was generated from an experiment:<P>
|
||
|
|
As a test, since the dialects were similar, Pitman implemented an <P>
|
||
|
|
approximate version of ISLISP in Common Lisp. The exercise took <P>
|
||
|
|
only a few hours to code up. In a few places, Pitman had to use<P>
|
||
|
|
implementation-specific techniques to compensate for missing <P>
|
||
|
|
functionality. The items mentioned in this proposal are the things<P>
|
||
|
|
he would have needed in Common Lisp in order not to have needed<P>
|
||
|
|
implementation-specific substrate.<P>
|
||
|
|
<P>
|
||
|
|
It's arguable that things like QUASIQUOTE, UNQUOTE, and<P>
|
||
|
|
UNQUOTE-SPLICING should appear in this proposal as well. However,<P>
|
||
|
|
technically, those can be written straightforwardly in CL, so they<P>
|
||
|
|
were omitted for reasons of minimalism in order to improve the<P>
|
||
|
|
likelihood of this passing. However, we might want to seriously<P>
|
||
|
|
consider them separately since they did get mentioned in other Public<P>
|
||
|
|
Review comments as a compatibility issue for Scheme users.<P>
|
||
|
|
<P>
|
||
|
|
</PRE>
|
||
|
|
<HR>
|
||
|
|
|
||
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
||
|
|
|
||
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
||
|
|
</BODY>
|
||
|
|
</HTML>
|