perm filename CLCLEA.2[COM,LSP] blob
sn#858556 filedate 1988-06-18 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00495 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00072 00002
C00073 00003 ∂28-Nov-87 0534 CL-Cleanup-mailer [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C00079 00004 ∂28-Nov-87 1105 CL-Cleanup-mailer Issue status
C00084 00005 ∂30-Nov-87 0921 CL-Cleanup-mailer [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C00087 00006 ∂30-Nov-87 1446 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
C00097 00007 ∂30-Nov-87 1733 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
C00099 00008 ∂30-Nov-87 1911 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
C00100 00009 ∂01-Dec-87 0025 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00102 00010 ∂01-Dec-87 0038 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
C00105 00011 ∂01-Dec-87 0100 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00108 00012 ∂01-Dec-87 0923 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00111 00013 ∂01-Dec-87 1042 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
C00113 00014 ∂01-Dec-87 1043 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
C00115 00015 ∂01-Dec-87 1102 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00126 00016 ∂01-Dec-87 1103 CL-Cleanup-mailer Issue: FUNCTION-TYPE-KEY-NAME
C00132 00017 ∂01-Dec-87 1201 CL-Cleanup-mailer Issue: FUNCTION-TYPE-KEY-NAME
C00136 00018 ∂01-Dec-87 1756 CL-Cleanup-mailer CL-CLEANUP membership
C00140 00019 ∂01-Dec-87 2016 CL-Cleanup-mailer introduction
C00142 00020 ∂01-Dec-87 2053 CL-Cleanup-mailer introduction
C00144 00021 ∂02-Dec-87 1008 CL-Cleanup-mailer Re: CL-CLEANUP membership
C00146 00022 ∂02-Dec-87 1119 CL-Cleanup-mailer Re: CL-CLEANUP membership
C00148 00023 ∂02-Dec-87 1202 CL-Cleanup-mailer intro
C00149 00024 ∂02-Dec-87 1421 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 4)
C00151 00025 ∂02-Dec-87 1422 CL-Cleanup-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
C00153 00026 ∂02-Dec-87 1528 CL-Cleanup-mailer intro
C00155 00027 ∂02-Dec-87 1941 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00158 00028 ∂02-Dec-87 2043 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00167 00029 ∂02-Dec-87 2146 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00171 00030 ∂02-Dec-87 2225 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00173 00031 ∂02-Dec-87 2236 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00175 00032 ∂03-Dec-87 0953 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00184 00033 ∂03-Dec-87 1042 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
C00187 00034 ∂03-Dec-87 1059 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00190 00035 ∂03-Dec-87 1059 CL-Cleanup-mailer CL-CLEANUP membership
C00192 00036 ∂03-Dec-87 1123 CL-Cleanup-mailer FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00194 00037 ∂03-Dec-87 1215 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00198 00038 ∂03-Dec-87 1331 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00204 00039 ∂04-Dec-87 1430 CL-Cleanup-mailer Issue: LAST-N (Version 1)
C00210 00040 ∂04-Dec-87 1449 CL-Cleanup-mailer Issue: LAST-N (Version 1)
C00212 00041 ∂04-Dec-87 1535 CL-Cleanup-mailer Issue: LAST-N (Version 1)
C00216 00042 ∂04-Dec-87 1729 CL-Cleanup-mailer Re: Issue: LAST-N (Version 1)
C00217 00043 ∂04-Dec-87 1729 CL-Cleanup-mailer Introduction
C00219 00044 ∂05-Dec-87 0001 CL-Cleanup-mailer Introduction
C00221 00045 ∂06-Dec-87 1424 CL-Cleanup-mailer Issue: DRIBBLE-TECHNIQUE (Version 1)
C00227 00046 ∂06-Dec-87 1435 CL-Cleanup-mailer Introduction
C00229 00047 ∂07-Dec-87 1643 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00231 00048 ∂07-Dec-87 2038 CL-Cleanup-mailer [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C00234 00049 ∂07-Dec-87 2310 CL-Cleanup-mailer introduction
C00236 00050 ∂07-Dec-87 2315 CL-Cleanup-mailer Issue: DRIBBLE-TECHNIQUE (Version 1)
C00239 00051 ∂07-Dec-87 2328 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00245 00052 ∂08-Dec-87 0021 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00249 00053 ∂08-Dec-87 0728 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00251 00054 ∂08-Dec-87 0857 CL-Cleanup-mailer Introduction
C00253 00055 ∂08-Dec-87 0937 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00257 00056 ∂08-Dec-87 0939 CL-Cleanup-mailer Re: Issue: DRIBBLE-TECHNIQUE (Version 1)
C00258 00057 ∂08-Dec-87 0948 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00266 00058 ∂08-Dec-87 1121 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00268 00059 ∂08-Dec-87 1123 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00274 00060 ∂08-Dec-87 1231 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00278 00061 ∂08-Dec-87 1334 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00280 00062 ∂08-Dec-87 1418 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00282 00063 ∂08-Dec-87 1620 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00285 00064 ∂08-Dec-87 1644 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00289 00065 ∂08-Dec-87 1828 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00291 00066 ∂08-Dec-87 1836 CL-Cleanup-mailer Introductions
C00293 00067 ∂09-Dec-87 0309 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00298 00068 ∂09-Dec-87 0702 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00300 00069 ∂09-Dec-87 0729 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION issues
C00305 00070 ∂09-Dec-87 0848 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00308 00071 ∂09-Dec-87 0955 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00313 00072 ∂10-Dec-87 2311 CL-Cleanup-mailer Cleanup issues from Japanese technical working group
C00326 00073 ∂15-Dec-87 1050 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00328 00074 ∂15-Dec-87 1128 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00331 00075 ∂16-Dec-87 1538 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (alternate proposal)
C00344 00076 ∂17-Dec-87 1736 CL-Cleanup-mailer Cleanup issues from Japanese technical working group
C00352 00077 ∂17-Dec-87 1740 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00354 00078 ∂17-Dec-87 1745 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00359 00079 ∂17-Dec-87 1757 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00361 00080 ∂17-Dec-87 1805 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION issues
C00364 00081 ∂17-Dec-87 1812 CL-Cleanup-mailer Cleanup issues from Japanese technical working group
C00369 00082 ∂17-Dec-87 1823 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION issues
C00372 00083 ∂18-Dec-87 1439 CL-Cleanup-mailer whether random objects self-evaluate (was cleaup issues from Japan)
C00376 00084 ∂18-Dec-87 1759 CL-Cleanup-mailer whether random objects self-evaluate (was cleaup issues from Japan)
C00378 00085 ∂21-Dec-87 1924 CL-Cleanup-mailer SETF-METHOD-FOR-SYMBOLS Issue
C00380 00086 ∂30-Dec-87 1625 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
C00385 00087 ∂30-Dec-87 1634 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
C00391 00088 ∂31-Dec-87 1126 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
C00393 00089 ∂31-Dec-87 1723 CL-Cleanup-mailer Releasing potentially confusing info to the CL community
C00398 00090 ∂31-Dec-87 1749 CL-Cleanup-mailer Re: Releasing potentially confusing info to the CL community
C00401 00091 ∂01-Jan-88 1245 CL-Cleanup-mailer New issue: FLET-DECLARATIONS
C00408 00092 ∂03-Jan-88 1322 CL-Cleanup-mailer cleanup status
C00413 00093 ∂03-Jan-88 1814 CL-Cleanup-mailer cleanup status
C00421 00094 ∂03-Jan-88 2012 CL-Cleanup-mailer cleanup status
C00425 00095 ∂04-Jan-88 0852 CL-Cleanup-mailer Re: cleanup status
C00428 00096 ∂04-Jan-88 1147 CL-Cleanup-mailer Re: New issue: FLET-DECLARATIONS
C00430 00097 ∂04-Jan-88 1309 CL-Cleanup-mailer Re: cleanup status
C00432 00098 ∂04-Jan-88 1832 CL-Cleanup-mailer &REST lists
C00436 00099 ∂04-Jan-88 2035 CL-Cleanup-mailer &REST lists
C00440 00100 ∂05-Jan-88 0521 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
C00453 00101 ∂05-Jan-88 0938 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
C00455 00102 ∂05-Jan-88 1345 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
C00458 00103 ∂05-Jan-88 1430 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
C00463 00104 ∂05-Jan-88 1458 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
C00466 00105 ∂05-Jan-88 1644 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
C00468 00106 ∂05-Jan-88 1922 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
C00470 00107 ∂05-Jan-88 1958 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
C00474 00108 ∂06-Jan-88 0736 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
C00477 00109 ∂06-Jan-88 1334 CL-Cleanup-mailer cleanup status
C00480 00110 ∂06-Jan-88 1414 CL-Cleanup-mailer cleanup status
C00485 00111 ∂06-Jan-88 1804 CL-Cleanup-mailer cleanup status
C00487 00112 ∂06-Jan-88 2034 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
C00493 00113 ∂06-Jan-88 2318 CL-Cleanup-mailer Issue: DECLARE-MACROS
C00497 00114 ∂06-Jan-88 2331 CL-Cleanup-mailer Cleanup status
C00503 00115 ∂06-Jan-88 2356 CL-Cleanup-mailer cleanup status
C00506 00116 ∂06-Jan-88 2358 CL-Cleanup-mailer cleanup status
C00508 00117 ∂07-Jan-88 0026 CL-Cleanup-mailer your proposed revision
C00514 00118 ∂07-Jan-88 0555 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
C00518 00119 ∂07-Jan-88 1224 CL-Cleanup-mailer your proposed revision
C00520 00120 ∂11-Jan-88 1150 CL-Cleanup-mailer paper for IWoLES
C00544 00121 ∂14-Jan-88 2023 CL-Cleanup-mailer [Jan Zubkoff <edsel!jlz@labrea.stanford.edu>: mailings]
C00546 00122 ∂14-Jan-88 2023 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 5)
C00554 00123 ∂14-Jan-88 2023 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
C00556 00124 ∂14-Jan-88 2024 CL-Cleanup-mailer Re: New issue: FLET-DECLARATIONS
C00558 00125 ∂14-Jan-88 2023 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
C00560 00126 ∂14-Jan-88 2045 CL-Cleanup-mailer Re: Issue: LAST-N (Version 1)
C00562 00127 ∂14-Jan-88 2054 CL-Cleanup-mailer Re: Issue: LOAD-TIME-EVAL (Version 3)
C00564 00128 ∂14-Jan-88 2111 CL-Cleanup-mailer Issue status: READY FOR LETTER BALLOT
C00571 00129 ∂14-Jan-88 2116 CL-Cleanup-mailer Issue status: PENDING
C00589 00130 ∂15-Jan-88 1056 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
C00591 00131 ∂15-Jan-88 1327 CL-Cleanup-mailer New, improved FUNCTION-TYPE-KEY-NAME proposal
C00597 00132 ∂15-Jan-88 1327 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00610 00133 ∂15-Jan-88 1450 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00612 00134 ∂15-Jan-88 1511 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00614 00135 ∂15-Jan-88 1516 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00617 00136 ∂15-Jan-88 1724 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00619 00137 ∂15-Jan-88 1724 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00622 00138 ∂15-Jan-88 1741 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00625 00139 ∂18-Jan-88 1618 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 2)
C00635 00140 ∂18-Jan-88 1831 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 2)
C00637 00141 ∂19-Jan-88 1539 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
C00643 00142 ∂21-Jan-88 0802 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00645 00143 ∂21-Jan-88 0810 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
C00650 00144 ∂26-Jan-88 1244 CL-Cleanup-mailer Issue: REMF-MULTIPLE
C00657 00145 ∂26-Jan-88 1307 CL-Cleanup-mailer Issue: EXPORT-IMPORT
C00663 00146 ∂27-Jan-88 0714 CL-Cleanup-mailer Issue: EXPORT-IMPORT
C00665 00147 ∂28-Jan-88 0424 CL-Cleanup-mailer Issue: EXPORT-IMPORT
C00667 00148 ∂03-Feb-88 0750 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
C00669 00149 ∂03-Feb-88 0755 CL-Cleanup-mailer Issue: EXPORT-IMPORT
C00671 00150 ∂03-Feb-88 0755 CL-Cleanup-mailer Issue: REMF-MULTIPLE
C00673 00151 ∂03-Feb-88 0756 CL-Cleanup-mailer New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2)
C00676 00152 ∂03-Feb-88 0757 CL-Cleanup-mailer Issue: FLET-DECLARATIONS (Version 2)
C00683 00153 ∂03-Feb-88 0757 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 4)
C00693 00154 ∂03-Feb-88 0757 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
C00711 00155 ∂03-Feb-88 0757 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal (Version 2)
C00713 00156 ∂03-Feb-88 0835 CL-Cleanup-mailer Issue: EXPORT-IMPORT
C00717 00157 ∂03-Feb-88 0951 CL-Cleanup-mailer Issue: EXPORT-IMPORT
C00721 00158 ∂03-Feb-88 1843 CL-Cleanup-mailer Issue: EXPORT-IMPORT
C00724 00159 ∂03-Feb-88 1844 CL-Cleanup-mailer Issue: EXPORT-IMPORT
C00727 00160 ∂03-Feb-88 1857 CL-Cleanup-mailer Issue: EXPORT-IMPORT
C00730 00161 ∂03-Feb-88 1945 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
C00738 00162 ∂03-Feb-88 2023 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
C00750 00163 ∂04-Feb-88 1529 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
C00762 00164 ∂04-Feb-88 1620 CL-Cleanup-mailer cover letter for issues mailing
C00767 00165 ∂04-Feb-88 1722 CL-Cleanup-mailer Cleanup committee meeting prior to X3J13
C00769 00166 ∂05-Feb-88 1241 CL-Cleanup-mailer Ready issues
C00776 00167 ∂05-Feb-88 1336 CL-Cleanup-mailer Re: Ready issues
C00777 00168 ∂05-Feb-88 2053 CL-Cleanup-mailer EXPORT-IMPORT and the other random commands
C00781 00169 ∂05-Feb-88 2056 CL-Cleanup-mailer {Improved version} EXPORT-IMPORT and the other random commands
C00786 00170 ∂07-Feb-88 1207 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00789 00171 ∂07-Feb-88 1224 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
C00792 00172 ∂07-Feb-88 1242 CL-Cleanup-mailer New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2)
C00795 00173 ∂07-Feb-88 1300 CL-Cleanup-mailer Re: {Improved version} EXPORT-IMPORT and the other random commands
C00799 00174 ∂07-Feb-88 1306 CL-Cleanup-mailer {Improved version} EXPORT-IMPORT and the other random commands
C00806 00175 ∂08-Feb-88 0901 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00808 00176 ∂08-Feb-88 1031 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
C00813 00177 ∂08-Feb-88 1033 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
C00815 00178 ∂08-Feb-88 1037 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 4)
C00817 00179 ∂08-Feb-88 1040 CL-Cleanup-mailer Issue: FLET-DECLARATIONS (Version 2)
C00819 00180 ∂08-Feb-88 1043 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
C00822 00181 ∂08-Feb-88 1051 CL-Cleanup-mailer Issue: FLET-DECLARATIONS (Version 2)
C00824 00182 ∂08-Feb-88 1058 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
C00829 00183 ∂08-Feb-88 1112 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
C00835 00184 ∂10-Feb-88 0203 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
C00845 00185 ∂10-Feb-88 0858 Common-Lisp-Object-System-mailer Status of SETF functions in Common Lisp
C00851 00186 ∂10-Feb-88 1007 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
C00859 00187 ∂11-Feb-88 1001 Common-Lisp-Object-System-mailer Re: Status of SETF functions in Common Lisp
C00862 00188 ∂11-Feb-88 1637 CL-Cleanup-mailer {Improved version} EXPORT-IMPORT and the other random commands
C00869 00189 ∂11-Feb-88 2044 CL-Cleanup-mailer Status of SETF functions in Common Lisp
C00873 00190 ∂12-Feb-88 0813 CL-Cleanup-mailer Package Odor
C00877 00191 ∂12-Feb-88 2337 CL-Cleanup-mailer Issue: SETF-SUB-METHODS
C00896 00192 ∂13-Feb-88 1333 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
C00905 00193 ∂13-Feb-88 1410 CL-Cleanup-mailer Issue FUNCTION-TYPE-KEY-NAME, Version 3
C00912 00194 ∂13-Feb-88 1428 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
C00921 00195 ∂13-Feb-88 1615 CL-Cleanup-mailer Issue: FUNCTION-TYPE (version 9)
C00950 00196 ∂13-Feb-88 1630 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
C00956 00197 ∂13-Feb-88 1640 CL-Cleanup-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
C00969 00198 ∂13-Feb-88 1713 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C00988 00199 ∂13-Feb-88 1720 CL-Cleanup-mailer New issues to be mailed to X3J13
C00993 00200 ∂13-Feb-88 1722 CL-Cleanup-mailer Old issues for confirmation at March X3J13
C00997 00201 ∂13-Feb-88 1726 CL-Cleanup-mailer Pending issues
C01011 00202 ∂13-Feb-88 1732 CL-Cleanup-mailer Withdrawn issues
C01015 00203 ∂13-Feb-88 1808 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C01018 00204 ∂15-Feb-88 0204 CL-Cleanup-mailer Common Lisp cleanup issue status to X3J13
C01021 00205 ∂15-Feb-88 0928 CL-Cleanup-mailer make-lexical-environment
C01025 00206 ∂15-Feb-88 0954 CL-Cleanup-mailer Re: make-lexical-environment
C01027 00207 ∂15-Feb-88 1634 CL-Cleanup-mailer Re: Issue: DO-SYMBOLS-DUPLICATES (Version 3)
C01028 00208 ∂15-Feb-88 1713 CL-Cleanup-mailer Re: Issue: FORMAT-COMMA-INTERVAL (Version 2)
C01031 00209 ∂16-Feb-88 0939 CL-Cleanup-mailer FUNCTION-TYPE:STRICT-REDEFINITION proposal
C01033 00210 ∂16-Feb-88 1139 CL-Cleanup-mailer Re: Issue: FORMAT-COMMA-INTERVAL (Version 2)
C01035 00211 ∂17-Feb-88 1159 CL-Cleanup-mailer two minor comments: DISASSEMBLE-SIDE-EFFECT & DRIBBLE-TECHNIQUE
C01037 00212 ∂19-Feb-88 1434 CL-Cleanup-mailer Re: FUNCTION-TYPE:STRICT-REDEFINITION proposal
C01040 00213 ∂22-Feb-88 1510 CL-Cleanup-mailer Volunteering
C01042 00214 ∂23-Feb-88 1115 CL-Cleanup-mailer function-type-rest-list-element
C01045 00215 ∂23-Feb-88 1115 CL-Cleanup-mailer compiler-warning-break
C01049 00216 ∂23-Feb-88 1414 CL-Cleanup-mailer function-type-rest-list-element
C01056 00217 ∂24-Feb-88 0715 CL-Cleanup-mailer RE: function-type-rest-list-element
C01066 00218 ∂24-Feb-88 1013 CL-Cleanup-mailer FUNCTION-TYPE:STRICT-REDEFINITION proposal
C01069 00219 ∂24-Feb-88 1459 CL-Cleanup-mailer function-type-rest-list-element
C01073 00220 ∂25-Feb-88 1047 CL-Cleanup-mailer function-type-rest-list-element
C01078 00221 ∂27-Feb-88 1818 CL-Cleanup-mailer function-type-rest-list-element
C01084 00222 ∂28-Feb-88 0807 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE
C01107 00223 ∂29-Feb-88 1357 CL-Cleanup-mailer function-type-rest-list-element
C01123 00224 ∂29-Feb-88 1553 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)
C01137 00225 ∂29-Feb-88 2001 CL-Cleanup-mailer function-type-rest-list-element
C01141 00226 ∂01-Mar-88 1009 CL-Cleanup-mailer function-type-rest-list-element
C01146 00227 ∂01-Mar-88 1102 CL-Cleanup-mailer sequence-functions-exclude-arrays (pardon msg duplication, if any)
C01150 00228 ∂01-Mar-88 1124 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)
C01156 00229 ∂01-Mar-88 1301 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
C01163 00230 ∂01-Mar-88 1310 CL-Cleanup-mailer function-type-rest-list-element (really array types)
C01169 00231 ∂01-Mar-88 1318 CL-Cleanup-mailer UPGRADE-ARRAY-ELEMENT-TYPE: a sloution for the array TYPEP problem?
C01175 00232 ∂01-Mar-88 1325 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
C01178 00233 ∂01-Mar-88 1445 CL-Cleanup-mailer function-type-rest-list-element (really array types)
C01181 00234 ∂01-Mar-88 1515 CL-Cleanup-mailer Compiler cleanup issues, again
C01185 00235 ∂01-Mar-88 1548 CL-Cleanup-mailer Compiler cleanup issues, again
C01187 00236 ∂01-Mar-88 1718 CL-Cleanup-mailer Re: Compiler cleanup issues, again
C01191 00237 ∂01-Mar-88 1749 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
C01195 00238 ∂01-Mar-88 1830 CL-Cleanup-mailer compiler "clean-up" issues
C01197 00239 ∂02-Mar-88 0545 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
C01202 00240 ∂02-Mar-88 0553 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
C01208 00241 ∂02-Mar-88 0821 CL-Cleanup-mailer Fair's Fair
C01210 00242 ∂02-Mar-88 1415 CL-Cleanup-mailer Compiler cleanup issues, again
C01214 00243 ∂02-Mar-88 1614 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
C01224 00244 ∂02-Mar-88 1757 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
C01228 00245 ∂02-Mar-88 2206 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
C01231 00246 ∂03-Mar-88 0825 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
C01235 00247 ∂03-Mar-88 1134 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
C01238 00248 ∂03-Mar-88 1204 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
C01242 00249 ∂03-Mar-88 1227 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
C01246 00250 ∂03-Mar-88 1453 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
C01251 00251 ∂03-Mar-88 1456 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
C01256 00252 ∂03-Mar-88 2155 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
C01263 00253 ∂04-Mar-88 0932 CL-Cleanup-mailer Re: Compiler cleanup issues, again
C01267 00254 ∂04-Mar-88 0940 CL-Cleanup-mailer Re: compiler-warning-break
C01270 00255 ∂04-Mar-88 1052 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
C01272 00256 ∂04-Mar-88 1140 CL-Cleanup-mailer Cleanup subcommittee meeting, Tuesday 15 March, 9:00-12:00
C01274 00257 ∂04-Mar-88 1304 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
C01276 00258 ∂04-Mar-88 1414 CL-Cleanup-mailer Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
C01278 00259 ∂06-Mar-88 1148 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
C01283 00260 ∂06-Mar-88 1203 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
C01292 00261 ∂06-Mar-88 1230 CL-Cleanup-mailer Not about Issue: LET-TOP-LEVEL (version 1)
C01304 00262 ∂06-Mar-88 1241 CL-Cleanup-mailer Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
C01309 00263 ∂06-Mar-88 1620 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
C01321 00264 ∂06-Mar-88 1935 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
C01323 00265 ∂07-Mar-88 0637 CL-Cleanup-mailer compiler-warning-break
C01327 00266 ∂07-Mar-88 0936 CL-Cleanup-mailer New issues for the "pending" list, from Japan
C01329 00267 ∂07-Mar-88 1030 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01336 00268 ∂07-Mar-88 1040 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01338 00269 ∂07-Mar-88 1043 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01340 00270 ∂07-Mar-88 1059 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01344 00271 ∂07-Mar-88 1206 CL-Cleanup-mailer Issue: LAMBDA-LIST-DUPLICATES (Version 1)
C01349 00272 ∂07-Mar-88 1232 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01356 00273 ∂07-Mar-88 1253 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01361 00274 ∂07-Mar-88 1257 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1)
C01367 00275 ∂07-Mar-88 1324 CL-Cleanup-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
C01372 00276 ∂07-Mar-88 1325 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1)
C01374 00277 ∂07-Mar-88 1326 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01376 00278 ∂07-Mar-88 1410 CL-Cleanup-mailer Are you coming to the cleanup meeting?
C01377 00279 ∂07-Mar-88 1719 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1)
C01379 00280 ∂07-Mar-88 2157 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01383 00281 ∂07-Mar-88 2216 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1)
C01386 00282 ∂08-Mar-88 0723 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01392 00283 ∂08-Mar-88 1126 CL-Cleanup-mailer Re: Are you coming to the cleanup meeting?
C01394 00284 ∂08-Mar-88 1319 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01397 00285 ∂08-Mar-88 1350 CL-Cleanup-mailer Issue: LAMBDA-LIST-DUPLICATES (Version 1)
C01399 00286 ∂08-Mar-88 1351 CL-Cleanup-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
C01401 00287 ∂08-Mar-88 1457 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01404 00288 ∂08-Mar-88 1712 CL-Cleanup-mailer [Now Macros, but formerly] Issue: LET-TOP-LEVEL (version 1)
C01406 00289 ∂09-Mar-88 1221 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01410 00290 ∂09-Mar-88 1248 CL-Cleanup-mailer Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
C01415 00291 ∂09-Mar-88 1710 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01418 00292 ∂09-Mar-88 1711 CL-Cleanup-mailer PROCLAIM [and "lexical scoping"?]
C01422 00293 ∂11-Mar-88 1031 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1)
C01428 00294 ∂11-Mar-88 1039 CL-Cleanup-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
C01431 00295 ∂11-Mar-88 1043 CL-Cleanup-mailer Issue: LAMBDA-LIST-DUPLICATES (Version 1)
C01434 00296 ∂11-Mar-88 1045 CL-Cleanup-mailer Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
C01438 00297 ∂12-Mar-88 1527 CL-Cleanup-mailer New issue: STEP-ENVIRONMENT
C01443 00298 ∂12-Mar-88 1600 CL-Cleanup-mailer New issue: DEFPACKAGE
C01451 00299 ∂12-Mar-88 1614 CL-Cleanup-mailer New issue: DEFPACKAGE
C01455 00300 ∂12-Mar-88 1646 CL-Cleanup-mailer New issue: DEFPACKAGE
C01457 00301 ∂12-Mar-88 1702 CL-Cleanup-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
C01460 00302 ∂12-Mar-88 1808 CL-Cleanup-mailer Issue: LAST-N (Version 2)
C01466 00303 ∂13-Mar-88 1637 CL-Cleanup-mailer Re: New issue: DEFPACKAGE
C01468 00304 ∂14-Mar-88 0007 CL-Cleanup-mailer Re: the array type mess....
C01470 00305 ∂14-Mar-88 0013 CL-Cleanup-mailer Current issue status
C01493 00306 ∂14-Mar-88 0110 CL-Cleanup-mailer New issue: STEP-ENVIRONMENT
C01496 00307 ∂14-Mar-88 0115 CL-Cleanup-mailer New issue: DEFPACKAGE
C01499 00308 ∂14-Mar-88 0559 CL-Cleanup-mailer New issue: DEFPACKAGE
C01502 00309 ∂14-Mar-88 0637 CL-Cleanup-mailer DEFPACKAGE syntax
C01504 00310 ∂18-Mar-88 1405 CL-Cleanup-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
C01511 00311 ∂18-Mar-88 1439 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 1)
C01522 00312 ∂18-Mar-88 1611 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 1)
C01526 00313 ∂18-Mar-88 2051 CL-Cleanup-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
C01528 00314 ∂18-Mar-88 2128 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 1)
C01534 00315 ∂19-Mar-88 1521 CL-Cleanup-mailer FUNCTION-TYPE proposal
C01538 00316 ∂21-Mar-88 1121 CL-Cleanup-mailer Pending issue status
C01546 00317 ∂21-Mar-88 1628 CL-Cleanup-mailer Issue: MACRO-FUNCTION-ENVIRONMENT
C01551 00318 ∂21-Mar-88 1726 CL-Cleanup-mailer RE: Issue: MACRO-FUNCTION-ENVIRONMENT
C01553 00319 ∂21-Mar-88 1743 CL-Cleanup-mailer Issue: MACRO-FUNCTION-ENVIRONMENT
C01555 00320 ∂21-Mar-88 1748 CL-Cleanup-mailer Re: Issue: MACRO-FUNCTION-ENVIRONMENT
C01557 00321 ∂22-Mar-88 0633 CL-Cleanup-mailer cleanup for equal ?
C01559 00322 ∂22-Mar-88 0955 CL-Cleanup-mailer stream-access background information
C01564 00323 ∂22-Mar-88 1025 CL-Cleanup-mailer Re: stream-access background information
C01566 00324 ∂22-Mar-88 1324 CL-Cleanup-mailer RE: stream-access background information
C01569 00325 ∂22-Mar-88 1630 CL-Cleanup-mailer New "issue" and proposal
C01573 00326 ∂22-Mar-88 1649 CL-Cleanup-mailer Re: New "issue" and proposal
C01574 00327 ∂22-Mar-88 2030 CL-Cleanup-mailer Strings as streams
C01576 00328 ∂23-Mar-88 1006 CL-Cleanup-mailer Strings as streams
C01580 00329 ∂23-Mar-88 1048 CL-Cleanup-mailer Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
C01584 00330 ∂23-Mar-88 1102 CL-Cleanup-mailer Issue: MACRO-FUNCTION-ENVIRONMENT
C01586 00331 ∂23-Mar-88 1105 CL-Cleanup-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
C01588 00332 ∂23-Mar-88 1110 CL-Cleanup-mailer Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
C01591 00333 ∂23-Mar-88 1117 CL-Cleanup-mailer Issue: LAST-N (Version 2)
C01593 00334 ∂23-Mar-88 1150 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C01604 00335 ∂23-Mar-88 1151 CL-Cleanup-mailer New issue: DEFPACKAGE
C01615 00336 ∂23-Mar-88 1156 CL-Cleanup-mailer New issue: DEFPACKAGE
C01617 00337 ∂23-Mar-88 1330 CL-Cleanup-mailer Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
C01619 00338 ∂24-Mar-88 0849 CL-Cleanup-mailer Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
C01623 00339 ∂24-Mar-88 1052 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS
C01628 00340 ∂24-Mar-88 1438 CL-Cleanup-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED
C01633 00341 ∂25-Mar-88 1411 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS
C01636 00342 ∂25-Mar-88 1456 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS
C01639 00343 ∂25-Mar-88 2152 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE
C01645 00344 ∂29-Mar-88 0759 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS, version 2
C01652 00345 ∂29-Mar-88 1153 CL-Cleanup-mailer Re: Issue: WITH-OPEN-STRING-APPEND-STYLE
C01654 00346 ∂29-Mar-88 1608 CL-Cleanup-mailer Re: Issue SUBSEQ-OUT-OF-BOUNDS, version 2
C01655 00347 ∂29-Mar-88 2140 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01661 00348 ∂08-Apr-88 0951 CL-Cleanup-mailer special var type decls
C01665 00349 ∂08-Apr-88 0951 CL-Cleanup-mailer special var type decls
C01669 00350 ∂08-Apr-88 2242 CL-Cleanup-mailer floating point questions
C01679 00351 ∂10-Apr-88 1509 CL-Cleanup-mailer Issue: REST-ARGUMENT-EXTENT
C01688 00352 ∂11-Apr-88 0831 CL-Cleanup-mailer Issue: REST-ARGUMENT-EXTENT
C01691 00353 ∂11-Apr-88 1032 CL-Cleanup-mailer Re: Issue: REST-ARGUMENT-EXTENT
C01694 00354 ∂12-Apr-88 0347 CL-Cleanup-mailer Issue: REST-ARGUMENT-EXTENT
C01701 00355 ∂13-Apr-88 1331 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 1)
C01708 00356 ∂13-Apr-88 1334 CL-Cleanup-mailer [Jim McDonald: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)]
C01719 00357 ∂17-Apr-88 1740 CL-Cleanup-mailer FORMAT-PRETTY-PRINT
C01720 00358 ∂26-Apr-88 2114 CL-Cleanup-mailer miscellaneous questions about declarations and type specfiers
C01724 00359 ∂13-May-88 0236 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C01753 00360 ∂17-May-88 0213 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C01760 00361 ∂19-May-88 0042 CL-Cleanup-mailer Features
C01762 00362 ∂19-May-88 1125 CL-Cleanup-mailer ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
C01768 00363 ∂19-May-88 1126 CL-Cleanup-mailer When is the Cambridge cleanup meeting?????
C01770 00364 ∂19-May-88 1136 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
C01777 00365 ∂19-May-88 1152 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
C01784 00366 ∂19-May-88 1301 CL-Cleanup-mailer Re: When is the Cambridge cleanup meeting?????
C01786 00367 ∂19-May-88 1354 CL-Cleanup-mailer PASSED X3J13 March 1988
C01792 00368 ∂19-May-88 1500 CL-Cleanup-mailer Issue: FUNCTION-TYPE (version 10)
C01809 00369 ∂20-May-88 1914 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C01817 00370 ∂20-May-88 1921 CL-Cleanup-mailer Issue: FUNCTION-TYPE (version 10)
C01819 00371 ∂20-May-88 2102 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C01824 00372 ∂21-May-88 0207 CL-Cleanup-mailer Issue: FUNCTION-TYPE (version 10)
C01827 00373 ∂21-May-88 0247 CL-Cleanup-mailer ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
C01831 00374 ∂21-May-88 0248 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
C01833 00375 ∂21-May-88 0520 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C01838 00376 ∂21-May-88 0613 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C01846 00377 ∂23-May-88 0828 CL-Cleanup-mailer HASH-TABLE-PRINTED-REPRESENTATION
C01853 00378 ∂23-May-88 1306 CL-Cleanup-mailer Re: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01855 00379 ∂23-May-88 1329 CL-Cleanup-mailer Re: issue FUNCTION-TYPE
C01861 00380 ∂23-May-88 1340 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C01881 00381 ∂23-May-88 1346 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY
C01883 00382 ∂23-May-88 1500 CL-Cleanup-mailer Issue: TAILP-NIL
C01889 00383 ∂23-May-88 1512 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY
C01891 00384 ∂23-May-88 1525 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C01894 00385 ∂23-May-88 1539 CL-Cleanup-mailer Re: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01897 00386 ∂23-May-88 1544 CL-Cleanup-mailer HASH-TABLE-PRINTED-REPRESENTATION
C01900 00387 ∂23-May-88 1605 CL-Cleanup-mailer Re: New issue: STEP-ENVIRONMENT
C01902 00388 ∂23-May-88 1613 CL-Cleanup-mailer Re: HASH-TABLE-PRINTED-REPRESENTATION
C01906 00389 ∂23-May-88 1613 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
C01918 00390 ∂23-May-88 1646 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01920 00391 ∂23-May-88 1723 CL-Cleanup-mailer Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
C01925 00392 ∂23-May-88 1727 CL-Cleanup-mailer Re: Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01927 00393 ∂23-May-88 1741 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
C01937 00394 ∂23-May-88 1801 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS
C01939 00395 ∂23-May-88 1819 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C01942 00396 ∂23-May-88 1819 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01945 00397 ∂23-May-88 1845 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01951 00398 ∂23-May-88 2212 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
C01958 00399 ∂24-May-88 0122 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS
C01968 00400 ∂24-May-88 0145 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 2)
C01986 00401 ∂24-May-88 0204 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
C01989 00402 ∂24-May-88 0313 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C01995 00403 ∂24-May-88 0602 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 2)
C02025 00404 ∂24-May-88 0707 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C02028 00405 ∂24-May-88 0746 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02031 00406 ∂24-May-88 0809 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 2)
C02033 00407 ∂24-May-88 0906 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS
C02041 00408 ∂24-May-88 1021 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
C02044 00409 ∂24-May-88 1201 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 2)
C02059 00410 ∂24-May-88 1210 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
C02061 00411 ∂24-May-88 1339 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C02069 00412 ∂24-May-88 1342 CL-Cleanup-mailer Re: Issue: STEP-ENVIRONMENT
C02072 00413 ∂24-May-88 1356 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C02079 00414 ∂24-May-88 1400 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
C02081 00415 ∂24-May-88 1402 CL-Cleanup-mailer ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
C02083 00416 ∂24-May-88 1425 CL-Cleanup-mailer issue: FUNCTION-TYPE (version 11)
C02102 00417 ∂24-May-88 1436 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 1)
C02104 00418 ∂25-May-88 0726 CL-Cleanup-mailer Re: issue: FORMAT-PRETTY-PRINT (version 1)
C02106 00419 ∂25-May-88 0747 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02109 00420 ∂25-May-88 1202 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02115 00421 ∂25-May-88 1321 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS
C02122 00422 ∂25-May-88 1618 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 2)
C02130 00423 ∂25-May-88 1634 CL-Cleanup-mailer mail deadline
C02132 00424 ∂26-May-88 1146 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 2)
C02139 00425 ∂26-May-88 1146 CL-Cleanup-mailer Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
C02144 00426 ∂26-May-88 1146 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
C02157 00427 ∂26-May-88 1647 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
C02160 00428 ∂26-May-88 1939 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 4)
C02188 00429 ∂26-May-88 1945 CL-Cleanup-mailer Issue: SETF-SUB-METHODS
C02190 00430 ∂26-May-88 2103 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C02196 00431 ∂27-May-88 0814 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
C02198 00432 ∂27-May-88 1815 CL-Cleanup-mailer [More on] Issue: DEFPACKAGE
C02202 00433 ∂28-May-88 0927 CL-Cleanup-mailer ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
C02204 00434 ∂28-May-88 1004 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 2)
C02208 00435 ∂28-May-88 1053 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
C02211 00436 ∂28-May-88 1753 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
C02213 00437 ∂28-May-88 2039 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C02215 00438 ∂31-May-88 0717 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
C02217 00439 ∂31-May-88 0814 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 2)
C02226 00440 ∂31-May-88 0840 CL-Cleanup-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
C02230 00441 ∂31-May-88 0856 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
C02232 00442 ∂31-May-88 1308 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02242 00443 ∂31-May-88 1422 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (Version 4)
C02251 00444 ∂31-May-88 1438 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
C02255 00445 ∂31-May-88 1451 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
C02259 00446 ∂31-May-88 1759 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02264 00447 ∂31-May-88 2211 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02266 00448 ∂01-Jun-88 0120 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02268 00449 ∂01-Jun-88 0711 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02270 00450 ∂01-Jun-88 1014 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02276 00451 ∂01-Jun-88 1037 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02280 00452 ∂01-Jun-88 1402 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02285 00453 ∂02-Jun-88 2141 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02292 00454 ∂02-Jun-88 2141 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02296 00455 ∂02-Jun-88 2216 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
C02322 00456 ∂03-Jun-88 1048 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02327 00457 ∂03-Jun-88 1134 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02330 00458 ∂07-Jun-88 1255 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 2)
C02332 00459 ∂07-Jun-88 1359 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
C02339 00460 ∂07-Jun-88 1429 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 4)
C02343 00461 ∂07-Jun-88 1559 CL-Cleanup-mailer Cleanup issues -- OK to mail out?
C02345 00462 ∂07-Jun-88 1614 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
C02347 00463 ∂07-Jun-88 1614 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
C02354 00464 ∂08-Jun-88 1356 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 5)
C02382 00465 ∂08-Jun-88 1724 CL-Cleanup-mailer Re: Cleanup Committee Mtg?
C02384 00466 ∂09-Jun-88 0714 CL-Cleanup-mailer Issue: LAST-N (Version 2)
C02386 00467 ∂09-Jun-88 0907 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
C02388 00468 ∂09-Jun-88 0953 CL-Cleanup-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
C02397 00469 ∂09-Jun-88 1525 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
C02399 00470 ∂09-Jun-88 1726 CL-Cleanup-mailer Re: X3 subcommittee room
C02401 00471 ∂09-Jun-88 2120 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 2)
C02408 00472 ∂09-Jun-88 2123 CL-Cleanup-mailer X3 subcommittee room
C02410 00473 ∂09-Jun-88 2136 CL-Cleanup-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
C02414 00474 ∂09-Jun-88 2314 CL-Cleanup-mailer Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION
C02416 00475 ∂09-Jun-88 2357 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
C02418 00476 ∂10-Jun-88 0000 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 2)
C02420 00477 ∂10-Jun-88 0056 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 4)
C02422 00478 ∂10-Jun-88 0159 CL-Cleanup-mailer [masinter.pa: Issue: COERCE-INCOMPLETE]
C02446 00479 ∂10-Jun-88 0205 CL-Cleanup-mailer Issue: FOLLOW-SYNONYM-STREAM
C02452 00480 ∂10-Jun-88 0223 CL-Cleanup-mailer Issue: FUNCTION-ARGUMENT-TYPE-SEMANTICS]
C02509 00481 ∂10-Jun-88 0227 CL-Cleanup-mailer [Dan L. Pierson <pierson@mist.ARPA>: Issue: LET-TOP-LEVEL (version 1)]
C02517 00482 ∂10-Jun-88 0228 CL-Cleanup-mailer Withdrawn issues
C02520 00483 ∂10-Jun-88 0231 CL-Cleanup-mailer [Masinter.pa: Issue: Pathname-subdirectory-list]
C02535 00484 ∂10-Jun-88 0244 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
C02543 00485 ∂10-Jun-88 0827 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 3)
C02552 00486 ∂10-Jun-88 0845 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 4)
C02557 00487 ∂10-Jun-88 0904 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE
C02559 00488 ∂10-Jun-88 1006 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 3)
C02561 00489 ∂10-Jun-88 1041 CL-Cleanup-mailer Re: Issue: FORMAT-PRETTY-PRINT (version 3)
C02564 00490 ∂10-Jun-88 1045 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 4)
C02573 00491 ∂10-Jun-88 1513 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 4)
C02575 00492 ∂10-Jun-88 2016 CL-Cleanup-mailer [Dan L. Pierson <pierson@mist.ARPA>: Issue: LET-TOP-LEVEL (version 1)]
C02578 00493 ∂12-Jun-88 2142 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE
C02581 00494 ∂13-Jun-88 0732 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 4)
C02583 00495 ∂17-Jun-88 1754 CL-Cleanup-mailer Issue: STREAM-ACCESS (version 1)
C02591 ENDMK
C⊗;
∂28-Nov-87 0534 CL-Cleanup-mailer [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Nov 87 05:34:09 PST
Received: by labrea.stanford.edu; Sat, 28 Nov 87 05:32:29 PST
Received: from bhopal.lucid.com by edsel id AA28590g; Sat, 28 Nov 87 05:26:50 PST
Received: by bhopal id AA17747g; Sat, 28 Nov 87 05:27:53 PST
Date: Sat, 28 Nov 87 05:27:53 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8711281327.AA17747@bhopal.lucid.com>
To: labrea!Dave.Touretzky%C.CS.CMU.EDU@labrea.stanford.edu
Cc: labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: Dave.Touretzky@C.CS.CMU.EDU's message of Mon 16 Nov 87 01:57:08-EST <12350990498.13.TOURETZKY@C.CS.CMU.EDU>
Subject: [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
There's one sense in which I share Fahlman's reluctance to accept this idea.
It seems to presume that underlying any array whatsoever is a simple
vector of elements that represent the array in dense, row-major order.
In fact, Lucid Common Lisp does just about that (as all the others do too,
I suspect!). There is even an "internal" function named
'underlying-simple-vector'
to fetch that simple vector.
But the problem is that the simple-vector needn't be "dense" in elements
of the array! The existence of the function array-row-major-index doesn't
require, for example, that there be no gaps between the rows. [The
definition on CLtL, p293 is only one possibility -- the one for dense
underlying simple-vectors.] Rather, it only requires a 1-1 mapping
between the integers {0,1,...(1- <array-total-size>)} and the full set of
multi-dimensional indices.
Your characterization of the relation between arrays and sequences exhibits
the bias towards dense, underlying simple vectors:
Let me restate the basic intuition one more time. A sequence is like
a string of beads. If you stretch it out straight you have a list or
vector. If you fold it up in various ways using COERCE or MAP, you
have an n-dimensional array which you can access with AREF, which is
not a sequence function. The beads still sit on the string in the same
order, and the sequence functions still give the same result no matter
how you fold the string of beads. This property is guaranteed by the
existing commitment in CLtL to storing array elements in row-major order.
"Ordering" may be guaranteed by row-major order; but "density" isn't.
Not even the existence of :displaced-index-offset guarantees "density"
(especially if it's value is typically row-aligned anyway), although
I admit that you won't get portable results if you can't assume density.
Until it is decided that a particular implementation of multi-dimensional
arrays is *standard* (as opposed to the functional interface to multi-
dimensional arrays), then Common Lisp implementations should be free
to store the rows of a matrix in any random way that is convenient to
the storage layout of that implementation (e.g., "sparse" storage?).
I must confess that on "stock" hardware, it would be rather inefficient not
to use the dense, row-major odering. But closing off other implementation
options seems premature, to me; at least until there is evidence of a *great*
win to be had by doing so.
-- JonL --
∂28-Nov-87 1105 CL-Cleanup-mailer Issue status
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Nov 87 11:05:33 PST
Received: by labrea.stanford.edu; Sat, 28 Nov 87 11:03:53 PST
Received: from kent-state.lucid.com by edsel id AA29214g; Sat, 28 Nov 87 10:57:29 PST
Received: by kent-state id AA05304g; Sat, 28 Nov 87 10:58:08 PST
Date: Sat, 28 Nov 87 10:58:08 PST
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8711281858.AA05304@kent-state.lucid.com>
To: Masinter.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 25 Nov 87 17:49 PST <871125-174935-2663@Xerox>
Subject: Issue status
Date: 25 Nov 87 17:49 PST
From: Masinter.pa@Xerox.COM
This isn't quite up to date as I've missed a few, but I thought I should
go ahead and send it out if you're keeping a score card... I think we
have some new members of the distribution list as of the last week or
so...
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
Ready for release
Perhaps you missed my message about this issue, since I sent it during
the meeting. Here it is again:
There's a problem with this SETF method for symbols. Consider the
following simplified version of SETF from p.107 of CLtL:
(DEFMACRO SETF (REFERENCE VALUE)
(MULTIPLE-VALUE-BIND (VARS VALS STORES STORE-FORM ACCESS-FORM)
(GET-SETF-METHOD REFERENCE)
(DECLARE (IGNORE ACCESS-FORM))
`(LET* ,(MAPCAR #'LIST (APPEND VARS STORES) (APPEND VALS (LIST VALUE)))
,STORE-FORM)))
This results in the following macrexpansion for (SETF X 1), using the
new SETF method for symbols:
(LET* ((G0002 X)
(G0001 1))
(SETQ X G0001))
The value of G0002 is never used. The problem is that X might be
unbound, so even just binding it to a local variable will fail. I
don't think we want to require implementations to eliminate
unnecessary bindings in SETF expansions, just to get correct
semantics. Nor should each SETF-like macro need a special case when
the location being stored is a symbol.
Unfortunately, I think special handling for symbols is necessary. If
we keep the SETF method for symbols the way it is in CLtL then we need
to make a special case for symbols in the SETF methods for GETF, LDB
and the like. If we change the SETF method as proposed here, we need
to make a special case for symbols in SETF and PSETF and any user
defined SETF-like macro that doesn't use the fifth value (ACCESS-FORM)
from GET-SETF-METHOD.
My feeling is that we should go with the new SETF method for symbols,
but describe this problem and point out to implementors that SETF and
PSETF must handle symbols specially, effectively resorting to the old
SETF method.
∂30-Nov-87 0921 CL-Cleanup-mailer [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Nov 87 09:21:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 290628; Mon 30-Nov-87 12:19:35 EST
Date: Mon, 30 Nov 87 12:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: Dave.Touretzky@C.CS.CMU.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8711281327.AA17747@bhopal.lucid.com>
Message-ID: <19871130171930.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 28 Nov 87 05:27:53 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
There's one sense in which I share Fahlman's reluctance to accept this idea.
It seems to presume that underlying any array whatsoever is a simple
vector of elements that represent the array in dense, row-major order.
....
That was clearly the intention of Common Lisp, although I note that the
only place in CLtL that says this explicitly is an example on p.289.
It can also be deduced from the definitions of array-total-size and
array-row-major-index, because the range of array-row-major-index's
answer is defined to be a range of integers that contains just enough
members to supply a value for each subscript set, with no gaps.
Since CLtL was not explicit enough to be clear to you, perhaps a cleanup
proposal in the "clarification" category is needed.
∂30-Nov-87 1446 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Nov 87 14:46:37 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Mon, 30 Nov 87 17:46:03 EST
Received: by kali.think.com; Mon, 30 Nov 87 17:45:59 EST
Date: Mon, 30 Nov 87 17:45:59 EST
From: gls@Think.COM
Message-Id: <8711302245.AA00685@kali.think.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 20 Nov 87 12:34 PST <871120-123444-1850@Xerox>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE
Issue: FORMAT-COLON-UPARROW-SCOPE
References: CLtL p. 406 and also p. 403
Category: CLARIFICATION
Edit history: version 1: Guy Steele, 30 November 1987
Problem description:
Implementations currently differ on the question of what is tested by the
FORMAT command "~:↑". Some implementations test to see whether any
arguments remain in the sublist for the current iteration step; others test
to see whether any sublists remain. The text on page 406 is not clear
on this point.
Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{.
The entire iteration process is terminated if and only if the sublist
that is supplying the arguments for the current iteration step is the
last sublist (in the case of ~:{) or the last FORMAT argument (~:@{).
Note that ~:↑ is *not* equivalent to ~:#↑; the latter terminates the
entire iteration if and only if no arguments remain for the current
iteration step.
Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{.
The entire iteration process is terminated if and only if no more arguments
remain for the current iteration step. Thus ~:↑ is equivalent to ~:#↑,
just as ~↑ is equivalent to ~#↑.
Test Cases/Examples:
(format nil "~:{~@?~:↑...~}" '(("a") ("b")))
Under proposal FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS
this yields "a...b".
Under proposal FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS
this yields "a".
Rationale:
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS is desirable
because otherwise there is no way to test whether any sublists remain.
The text on page 406 may be construed to hint at this proposal
indirectly. To quote Nick Gall:
If one thinks about the intent of the parenthetical
(because in the standard case it tests for remaining arguments of
the current step only)
one should agree that "a...b" will be returned. In referring to ~↑ as
the "standard case", which tests the arguments remaining in the
current argument sublist, this parenthetical implies that there is
an `other case', which tests `something else.' The only `other case'
discussed is ~:↑, which therefore must test `something else.' I claim
that the parentheical makes no sense if we interpret ~:↑ as testing
the same condition as ~↑. If they both test the same condition, why
have the parenthetical explanation?
If ~:↑ doesn't test the same condition as ~↑, then what does it test?
I claim that the only test that makes sense is for ~:↑ to test the
only thing that affects the "entire iteration process:" the number of
sublists. When there are no more sublists, "the entire iteration
process" is terminated.
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS is desirable
only because it maintains the equivalence of ~:#↑ and ~:↑ and because
some implementations have been produced that take this approach.
Current practice:
Implementations using FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS
include Symbolics Common Lisp.
Implementations using FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS
include Kyoto Common Lisp, Allegro Common Lisp, GCLISP, and VAXLISP.
Cost to Implementors:
One or the other batch of implementors will have to make a one-line change.
Cost to Users:
It is unlikely that much user code depends on the behavior
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS, but it is
possible. The author of this writeup (Steele) judges it somewhat more
likely that user code might depend on the behavior
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Cost of non-adoption:
Users would have to be warned not to use ~:↑ in code that is meant to be
portable.
Benefits:
Elimination of yet one more ambiguity.
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS allows greater
semantic power (there are more things one can test).
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS maintains an
elegant but useless symmetry.
Esthetics:
Absolutely none. We're talking about FORMAT here.
Discussion:
Nick Gall favors FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Kevin Layer, Rich Robbins, and Robert Poor have spoken in favor of
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS.
Guy Steele strongly prefers the interpretation
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Historical note: Steele first implemented this "feature", in Zetalisp, and
so the code in Symbolics Common Lisp is likely a direct descendant of the
original code. This might cause some to give weight to Steele's opinion.
There are two arguments against such credence. First, there is no reason
why the original code should be regarded as part of the specification of
Common Lisp any more than any other implementation; plainly, Steele botched
the specification when he wrote the book. Second, a professor of
literature (I believe) once told Isaac Asimov concerning a short story of
his (I quote from memory): "Tell me, Dr. Asimov, just because you wrote the
story, what makes you think you know what it means?"
∂30-Nov-87 1733 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Nov 87 17:33:23 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291206; Mon 30-Nov-87 20:33:04 EST
Date: Mon, 30 Nov 87 20:33 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE
To: cl-cleanup@SAIL.STANFORD.EDU
cc: gls@Think.COM
In-Reply-To: <8711302245.AA00685@kali.think.com>
Message-ID: <19871201013304.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks ready for release to me, unless we don't want to release any
discussions containing more than one proposal. In that case, my vote is
with FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS on the grounds
of its greater expressive power and slightly lower cost to users.
∂30-Nov-87 1911 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Nov 87 19:11:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 87 15:50:53 PST
Date: Mon, 30 Nov 87 15:50:47 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FORMAT-COLON-UPARROW-SCOPE
In-reply-to: <8711302245.AA00685@kali.think.com>
To: cl-cleanup@sail.stanford.edu
Message-ID: <871130-155053-1317@Xerox>
I also favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
∂01-Dec-87 0025 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 87 00:25:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 87 15:29:31 PST
Date: 30 Nov 87 15:29 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <871130-152931-1269@Xerox>
Charniak, Riesbeck, McDermott and Meehan's "Artificial Intelligence Programming"
, says:
"Also as recommended in Steele, if &REST is given in a FUNCTION type form, the
type that follows &REST refers to the type of each argument that &REST collects,
not to the type of the &REST variable (which is always a list). The definition
of + might begin
(DEFUN + (&REST NUMBERS) ...)
Its type is
(FUNCTION (&REST NUMBER) NUMBER)."
Unfortunately, I've never found the place in CLtL where such a recommendation is
made.
∂01-Dec-87 0038 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 00:37:55 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291526; Tue 1-Dec-87 11:26:00 EST
Date: Tue, 1 Dec 87 11:25 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE
To: gls@Think.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8711302245.AA00685@kali.think.com>
Message-ID: <871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I side with TEST-FOR-REMAINING-SUBLISTS because it offers important
flexibility that is otherwise tricky to obtain.
If we can reach consensus within the group, I'd like to see the proposal
rewritten to contain only one proposal.
If we have to retain two proposals, I think the TEST-FOR-REMAINING-ARGUMENTS
is going to need its rationale/benefits beefed up a bit. As it stands,
Steele argues only elegance and then goes on to say later that
aesthetics doesn't count in FORMAT. I don't think this is going to win
many people who are hanging in the balance.
I think the remark about aesthetics not counting at all in FORMAT is cute
but not strictly true. But since I don't have anything more consequential
to write there, I'll suggest the following compromise presentation which
(for the sake of casual readers and future historians) makes it more clear
that we're being flippant -- or at least less clear that we're being
serious...
Aesthetics:
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele, Jr.
∂01-Dec-87 0100 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 01:00:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291565; Tue 1-Dec-87 11:46:33 EST
Date: Tue, 1 Dec 87 11:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
To: Masinter.pa@Xerox.COM
cc: sandra%orion@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871130-152931-1269@Xerox>
Message-ID: <19871201164614.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 30 Nov 87 15:29 PST
From: Masinter.pa@Xerox.COM
Charniak, Riesbeck, McDermott and Meehan's "Artificial Intelligence Programming", says:
"Also as recommended in Steele, if &REST is given in a FUNCTION type form, the
type that follows &REST refers to the type of each argument that &REST collects,
not to the type of the &REST variable (which is always a list). The definition
of + might begin
(DEFUN + (&REST NUMBERS) ...)
Its type is
(FUNCTION (&REST NUMBER) NUMBER)."
Unfortunately, I've never found the place in CLtL where such a recommendation is
made.
That's because there isn't one. Note that the reference was to "Steele", not
to CLtL. It can be found in document X3J13 / 86-003, a many-times photocopied
5 page document that is apparently entitled "A:>GLS>clarifications.text.4".
A scribble on my copy says "be explicit about &optional, colons; remanded
to declarations committee." I suppose the declarations committee is one of
those vapor committees that never produces anything? This seems like a
reasonable thing for the Cleanup committee to address, expanded to cover
all lambda-list keywords in FUNCTION type-specifiers, not just &REST.
∂01-Dec-87 0923 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 01:00:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291565; Tue 1-Dec-87 11:46:33 EST
Date: Tue, 1 Dec 87 11:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
To: Masinter.pa@Xerox.COM
cc: sandra%orion@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871130-152931-1269@Xerox>
Message-ID: <19871201164614.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 30 Nov 87 15:29 PST
From: Masinter.pa@Xerox.COM
Charniak, Riesbeck, McDermott and Meehan's "Artificial Intelligence Programming", says:
"Also as recommended in Steele, if &REST is given in a FUNCTION type form, the
type that follows &REST refers to the type of each argument that &REST collects,
not to the type of the &REST variable (which is always a list). The definition
of + might begin
(DEFUN + (&REST NUMBERS) ...)
Its type is
(FUNCTION (&REST NUMBER) NUMBER)."
Unfortunately, I've never found the place in CLtL where such a recommendation is
made.
That's because there isn't one. Note that the reference was to "Steele", not
to CLtL. It can be found in document X3J13 / 86-003, a many-times photocopied
5 page document that is apparently entitled "A:>GLS>clarifications.text.4".
A scribble on my copy says "be explicit about &optional, colons; remanded
to declarations committee." I suppose the declarations committee is one of
those vapor committees that never produces anything? This seems like a
reasonable thing for the Cleanup committee to address, expanded to cover
all lambda-list keywords in FUNCTION type-specifiers, not just &REST.
∂01-Dec-87 1042 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 10:42:13 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA01261; Tue, 1 Dec 87 13:44:29 EST
Message-Id: <8712011844.AA01261@multimax.ARPA>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
Subject: Re: Issue: FORMAT-COLON-UPARROW-SCOPE
In-Reply-To: Your message of Tue, 01 Dec 87 11:25:00 -0500.
<871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 01 Dec 87 13:44:24 EST
From: Dan L. Pierson <pierson@multimax.arpa> <pierson>
Despite my earlier comments on the common-lisp mailing list, I also
now favor TEST-FOR-REMAINING-ARGUMENTS. It does gain more power.
∂01-Dec-87 1043 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 10:43:35 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA01311; Tue, 1 Dec 87 13:45:51 EST
Message-Id: <8712011845.AA01311@multimax.ARPA>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
Subject: Re: Issue: FORMAT-COLON-UPARROW-SCOPE
In-Reply-To: Your message of Tue, 01 Dec 87 11:25:00 -0500.
<871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 01 Dec 87 13:45:41 EST
From: Dan L. Pierson <pierson@multimax.arpa> <pierson>
Ooops, make that TEST-FOR-REMIANING-SUBLISTS. Braino.
∂01-Dec-87 1102 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 11:02:44 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA12488; Tue, 1 Dec 87 12:02:15 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA15709; Tue, 1 Dec 87 12:02:09 MST
Date: Tue, 1 Dec 87 12:02:09 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712011902.AA15709@orion.utah.edu>
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
To: cl-cleanup@sail.stanford.edu
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p.47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Related issues: FUNCTION-TYPE-KEY-NAME
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables. However, this is actually of limited
usefulness in the context of a declaration, where one normally wants type
information about the actual arguments which can be passed to the function
rather than the lambda variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem
that the corresponding type given in the FUNCTION declaration must also be
LIST, but since this provides no information about the actual arguments,
some users/implementors have instead adopted the convention of supplying
the type of the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the
type specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.
Test Case:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must
be LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Many Common Lisp
implementations currently ignore FUNCTION type declarations.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do
so. Probably only a small amount of code would have to be written/changed
in implementations that currently think that the type of the &REST parameter
must be LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must
be LIST will have to change their code. However, because this issue is so
unclear, the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
Ugly. Since the argument type syntax used by the FUNCTION type specifier
mirrors normal lambda-list syntax, it is confusing to make the &REST type
to refer to the types of the actual arguments rather than the type of the
matching lambda variable.
Discussion:
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:EXTEND-LIST-TYPE):
(1) Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST refers to the type of the corresponding lambda variable and must
be LIST or a subtype of LIST.
(2) Introduce a list form of the LIST type specifier, (LIST <type>), to
specify a list where the value of each successive CAR of the list is a
member of type <type>.
(3) Introduce a list form of the SEQUENCE type specifier, (SEQUENCE <type>),
to specify a sequence where the value of each successive element is a
member of type <type>.
Test Case:
The type of the function + would be specified as:
(FUNCTION (&REST (LIST NUMBER)) NUMBER)
Rationale:
(1) It is clear that a &REST lambda variable must be bound to a list.
Since the FUNCTION type syntax follows lambda-list syntax rather than
function call syntax, it is more consistent to make the type correspond to
the type of the lambda variable rather than that of the actual arguments.
(2) Introducing a list LIST type specifier would allow the FUNCTION type
specifier to be more useful for its intended purpose. It would also be
useful on its own. For example, a compiler may be able to optimize
calls to functions such as MAPCAR that operate on successive elements of
a list if information is available about the type of items in the list.
The motivation for making this part of the standard is that the syntax
of the LIST type cannot cannot be extended by user code.
(3) This is an obvious extension of (2).
Current practice:
There does not appear to be any concensus on this issue. Many Common Lisp
implementations currently ignore FUNCTION type declarations.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to
do so. It should be a fairly straightforward to implement the list
forms of the LIST and SEQUENCE type specifiers.
Cost to Users:
Users who have been using the convention that the &REST type parameter
specifies the type of the actual arguments will have to change their code.
However, because this issue is so unclear, the FUNCTION type specifier is
probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
Since the argument type syntax used by the FUNCTION type specifier mirrors
normal lambda-list syntax, it would be cleaner and less confusing to provide
the type of the lambda variable rather than the type of the actual arguments.
Discussion:
-------
∂01-Dec-87 1103 CL-Cleanup-mailer Issue: FUNCTION-TYPE-KEY-NAME
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 11:03:14 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA12513; Tue, 1 Dec 87 12:02:44 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA15714; Tue, 1 Dec 87 12:02:36 MST
Date: Tue, 1 Dec 87 12:02:36 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712011902.AA15714@orion.utah.edu>
Subject: Issue: FUNCTION-TYPE-KEY-NAME
To: cl-cleanup@sail.stanford.edu
Issue: FUNCTION-TYPE-KEY-NAME
References: CLtL p.47-48, 61
Category: CLARIFICATION, CHANGE
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables. However, there is a problem with &KEY
lambda variables because keyword arguments may be specified in arbitrary
order in both the the lambda list and the actual argument list. It is not
possible to match up the types specified in the FUNCTION declaration to
either actual arguments or lambda variables without additional information.
Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD):
(1) Specify that the &KEY parameters in a FUNCTION type specifier lambda
list should be supplied as lists of the form (<keyword> <type>). The
<keyword> must be a symbol in the keyword package.
(2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda
list.
Test Case:
The type of the function SORT could be specified as:
(FUNCTION (SEQUENCE FUNCTION &KEY (:KEY FUNCTION)) SEQUENCE)
Rationale:
(1) This specifies a direct correspondence between the argument type and
its matching keyword. All of the information is in one place, and the user
does not have to remember (or even know) the order in which &KEY arguments
appear in the actual function definition.
(2) This is probably an oversight in the original specification.
Current practice:
Many Common Lisp implementations currently ignore FUNCTION type
declarations. The situation regarding type specifications for keyword
arguments is so ambiguous that few users attempt to use them.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier or keyword arguments
in a FUNCTION type specifier may continue to do so. This proposal should
not involve massive amounts of code to be rewritten.
Conversion Cost:
Because the current situation is so ambiguous, FUNCTION type specifiers and
particularly the specification of keyword argument types are not widely used.
However, since this is an incompatible change, it would be nice if
implementations check for, and warn about, old-style usage.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
The syntax is fairly obvious and is analogous to the (<keyword> <variable>)
lambda list syntax.
Discussion:
-------
∂01-Dec-87 1201 CL-Cleanup-mailer Issue: FUNCTION-TYPE-KEY-NAME
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 12:01:16 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291874; Tue 1-Dec-87 15:00:39 EST
Date: Tue, 1 Dec 87 15:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE-KEY-NAME
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8712011902.AA15714@orion.utah.edu>
Message-ID: <871201150013.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I am generally sympathetic to the SPECIFY-KEYWORD proposal but can't really
endorse it in its current form because...
* The problem description should make it clear that the problem is not
the keywords can be in any order in the formal and actual argument
lists, but rather just that CLtL is not clear on how the matchup is
specified. It is "possible", it's just not "defined".
* Item one of the proposal should not require that the <keyword> be in
the keyword package since there is a proposal on the floor to loosen
this requirement for keywords. Instead it should state that the <keyword>
must be a valid keyword-name symbol.
* Should we make it explicit that SUPPLIED-P information is either allowed
or disallowed in FUNCTION declarations? (I see no reason to allow it but
maybe I'm overlooking something.)
* The test case is wrong because the word SORT is omitted in the declaration.
This is presumably just a typo.
Also, though, it looks funny because of the :KEY and because the type
FUNCTION is also probably the user's idea of the argument's name. These
"coincidences" don't make the example wrong but make it hard to focus on
the points it's trying to make.
I suggest picking another example. MAKE-LIST comes to mind. eg:
(FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)
∂01-Dec-87 1756 CL-Cleanup-mailer CL-CLEANUP membership
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 87 17:54:06 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 87 11:40:08 PST
Date: 30 Nov 87 11:39 PST
From: Masinter.pa@Xerox.COM
Subject: CL-CLEANUP membership
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871130-114008-117@Xerox>
There are a number of people who are either observers or members of this
subcommittee and were not listed in Mathis' announcement.
> Date: 29 Nov 87 17:22 EST
> Subject: subcommittees
> From: MATHIS@A.ISI.EDU
> To: x3j13@SAIL.STANFORD.EDU
> Message-ID: <[A.ISI.EDU]29-Nov-87 17:22:16.MATHIS>
> here is my version of how the subcommittee evolved at the Ft. Collins
> meeting. PLEASE send me any additions or other corrections.
> If you have an electronic mailing list, please let me know and tell
> me how people outside the subcommittee should be involved with that
> list (if at all)
> X3J13 Subcommittees (as of November 29, 1987
> (Mathis, Steele, and Gabriel try to follow all)
> Clean-up
> Larry Masinter
> Guy Steele
> Kent Pitman
> JonL White
> JScott Fahlman
> David Moon
> Ellen Waldrum
Rather than my embarassing myself by misspelling your name or otherwise mangling
the introduction, or including some and not others... Lets have another round
of mail-check: For those who are not in the list above, please send a brief
message to CL-CLEANUP@SU-AI.STANFORD.EDU, introducing yourself. Please do not
use the word "Axolotl" in your reply.
- - - - -
This is the current distribution list for cl-cleanup@Sail.stanford.edu:
rpg
#clclea.msg[com,lsp]
Fahlman@C.CS.CMU.EDU
chiles@C.CS.CMU.EDU
ram@C.CS.CMU.EDU
mcdonald@C.CS.CMU.EDU
gls@THINK.COM
"xerox-cl-cleanup↑.pa"@XEROX.COM
(Brotsky.PA, Daniels.PA, Gregor.PA, Masinter.PA, Pavel.PA, Pedersen.PA)
(redistribution to: "Dieter Kolb:ZTISOF:Siemens")
"hpfclp!dcm"@HPLABS.HP.COM
"hpfclp!cl-technical"@HPLABS.HP.COM
kmp@SCRC-STONY-BROOK.ARPA
Moon@SCRC-STONY-BROOK.ARPA
"edsel!cl-cleanup-dist"@LABREA.STANFORD.EDU
Mathis@C.ISI.EDU
brittain@A.ISI.EDU
mly-lispm@AI.AI.MIT.EDU
JAR-CL@AI.AI.MIT.EDU
"willc%tekchips.tek.com"@RELAY.CS.NET
"Haug%ti-csl"@RELAY.CS.NET
"Waldrum%ti-csl"@RELAY.CS.NET
wjr@SCRC-STONY-BROOK.ARPA
"chapman%aitg.dec"@DECWRL.DEC.COM
pierson@multimax.arpa
"franz!akbar!layer"@ucbarpa.Berkeley.EDU
padget@RAND-UNIX.ARPA
∂01-Dec-87 2016 CL-Cleanup-mailer introduction
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 20:16:29 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA02402; Tue, 1 Dec 87 20:16:38 PST
Received: from akbar by franz (5.5/3.14)
id AA09817; Tue, 1 Dec 87 20:07:56 PST
Received: by akbar (5.5/3.14)
id AA28657; Tue, 1 Dec 87 20:03:54 PST
From: franz!akbar!layer@ucbarpa.Berkeley.EDU (Kevin Layer)
Return-Path: <akbar!layer>
Message-Id: <8712020403.AA28657@akbar>
To: cl-cleanup@sail.stanford.edu
Subject: introduction
Date: Tue, 01 Dec 87 20:03:53 PST
Hello,
I'm a lisp hacker a Franz Inc. and I'm mainly on the cleanup mailing
list to monitor the activity and pitch in the "current practice" for
our Common Lisp (Allegro CL, used to be Extended Common Lisp). I
also volunteered to write-up a few issues at the Ft. Collins meeting,
which I'll be getting to soon...
Kevin Layer
ucbvax!franz!layer
layer%franz.uucp@Berkeley.EDU
∂01-Dec-87 2053 CL-Cleanup-mailer introduction
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 20:53:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 292457; Tue 1-Dec-87 23:22:58 EST
Date: Tue, 1 Dec 87 23:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: introduction
To: Kevin Layer <franz!akbar!layer@ucbarpa.Berkeley.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8712020403.AA28657@akbar>
Message-ID: <19871202042310.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 01 Dec 87 20:03:53 PST
From: franz!akbar!layer@ucbarpa.Berkeley.EDU (Kevin Layer)
I'm a lisp hacker a Franz Inc. and I'm mainly on the cleanup mailing
list to monitor the activity and pitch in the "current practice" for
our Common Lisp (Allegro CL, used to be Extended Common Lisp).
Welcome. I think we've suffered from a lack of coverage in the
"current practice" department, so I'm glad to see you join.
∂02-Dec-87 1008 CL-Cleanup-mailer Re: CL-CLEANUP membership
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 10:08:43 PST
Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Wed 2 Dec 87 10:03:14-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Wed, 2 Dec 87 10:08:24 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Wed, 2 Dec 87 10:27:53 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 2 Dec 87 10:27:35 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 2 Dec 87 10:26:14 mst
Return-Path: <dcm@hpfcdcm>
To: cl-cleanup@sail.stanford.edu
Subject: Re: CL-CLEANUP membership
X-Mailer: mh6.5
In-Reply-To: Your message of 30 Nov 87 11:39:00 -0800.
<871130-114008-117@Xerox>
Date: Wed, 02 Dec 87 10:26:05 MST
Message-Id: <13622.565464365@hpfcdcm>
From: Dave Matthews <dcm%hpfclp@hplabs.HP.COM>
"hpfclp!dcm"@HPLABS.HP.COM
Dave Matthews of Hewlett Packard. I am following the
conversation and provide current practice information when
appropriate.
"hpfclp!cl-technical"@HPLABS.HP.COM
Pipe to notes system for other reviewers within HP.
Dave
∂02-Dec-87 1119 CL-Cleanup-mailer Re: CL-CLEANUP membership
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 2 Dec 87 11:19:09 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA00566; Wed, 2 Dec 87 14:23:06 EST
Message-Id: <8712021923.AA00566@multimax.ARPA>
To: Masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.stanford.edu
Subject: Re: CL-CLEANUP membership
In-Reply-To: Your message of 30 Nov 87 11:39:00 -0800.
<871130-114008-117@Xerox>
Date: Wed, 02 Dec 87 14:23:02 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
I'm Dan Pierson <pierson@multimax.arpa> working on Common Lisp for the
Encore Multimax. First serial, then parallel (the Multimax is a
shared memory multiprocessor). I'm currently working on four writeups
for this committee.
∂02-Dec-87 1202 CL-Cleanup-mailer intro
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 12:02:17 PST
Date: Wed, 2 Dec 87 15:05:57 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: intro
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <293701.871202.JAR@AI.AI.MIT.EDU>
I'm Jonathan Rees (JAR@AI.AI.MIT.EDU). I'm a graduate student at MIT
working on Scheme and related things, and also a consultant for the VAX
(Common) Lisp development group at DEC.
∂02-Dec-87 1421 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 4)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 14:20:51 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Wed, 2 Dec 87 17:20:07 EST
Received: by kali.think.com; Wed, 2 Dec 87 17:20:03 EST
Date: Wed, 2 Dec 87 17:20:03 EST
From: gls@Think.COM
Message-Id: <8712022220.AA04837@kali.think.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 23 Nov 87 12:25 PST <871123-122535-2508@Xerox>
Subject: Issue: APPEND-DOTTED (Version 4)
I support APPEND-DOTTED:REPLACE, version 4.
∂02-Dec-87 1422 CL-Cleanup-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 14:22:09 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Wed, 2 Dec 87 17:20:55 EST
Received: by kali.think.com; Wed, 2 Dec 87 17:20:50 EST
Date: Wed, 2 Dec 87 17:20:50 EST
From: gls@Think.COM
Message-Id: <8712022220.AA04840@kali.think.com>
To: Masinter.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 23 Nov 87 12:42 PST <871123-124211-2551@Xerox>
Subject: Issue: ASSOC-RASSOC-IF-KEY (Version 4)
I am indifferent on this issue.
∂02-Dec-87 1528 CL-Cleanup-mailer intro
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 15:28:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 DEC 87 14:47:16 PST
Date: Wed, 2 Dec 87 14:31:47 PST
From: Pavel.pa@Xerox.COM
Subject: intro
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <871202-144716-1018@Xerox>
I'm Pavel Curtis (Pavel.pa@Xerox.Com) and I'm currently trying both to finish my
thesis and not to get overly committed to work on any proposals unless there's a
crying need. I read all of the ones that come across, though. I expect to be
much more active when the thesis is done, in another couple of months or so.
Pavel
∂02-Dec-87 1941 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 19:41:22 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Dec 87 22:40:45-EST
Date: Wed, 2 Dec 1987 22:40 EST
Message-ID: <FAHLMAN.12355411187.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: sandra%orion@CS.UTAH.EDU
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
In-reply-to: Msg of 1 Dec 1987 11:46-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Rather than introduce some godawful kludge for declaring the type of
&rest lists (only), we should probably try to clean up the inadequacies
of the LIST data-type specification. There should be some long-form
declaration for LIST that allows you to declare the element-type and
length, similar to the declarations for vectors.
We might or might not want to add a "true list" data type at the same
time. A "true list" is finite in the CDR direction and terminates in
NIL. I can forsee some arguments about whether LIST in a declaration
should mean "true list", or whetehr we should give a new name to true
lists.
This is just a trial balloon -- if there is some enthusiasm for this
idea, I'll turn it into a real proposal. If not, we can go back to
discussing kludges for indicating the element-type in an &REST list.
-- Scott
∂02-Dec-87 2043 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 20:42:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 20:41:08 PST
Date: 2 Dec 87 20:40 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Wed, 2 Dec
87 22:40 EST
To: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-204108-1072@Xerox>
I'm tempted to try to address several issues with FUNCTION declarations at once.
1) I realize now that I do not understand the import of *any* of the argument
type specifiers, and specificly the language about "at least of the types
specified" that appears in CLtL p 47. However, I don't know what
(declare (function my-cons (float string) list) )
means. It says that my-cons is a function that can "accept a floating-point
number and a string (among other things), and its result is an object of type
list...."
The problem is that the argument type declaration here is of absolutely no use.
That the declared function can accept a float and a string among other things
has no content. It doesn't say that it is illegal to pass a non-float as the
first argument. It says that if you pass a float, its ok, and if you pass a
non-float, it might be OK too. Isn't that the same as saying (function my-cons
(t t) list)?
It would be more valuable as far as I can see to say that a (function (float
string) list) is one to which *only* a float and a string can be passed. Perhaps
someone familiar with an implementation that pays attention to these
declarations can explain what they are used to denote?
2) On the specific issue at hand: I'm inclined to be more sympathetic to
allowing &REST <element-type>; function type specifiers are, after all, already
a specialized little language -- the &KEY arguments have a separate syntax which
only vaguely resembles the original lambda list syntax, for example.
3) Should the function type specifier also allow &ALLOW-OTHER-KEYS?
Here is some (old) mail from the Common Lisp mailing list which touches on some
related issues:
!
Date: 18 Apr 1986 16:07-EST
Subject: Type Specifier: (OR (FUNCTION ...) ...)
From: NGALL@G.BBN.COM
Question: What is the 'most informative' type specifier for the CL function
COPY-SEQ?
How 'bout? (function (sequence) sequence)
Unfortunately, this does not tell the reader nor the compiler that if the
argument is a list, then the result is also a list, and vice versa. So how
about this:
(or (function (list) list)
(function (vector) vector))
This is syntactically valid CL, and the definition of the OR and FUNCTION type
specifiers makes it meaningful. Unfortunately, it is not clear from pg. 158
whether or not the following is legal:
(proclaim '(ftype (or (function (list) list)
(function (vector) vector))
copy-seq))
It is not legal in VaxLisp, and my guess is that there aren't any
implementations that would do the right thing with it. So I would like to
propose that such a use of OR/FUNCTION be considered legal CL.
Without such a declaration, one is forced to either wrap (the <result-type> ...)
around all calls to such functions or to DECLARE a restricted version of
FUNCTION in the appropriate places, e.g., (defun foo (alist avector)
(declare (list alist)
(vector avector)
(function copy-seq (list) list))
(zap (copy-seq alist)
(let ()
(declare (function copy-seq (vector) vector))
(zoop (copy-seq avector))))
Either method is a real pain.
This use of OR would give CL something akin to Ada overloading. It allows the
overloading of multiple 'function type signatures' on a single function name.
Such overloading is already implicit throughout CL (esp. the seq. functions).
My proposal would merely allow a way of describing it.
-- Nick
!
Date: Mon, 4 Nov 85 22:29 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Declaring Functions
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
Message-ID: <851104222904.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
In-Reply-To: <8511012045.AA07112@utah-orion.ARPA>
Date: Fri, 1 Nov 85 13:45:55 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
The notion of a function type is mentioned in two places: p. 47 of the
CLM, where the (function ...) type specifier is defined, and p. 158-159,
where (ftype ...) and (function ...) are defined as options to declare.
Are they intended to be the same?
Read page 159 more carefully. It explains that they have the same meaning, but
are syntactically different. "function" has the disadvantage that you can only
declare one thing per clause, unlike most other declarations, but the advantage
that it looks mildly like "defun".
If so, then the second definition
should say that keywords and a (values ...) type specifier are allowed.
If by keywords you mean &optional and friends, it isn't strictly necessary to
repeat that, although it would sure clear things up if there were a cross
reference in the book.
However, there appears to be a typo on page 159. The form following the phrase
"entirely equivalent to", which currently reads
(ftype (function arglist result-type1 result-type2 ...) name)
ought to read
(ftype (function arglist (values result-type1 result-type2 ...)) name)
in order to be consistent with page 47.
∂02-Dec-87 2146 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 21:46:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 21:42:53 PST
Date: Wed, 2 Dec 87 21:42:47 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: <871202-204108-1072@Xerox>
To: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-214253-1099@Xerox>
Larry says:
``I don't know what (declare (function my-cons (float string) list) ) means.''
It is usual in type theory for this to be read as an implication:
IF
you pass a float and a string to MY-CONS
THEN
MY-CONS is guaranteed to return a list.
More rigorously, a type theorist would see (function my-cons (float string)
list) as representing the set of all functions that, when applied to a float and
a string, return a list.
Under this view of types, we understand the constructor OR to be set-union (that
is, the type (OR t1 t2) represents the set of values in the union of the sets
represented by t1 and t2) and the AND constructor is thus set intersection.
Under this view, Nick Gall gives the wrong answer to his question about a
specific type for COPY-SEQ when he claims that a good one would be
(or (function (list) list)
(function (vector) vector))
Since this does not guarantee that COPY-SEQ will return a list when applied to a
list; in fact, a function in this type might very well bomb when presented with
a list. In general, ORing function types isn't very helpful. What he really
wants here is AND, not OR:
(and (function (list) list)
(function (vector) vector))
This represents the set of functions that both map lists to lists and vectors to
vectors.
Let me point out that I'm not claiming that this is how CLtL intends function
types to be interpreted, just that this meaning has proven very convenient for
most uses.
Pavel
∂02-Dec-87 2225 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 22:25:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 22:20:29 PST
Date: 2 Dec 87 22:20 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Pavel.pa's message of Wed, 2 Dec 87 21:42:47 PST
To: Pavel.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-222029-1111@Xerox>
Under the interpretation outlined in your message, it would not be valid to assume, given
(declare (function my-cons (float string) list) )
that
(typep (my-cons x y) 'list)
can be assumed, unless it was also asserted (declare (float x) (string y))?
∂02-Dec-87 2236 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 22:36:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 22:36:23 PST
Date: Wed, 2 Dec 87 22:36:17 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: <871202-222029-1111@Xerox>
To: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-223623-1122@Xerox>
That's right. Unless you know something about the types of the arguments, you
can assume nothing about the type of the result.
Pavel
∂03-Dec-87 0953 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Dec 87 09:53:41 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 294082; Thu 3-Dec-87 12:53:18 EST
Date: Thu, 3 Dec 87 12:52 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
In-Reply-To: <871202-204108-1072@Xerox>
Message-ID: <871203125256.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 2 Dec 87 20:40 PST
From: Masinter.pa@Xerox.COM
...
(declare (function my-cons (float string) list) )
...
The problem is that the argument type declaration here is of absolutely
no use.
...
It would be more valuable as far as I can see to say that a
(function (float string) list)
is one to which *only* a float and a string can be passed. Perhaps
someone familiar with an implementation that pays attention to these
declarations can explain what they are used to denote?
In Maclisp, if you declared a function to take arguments (fixnum flonum),
for example, special tricks were allowed to be done with passing the arguments
without having to heap-cons them. You were required to only use this declaration
if you had made it available to the compiler at the time of compiling the function
(so that it would have done the special tricks necessary to make the external
calling sequence work). The net effect was that the function had a naive entry
point (for people who didn't know about the declaration) and a magic entry point
for people who wanted to exploit the declaration information and bypass some
setup instructions.
In order to get this effect in CL, we have only to restrict the declaration of
a function to be exactly the declaration that the function was compiled under.
That is, there are a number of possible universes we could elect to be in:
* We could allow local function declarations to just say things we know to
be true, regardless of whether they were interesting. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)
This would tend to thwart interesting compilations because nothing in the
declaration would tell you anything useful about how the function was compiled.
* We could allow local function declarations only if they restrict the
declaration under which the function was compiled. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
but not by
(LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)
This might thwart some interesting compilations because you wouldn't know
everything about the way the function was compiled, but you'd know some
information.
* We could allow local function declarations only if they exactly match
the declaration under which the function was compiled. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
but not by
(LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)
This would have the best chance of getting interesting compilations, I think.
* We could, as I guess Pavel is suggesting (though I lost or missed the
original mail), allow multiple declarations of the same function, in which
case the information provided would be of an entirely different nature (in
what amounts to a DEFMETHOD style) than what it's used for in the previous
three bullet items.
Presumably there are some gains to be had from this style. I have no feel for
how useful they are. An example, though, would be:
(PROCLAIM '(FUNCTION FOO (LIST) LIST))
(PROCLAIM '(FUNCTION FOO (VECTOR) VECTOR))
which would let you compile
(LENGTH (FOO (THE LIST L)))
into
(SYSTEM:LENGTH-ROUTINE-FOR-THINGS-KNOWN-TO-BE-OF-TYPE-LIST (FOO L))
[Sigh. I'd have called it SYSTEM:LIST-LENGTH, but that's taken by CLtL for
something that doesn't mean what I think of as LIST-LENGTH. A poor naming
decision if you ask me...]
* This is a placeholder to remind readers that the likelihood that this list is
exhaustive is fairly low.
This really gets at the heart of the problem, which is:
* Are declarations just for compilation or do they serve some more abstract
higher level goal (eg, "documentation").
* How important is exact-typep information vs typep information.
* How much of a modularity violation (or documentation constraint) is it to
have to know the exact conditions under which a function was compiled.
* How important are optimal compilations?
∂03-Dec-87 1042 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Dec 87 10:42:12 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 3 Dec 87 13:41:26 EST
Received: by kali.think.com; Thu, 3 Dec 87 13:41:22 EST
Date: Thu, 3 Dec 87 13:41:22 EST
From: gls@Think.COM
Message-Id: <8712031841.AA07746@kali.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 1 Dec 87 11:25 EST <871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE
Date: Tue, 1 Dec 87 11:25 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
I think the remark about aesthetics not counting at all in FORMAT is cute
but not strictly true. But since I don't have anything more consequential
to write there, I'll suggest the following compromise presentation which
(for the sake of casual readers and future historians) makes it more clear
that we're being flippant -- or at least less clear that we're being
serious...
Aesthetics:
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele, Jr.
I would accept this friendly amendment.
--Guy
∂03-Dec-87 1059 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 10:58:54 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA20506; Thu, 3 Dec 87 11:57:15 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA21459; Thu, 3 Dec 87 11:57:05 MST
Date: Thu, 3 Dec 87 11:57:05 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712031857.AA21459@orion.utah.edu>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: Masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu,
sandra%orion@cs.utah.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 3 Dec 87 12:52 EST
One reason for wanting to use a FUNCTION type specifier is that you may
only be concerned with how many arguments a function can take, and you
don't care at all about their types. Back when we were trying to
implement a CL compatibility package in PSL, we wanted to do the
matching of actual arguments to lambda variables at compile-time so we
could use the EXPR call protocol instead of the much slower NEXPR
protocol. (Basically, we had an EXPR entry point for every function
with a 1-1 correspondence between actual arguments and lambda
variables.) The problem is, you couldn't do the transformation on a
call unless you already knew something about the lambda list for the
function.
I agree that the argument type business is confusing and not very useful
in its current state. I'd like to say that
(LOCALLY (DECLARE (FTYPE (FUNCTION (INTEGER INTEGER) INTEGER) +))
(+ X Y))
is equivalent to
(THE INTEGER (+ (THE INTEGER X) (THE INTEGER Y)))
but I'm not sure that's exactly what CLtL is getting at.
-Sandra
-------
∂03-Dec-87 1059 CL-Cleanup-mailer CL-CLEANUP membership
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Dec 87 10:59:19 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 3 Dec 87 13:58:48 EST
Received: by kali.think.com; Thu, 3 Dec 87 13:58:44 EST
Date: Thu, 3 Dec 87 13:58:44 EST
From: gls@Think.COM
Message-Id: <8712031858.AA07850@kali.think.com>
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 30 Nov 87 11:39 PST <871130-114008-117@Xerox>
Subject: CL-CLEANUP membership
I am sending this message merely to remark that, inasmuch as my
name *was* on the list Mathis sent out, it is necessary for this
message to contain the word "axolotl" in order to distinguish it
from valid replies to Larry's request.
Sorry, but I could not resist.
--Guy
∂03-Dec-87 1123 CL-Cleanup-mailer FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: cl-cleanup@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I'd like to reiterate what Pavel said: the declaration
(declare (function my-cons (float string) list) )
means that the function MY-CONS accepts two arguments, the first at least
of the type FLOAT (it can be a more general type), and the second at least
of the type STRING; it returns one value which is of the type LIST (it
could be more specific).
Unfortunately, it does not mean that if the two arguments are of types
FLOAT and STRING then the result is of type LIST, which would be
useful.
Lucid has a variant of this called RESTRICTIVE-FTYPE (or something),
which would mean MY-CONS assumes it receives two arguments of types
FLOAT and STRING and produces something of type LIST.
See page 47 (CLtL), the last complete paragraph, to see this.
-rpg-
∂03-Dec-87 1215 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 3 Dec 87 12:15:27 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 301485; Thu 3-Dec-87 14:17:50 EST
Date: Thu, 3 Dec 87 14:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: sandra%orion@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Masinter.pa@xerox.com,
cl-cleanup@sail.stanford.edu
In-Reply-To: <8712031857.AA21459@orion.utah.edu>
Message-ID: <871203141725.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 3 Dec 87 11:57:05 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
One reason for wanting to use a FUNCTION type specifier is that you may
only be concerned with how many arguments a function can take, and you
don't care at all about their types. ...
Thanks for remembering to mention this issue. It pops into my head from time to time
and then I always forget it before I get to the console.
Yes, the same style of issues as I raised in my last message applies to argument
number. eg, if I did
(PROCLAIM '(FUNCTION FOO (NUMBER NUMBER) NUMBER))
(DEFUN FOO (X Y) (+ X Y))
and later did:
(LOCALLY (DECLARE (FUNCTION FOO (FIXNUM &REST (LIST T)) FIXNUM)) ... (FOO ...) ...)
would I be within reason? ie, is there semantic impact to the &REST which goes beyond
type declaring the rest of the arguments to be of type T? Am I also declaring that the
function was in fact compiled believing that a &REST style argument pickup was used
(and at the same point as I've specified it here). What about:
(PROCLAIM '(FUNCTION FOO (NUMBER &REST (LIST NUMBER)) NUMBER))
(DEFUN FOO (X &REST Y) (APPLY #'+ X Y))
and then later
(LOCALLY (DECLARE (FUNCTION FOO (NUMBER NUMBER &REST (LIST NUMBER)) NUMBER))
... (FOO ...at least two arguments...) ...)
In my CL conversion of Macsyma, I threw out all the *LEXPR declarations because
CL couldn't make any use of them and they were just clutter. (And they'd be trivial
to re-conjure if they were ever needed.) But I felt funny as I did it because I did
know I was throwing away information that would be interesting to some compilers
and that seemed sad, so I definitely agree that one way or another, this is a real
issue.
∂03-Dec-87 1331 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 13:31:12 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Dec 87 16:30:32-EST
Date: Thu, 3 Dec 1987 16:30 EST
Message-ID: <RAM.12355605918.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>, cl-cleanup@SAIL.STANFORD.EDU,
Masinter.pa@XEROX.COM, sandra%orion@CS.UTAH.EDU
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Msg of 3 Dec 1987 12:52-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
My compiler cleanup proposal addresses a number of the issues being
discussed here. We already went around once on cl-cleanup about the
meaning function type.
In my initial proposal, I had assumed a strict interpretation of
function type. It was pointed out to me, that not only is CLTL very
clear about its non-restrictive interpretation, it is also very
difficult to use a strict interpretation within the framework of the
current type system.
Basically, the problem is that if you think about "function type
declarations" as being declarations about the type of the object which
is the function, then it isn't possible to use a strict
interpretation. If you attempt to do so, then there will be cases
where a type declaration is necessary for a program to be correct, and
removing declarations can cause a program to be incorrect. In
addition to problems with defining where declarations are necessary,
requiring declarations is also clearly in conflict with the stated
goals for declarations in Common Lisp.
Basically, the reason for this non-intuitive result is that a
declaration of a function's type actually makes a statement about what
definitions are legal, rather than what calls are legal. What a
compiler really wants to know is what calls are legal.
The solution I suggest in my proposal is to introduce a mechanism that
allows arbitrary information about a function definition to be bound
at compile time. You don't declare the function type, you just define
the function, with any appropriate argument type declarations.
Since you have asserted that calls to the function can be bound at
compile time, the compiler can apply any assertions on the formal
parameters to the actual parameters and use type information derived
from the definition as the type of the call result.
Early-binding of function names also allows many other optimizations
such as "inline expansion" and "block compilation".
Before people flame uncotrollably about the horror of static function
binding in Lisp, I will point out that I don't propose that static
function binding be required, or even that it necessarily be the
default. It is also worth noting that the extent to which static
binding is actually done once it has been allowed is an implementation
decision. Declaring static binding doesn't necessarily prevent
incremental redefintion or reduce safety, it might only cause better
compiler warnings to be generated.
If this capability exists, then function type declarations (and
function types) are more useless than they currently are (if that is
even possible).
Rob
P.S. My proposal is <ram>cprop.txt on c.cs.cmu.edu
∂04-Dec-87 1430 CL-Cleanup-mailer Issue: LAST-N (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Dec 87 14:30:43 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 295555; Fri 4-Dec-87 16:49:13 EST
Date: Fri, 4 Dec 87 16:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAST-N (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871204164910.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: LAST-N
References: LAST (p267)
Category: ENHANCEMENT
Edit history: 04-Dec-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
People always ask why LAST returns a cons and not an element.
BUTLAST takes an argument N but LAST does not.
Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT):
Allow LAST to take an optional argument N, saying how many cells to return.
It is an error if N is negative or L is circular.
If N is equal to the number of cons cells in the list L, then the atom which
terminates the list L is returned.
If N is greater than the number of cons cells in the list L, then it is an
error if the list is not a proper list. If in this case the list is a proper
list, then L is returned.
Test Cases:
(LAST '(A B C) 0) => ()
(BUTLAST '(A B C) 0) => (A B C)
(LAST '(A B C) 1) => (C)
(BUTLAST '(A B C) 1) => (A B)
(LAST '(A B C) 2) => (B C)
(BUTLAST '(A B C) 2) => (A)
(LAST '(A B C) 3) => (A B C)
(BUTLAST '(A B C) 3) => ()
(LAST '(A B C) 4) => (A B C)
(BUTLAST '(A B C) 4) => ()
(LAST '(A B C)) => (C)
(BUTLAST '(A B C)) => (A B)
(LAST '(A . B) 0) => B
(LAST '(A . B) 1) => (A . B)
(LAST '(A . B) 2) is an error.
Rationale:
BUTLAST and LAST would select complementary parts of a list in general.
That is (EQUAL L (APPEND (BUTLAST L N) (LAST L N))) would be T for N >= 0
and L being a proper list.
This would make it more obvious why LAST should return a list and not
an element. ie, it would return the "last N elements" where N=1 by default.
Current Practice:
Probably nobody does this.
Adoption Cost:
Very slight. The following code would suffice:
(DEFUN LAST (LIST &OPTIONAL (N 1))
(CHECK-TYPE N (INTEGER 0))
(DO ((L LIST (CDR L))
(R LIST)
(I 0 (+ I 1)))
((ATOM L) R)
(IF (>= I N) (POP R))))
Some implementations might want to provide compiler optimizations for
the N=1 case.
Benefits:
This utility is probably needed often enough to warrant its inclusion.
It's present (as a separate function called NLEFT) in Symbolics Common
Lisp and Interlisp.
Conversion Cost:
None. This is an upward compatible extension.
Aesthetics:
This would make things a little prettier.
Discussion:
This suggestion came up recently on a Symbolics design discussion list.
Symbolics is contemplating offering it as an extension, but it seemed like
the rest of the CL community might want to adopt it, too. Pitman thinks
it's a nice idea.
∂04-Dec-87 1449 CL-Cleanup-mailer Issue: LAST-N (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 14:49:42 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 4 Dec 87 17:49:16-EST
Date: Fri, 4 Dec 1987 17:49 EST
Message-ID: <FAHLMAN.12355882409.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: LAST-N (Version 1)
In-reply-to: Msg of 4 Dec 1987 16:49-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Seems harmless enough... No strong opinion one way or the other.
-- Scott
∂04-Dec-87 1535 CL-Cleanup-mailer Issue: LAST-N (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Dec 87 15:35:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 295702; Fri 4-Dec-87 18:35:08 EST
Date: Fri, 4 Dec 87 18:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAST-N (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871204164910.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871204233526.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 4 Dec 87 16:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Issue: LAST-N
References: LAST (p267)
Category: ENHANCEMENT
Edit history: 04-Dec-87, Version 1 by Pitman
Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT):
Allow LAST to take an optional argument N, saying how many cells to return.
You should say explicitly that the default for N is 1.
The following two paragraphs cannot be correct. For example, think about
(last '(a)), which you are saying returns nil.
If N is equal to the number of cons cells in the list L, then the atom which
terminates the list L is returned.
If N is greater than the number of cons cells in the list L, then it is an
error if the list is not a proper list. If in this case the list is a proper
list, then L is returned.
I think what you really mean is
If N is zero, then the atom that terminates the list L is returned.
If N is greater than or equal to the number of cons cells in
the list L, then the result is L.
This correction makes it consistent with your examples.
With these corrections, I don't oppose the proposal. I'm not strongly in
favor of it, since I put less priority on enhancements than on correcting
mistakes in what we've got already. I'll favor it if others do.
∂04-Dec-87 1729 CL-Cleanup-mailer Re: Issue: LAST-N (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Dec 87 17:28:54 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 DEC 87 15:35:33 PST
Date: 4 Dec 87 15:35 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: LAST-N (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Fri, 4 Dec 87 16:49 EST
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <871204-153533-228@Xerox>
I don't much care. It basically looks OK.
-- Andy. --
∂04-Dec-87 1729 CL-Cleanup-mailer Introduction
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Dec 87 17:29:01 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 DEC 87 15:38:37 PST
Date: 4 Dec 87 15:38 PST
From: Daniels.pa@Xerox.COM
Subject: Introduction
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871204-153837-228@Xerox>
Hello all. I'm a senior developer with Xerox's AI group. I'm also one of the two
members of the error system subgroup. I'm on this particular list mainly to keep
an eye on the accepted cleanups and changes and make sure our implementation
conforms.
For the most part, other people seem to adequately cover the space of things
I've wanted to say, so you're not likely to see much mail from me.
-- Andy. --
∂05-Dec-87 0001 CL-Cleanup-mailer Introduction
Received: from UUNET.UU.NET by SAIL.STANFORD.EDU with TCP; 5 Dec 87 00:01:45 PST
Received: from unido.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA28402; Sat, 5 Dec 87 03:01:28 EST
Received: by unido.uucp with uucp;
Sat, 5 Dec 87 08:30:41 +0100
From: "Dieter Kolb" <unido!ztivax!kolb@uunet.UU.NET>
Date: Fri, 4 Dec 87 16:12:40 -0100
Message-Id: <8712041512.AA03656@ztivax.uucp>
Received: by ztivax.uucp; Fri, 4 Dec 87 16:12:40 -0100
To: CL-Cleanup@sail.stanford.edu
Subject: Introduction
I am Dieter Kolb of Siemens AG, West Germany. In my group we
are developing a Common LISP system for Siemens computers.
I am also member of the EuLisp group in Europe.
I am following the conversion on CL-Cleanup to get information
for our implementation activities as well as to provide discussion
contributions based on our experience with the language.
Dieter Kolb
Siemens AG
ZTI SOF 23
Otto Hahn Ring 6
D-8000 Munich 83
Phone: +49-89-636-2386
ARPA net address: unido!ztivax!kolb@SEISMO.CSS.GOV
Xerox Internet address: kolb:ztisof:siemens
∂06-Dec-87 1424 CL-Cleanup-mailer Issue: DRIBBLE-TECHNIQUE (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 Dec 87 14:24:29 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 296206; Sun 6-Dec-87 17:14:51 EST
Date: Sun, 6 Dec 87 17:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DRIBBLE-TECHNIQUE (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871206171357.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: DRIBBLE-TECHNIQUE
References: DRIBBLE (p443)
Category: CLARIFICATION
Edit history: 06-Dec-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The intent and effect of DRIBBLE is not very clearly specified.
Proposal (DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE):
Clarify that DRIBBLE is intended primarily for interactive debugging
and that its effect cannot be relied upon from programs.
Test Case:
#1: (PROGN (DRIBBLE "temp")
(PRINT 'FOO)
(DRIBBLE))
#2: (DRIBBLE "temp")
(PROGN (PRINT 'FOO)
(DRIBBLE)
(PRINC 'BAR))
Rationale:
Users of DRIBBLE have been surprised about how differently DRIBBLE
behaves in different implementations. This makes the status quo
much more explicit and will lead to less surprise.
Current Practice:
Some implementations implement DRIBBLE as a function which simply
assigns streams such as *STANDARD-OUTPUT* to broadcast streams
(or the approximate equivalent thereof). Even within this camp,
there is not widespread agreement about which streams are affected.
However, typically test case #1 will capture the output of (PRINT 'FOO)
in the file "temp" and will execute (PRINT 'BAR) but not capture its
output.
Some implementations (eg, Symbolics) push to a recursive command
loop when DRIBBLE is called with an argument, and return from that
command loop when DRIBBLE is called with no argument. In these
implementations, test case #1 will enter a recursive command loop
upon the first call to DRIBBLE and will not execute the (PRINT 'FOO)
until (DRIBBLE) is done interactively. When the second (DRIBBLE)
in test case #1 is executed, DRIBBLE will complain that output is
not currently being recorded. In test case #2, the output of
(PRINT 'FOO) will be captured, but the form (PRINT 'BAR) will never
be executed because (DRIBBLE) does not return normally (it throws).
Adoption Cost:
None. This is just a clarification.
Benefits:
Users will be aware that they cannot rely on DRIBBLE in portable code.
Conversion Cost:
Effectively none. Anyone who currently uses DRIBBLE in code that is
believed to be portable is kidding himself. If such code works in some
implementations, it can continue to work.
Aesthetics:
Since this is a clarification, there is no significant change to
the aesthetics.
Discussion:
Pitman wrote this proposal as a straw man so that CL-Cleanup would have
the issue on the books for explicit discussion.
∂06-Dec-87 1435 CL-Cleanup-mailer Introduction
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Dec 87 14:35:08 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 DEC 87 14:35:09 PST
Date: 6 Dec 87 14:28 PST
From: pedersen.pa@Xerox.COM
Subject: Introduction
To: CL-Cleanup@sail.stanford.edu
Message-ID: <871206-143509-2198@Xerox>
Hi,
My name is Jan Pedersen and I work for Xerox as a Xerox Lisp developer and as a
member of the Natural Language group at PARC. I'm on the CL-Cleanup list as an
observer since it is high priority here to maintain strict adherance with the
Common Lisp specification.
J.P.
∂07-Dec-87 1643 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Dec 87 16:43:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 DEC 87 15:23:50 PST
Date: 7 Dec 87 14:40 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Ram@C.CS.CMU.EDU's message of Thu, 3 Dec 87 16:30 EST
To: Ram@C.CS.CMU.EDU
cc: KMP@SCRC-STONY-BROOK.ARPA, cl-cleanup@SAIL.STANFORD.EDU,
Masinter.pa@Xerox.COM, sandra%orion@CS.UTAH.EDU
Message-ID: <871207-152350-3643@Xerox>
Ram: I've scanned your latest proposal, but it still doesn't seem to address the
minor issue at hand here:
What does
(declare (function (integer integer) t) foo)
imply?
We've discussed what it could mean, what it should mean, what CLtL says it
means, but I'd to hear about current practice. What, if anything, do current
implementations do with such declarations? Do any implementations pay attention
to the types of arguments in function declarations?
∂07-Dec-87 2038 CL-Cleanup-mailer [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 20:38:02 PST
Received: by labrea.stanford.edu; Mon, 7 Dec 87 20:31:59 PST
Received: from bhopal.lucid.com by edsel id AA02700g; Mon, 7 Dec 87 18:22:09 PST
Received: by bhopal id AA01347g; Mon, 7 Dec 87 18:22:31 PST
Date: Mon, 7 Dec 87 18:22:31 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8712080222.AA01347@bhopal.lucid.com>
To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Cc: labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 30 Nov 87 12:19 EST <19871130171930.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
re: It [density] can also be deduced from the definitions of array-total-size
and array-row-major-index, because the range of array-row-major-index's
answer is defined to be a range of integers that contains just enough
members to supply a value for each subscript set, with no gaps.
I think my previous note mentioned that density in storage isn't actually
required by this bijective mapping -- it would only do so if the output
of array-row-major-index were required to be a memory index.
Perhaps one couldn't imagine any other meaning for array-row-major-index
other than "index offset from base memory location"; but CLtL doesn't
say this now, and I can certainly think of alternative representations
which would reinject the "linearized" index into the multi-dimensional
format simply in order to preserve the documented property.
If any clarification is necessary, then it ought to take into account
the AREF-1D proposal, which would raise some efficiency questions if the
bijective mapping weren't "index-offset" memory access.
-- JonL --
∂07-Dec-87 2310 CL-Cleanup-mailer introduction
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:10:18 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa03665; 8 Dec 87 0:33 EST
Received: from csc.ti.com by RELAY.CS.NET id ac17859; 8 Dec 87 0:29 EST
Received: from ERDOS by tilde id AA29927; Mon, 7 Dec 87 19:20:20 CST
To: cl-cleanup@SAIL.STANFORD.EDU
Cc:
From: HAUG%erdos.csc.ti.com@RELAY.CS.NET
Subject: introduction
Date: 7-Dec-87 19:15:55
Sender: HAUG%erdos.csc.ti.com@RELAY.CS.NET
Message-Id: <HAUG.2774913353@ERDOS>
My name is David Haug and I work for the Symbolic Computing group at TI
and did a lot of work for the Explorer project. My participation in the
CL-cleanup group has been as an observer to keep track of changes to
the language. However, my observer status will change if I am
sufficiently stirred.
--------- DHaug
∂07-Dec-87 2315 CL-Cleanup-mailer Issue: DRIBBLE-TECHNIQUE (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:15:06 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 8 Dec 87 01:45:15-EST
Date: Sun, 6 Dec 1987 22:57 EST
Message-ID: <FAHLMAN.12356462749.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: DRIBBLE-TECHNIQUE (Version 1)
In-reply-to: Msg of 6 Dec 1987 17:13-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I support DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE.
I'm not sure exactly what KMP means by stating that this proposal is a
straw man, but I like it. I think that it was a mistake to put dribble
into the manual, and that we should just tell users that it differs from
system to system. I don't think that there's any hope of getting a
standard that makes sense on editor-top-level systems, dumb
Read-Eval-Print systems, and all the flavors in between, so we should
just punt on this.
The only advantage of mentioning DRIBBLE in the standard at all is that
users know what name to look up in any given system to get this general
sort of functionality.
-- Scott
∂07-Dec-87 2328 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:24:56 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA01737; Mon, 7 Dec 87 18:37:22 EST
Message-Id: <8712072337.AA01737@multimax.ARPA>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Date: Mon, 07 Dec 87 18:37:19 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
Issue: REDUCE-ARGUMENT-EXTRACTION
References: REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313),
see also REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF,
DELETE-IF-NOT, REMOVE-DUPLICATES, DELETE-DUPLICATES, SUBSTITUTE,
SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF,
NSUBSTITUTE-IF-NOT, FIND, FIND-IF, FIND-IF-NOT, POSITION,
POSITION-IF, POSITION-IF-NOT, COUNT, COUNT-IF, COUNT-IF-NOT,
MISMATCH, SEARCH, SORT, STABLE-SORT, MERGE (pp. 253-261),
SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT,
SUBLIS, NSUBLIS, MEMBER, MEMBER-IF, MEMBER-IF-NOT (pp. 273-275),
ADJOIN, UNION, NUNION, INTERSECTION, NINTERSECTION,
SET-DIFFERENCE, NSET-DIFFERENCE, SET-EXCLUSIVE-OR,
NSET-EXCLUSIVE-OR, SUBSETP (pp. 276-279),
ASSOC, ASSOC-IF, ASSOC-IF-NOT, RASSOC, RASSOC-IF, RASSOC-IF-NOT
(pp. 280-281)
Category: ADDITION
Edit history: Version 1 by Pierson 12/5/87
Issue: For Internal Discussion
Problem description:
REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword.
Test Cases/Examples:
Using REDUCE to obtain the total of the ages of the possibly empty
sequence of astronauts ASTROS, would currently require:
(REDUCE #'(LAMBDA (&OPTIONAL (X 0) (Y 0)) (+ (PERSON-AGE X) (PERSON-AGE Y)))
ASTROS)
If this proposal is adopted, the same result could be obtained with:
(REDUCE #'+ ASTROS :KEY #'PERSON-AGE)
Rationale:
This proposal brings REDUCE into line with the rest of the sequence
and list modifying and searching functions at the cost of slightly
blurring the meaning of :KEY arguments.
Current practice:
Does anyone currently support this as an extension?
Cost to Implementors:
This will require most implementations to make a trivial modification
to REDUCE. Implementations which wish to use this as an opportunity to
further optimize compiled calls to REDUCE will have to undertake more
work (which would be much more difficult today).
Cost to Users:
None, this is an upward compatible extension.
Cost of non-Adoption:
REDUCE will continue to be more difficult to use than other sequence
functions on sequences of complex objects.
Benefits:
REDUCE will become easier to use on sequences of complex objects. It
will be easier for compilers to convert some calls to REDUCE into
efficient loops.
Aesthetics:
Slightly damaged. All :KEY arguments are currently defined to be used
for predicates, this proposal will implicitly broaden :KEY to support
general extraction for any purpose.
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
∂08-Dec-87 0021 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87 00:20:56 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA01767; Mon, 7 Dec 87 18:40:50 EST
Message-Id: <8712072340.AA01767@multimax.ARPA>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Date: Mon, 07 Dec 87 18:40:46 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
Issue: DISASSEMBLE-SIDE-EFFECT
References: DISASSEMBLE (p. 439), COMPILE (p. 439)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 12/2/87
Status: For Internal Discussion
Problem description:
The definition of DISASSEMBLE says that "if the relevant function is
not a compiled function, it is first compiled.". The definition of
COMPILE says that "If name is a non-nil symbol, then the
compiled-function is installed as the global function definition of
the symbol...". Several implementations have taken this to mean that
if DISASSEMBLE is passed a symbol which has an uncompiled function
definition, then it has the side-effect of (COMPILE 'symbol).
Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL):
Clarify that when DISASSEMBLE compiles a function, it will never
install the newly compiled function.
Test Cases/Examples:
(DEFUN F (A) (1+ A))
(DISASSEMBLE 'F)
(TYPEP (SYMBOL-FUNCTION 'F) 'COMPILED-FUNCTION)
This code will return NIL if this proposal is adopted. Some current
implementations will return T, some will return NIL.
Rationale:
Several current implementations of DISASSEMBLE have surprising side
effects, especially for new users.
Current practice:
Allegro CL, Symbolics, and Vax Lisp install the compiled definition.
Lucid and KCL don't install it. [[This is from an informal survey at
the last meeting; please correct any mistakes.]]
Cost to Implementors:
Some implementations will have to make a simple change.
Cost to Users:
Very little. DISASSEMBLE is really part of the environment and is
probably not called by much, if any user code.
Cost of non-Adoption:
DISASSEMBLE will continue to surprise less experienced users.
Benefits:
DISASSEMBLE will become the predictable debugging function it was
meant to be.
Aesthetics:
Those who thought DISASSEMBLE was supposed to install the compiled
function may find that the language has become a little cleaner.
Discussion:
∂08-Dec-87 0728 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 07:28:44 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 8 Dec 87 10:27:51-EST
Date: Tue, 8 Dec 1987 10:27 EST
Message-ID: <FAHLMAN.12356850608.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Dan L. Pierson" <pierson@MULTIMAX.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Msg of 7 Dec 1987 18:40-EST from Dan L. Pierson <pierson at multimax.ARPA>
I support DO-NOT-INSTALL.
∂08-Dec-87 0857 CL-Cleanup-mailer Introduction
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 08:51:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 08:41:54 PST
Date: 8 Dec 87 08:41 PST
From: Brotsky.pa@Xerox.COM
Subject: Introduction
To: CL-Cleanup@sail.stanford.edu
cc: Brotsky.pa@Xerox.COM
Message-ID: <871208-084154-4763@Xerox>
I'm Dan Brotsky. I used to be at the MIT AI Lab and now I'm at Xerox PARC. I've
been fighting for years to clean up the entire first half of the alphabet,
concentrating so far primarily on the letters A, B, and M. So (as you might
imagine) I'm quite excited about participating in an effort directed at the
other 10.
dan
∂08-Dec-87 0937 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87 09:37:06 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297870; Tue 8-Dec-87 12:36:31 EST
Date: Tue, 8 Dec 87 12:36 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
To: pierson@MULTIMAX.ARPA
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8712072340.AA01767@multimax.ARPA>
Message-ID: <871208123627.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I mostly approve of the proposal contained in this write-up, though I have
some specific comments that I think should be addressed...
Date: Mon, 07 Dec 87 18:40:46 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
Issue: DISASSEMBLE-SIDE-EFFECT
...
Test Cases/Examples:
(DEFUN F (A) (1+ A))
(DISASSEMBLE 'F)
(TYPEP (SYMBOL-FUNCTION 'F) 'COMPILED-FUNCTION)
This code will return NIL if this proposal is adopted. Some current
implementations will return T, some will return NIL.
...
This isn't quite the right test case. Our Cloe implementation will return
T if this proposal is adopted because it is a compiled-only implementation.
I suggest:
(DEFUN F (A) (1+ A))
(EQ (SYMBOL-FUNCTION 'F)
(PROGN (DISASSEMBLE 'F)
(SYMBOL-FUNCTION 'F)))
I believe this will return T for all implementations if this proposal is
adopted and might return either T or NIL right now.
Current practice:
Allegro CL, Symbolics, and Vax Lisp install the compiled definition.
Lucid and KCL don't install it. [[This is from an informal survey at
the last meeting; please correct any mistakes.]]
I checked the various Symbolics implementations, and I guess my stated
beliefs in this informal survey were wrong. We don't install it so should
be listed with Lucid and KCL. [Actually, we have three situations. Our
released system signals an error, our development system compiles a dummy
function and does not install the definition, and our Cloe system (a CL
for the 80386) is a compiled-only implementation so this issue is not
meaningful.
...
Aesthetics:
Those who thought DISASSEMBLE was supposed to install the compiled
function may find that the language has become a little cleaner.
...
I would say "Some who worried..." rather than "Those who thought...".
∂08-Dec-87 0939 CL-Cleanup-mailer Re: Issue: DRIBBLE-TECHNIQUE (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 09:38:58 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 09:39:02 PST
Date: 8 Dec 87 09:38 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: DRIBBLE-TECHNIQUE (Version 1)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun, 6 Dec
87 22:57 EST
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871208-093902-4884@Xerox>
I agree that DRIBBLE should be explicitly vague.
-- Andy. --
∂08-Dec-87 0948 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87 09:48:22 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297885; Tue 8-Dec-87 12:47:14 EST
Date: Tue, 8 Dec 87 12:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
To: pierson@MULTIMAX.ARPA
cc: cl-cleanup@sail.stanford.edu, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8712072337.AA01737@multimax.ARPA>
Message-ID: <871208124709.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I mostly support the contained proposal, but have a number of specific comments...
Date: Mon, 07 Dec 87 18:37:19 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
Issue: REDUCE-ARGUMENT-EXTRACTION
References: REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313),
see also REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF,
DELETE-IF-NOT, REMOVE-DUPLICATES, DELETE-DUPLICATES, SUBSTITUTE,
SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF,
NSUBSTITUTE-IF-NOT, FIND, FIND-IF, FIND-IF-NOT, POSITION,
POSITION-IF, POSITION-IF-NOT, COUNT, COUNT-IF, COUNT-IF-NOT,
MISMATCH, SEARCH, SORT, STABLE-SORT, MERGE (pp. 253-261),
SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT,
SUBLIS, NSUBLIS, MEMBER, MEMBER-IF, MEMBER-IF-NOT (pp. 273-275),
ADJOIN, UNION, NUNION, INTERSECTION, NINTERSECTION,
SET-DIFFERENCE, NSET-DIFFERENCE, SET-EXCLUSIVE-OR,
NSET-EXCLUSIVE-OR, SUBSETP (pp. 276-279),
ASSOC, ASSOC-IF, ASSOC-IF-NOT, RASSOC, RASSOC-IF, RASSOC-IF-NOT
(pp. 280-281)
I think this references list will scare people voting. I think the references is
intended to give people an idea of how sweeping the change is. If we feel strongly
that this isn't enough, we might want to have both a references and a cross-references
field. But for now I'd just leave the references as
REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut example (pp. 312-313)
and drop the rest.
Category: ADDITION
Edit history: Version 1 by Pierson 12/5/87
Issue: For Internal Discussion
Problem description:
REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword.
This needs to be more elaborated. You need to say what the :KEY keyword will do.
The proposal part of these write-ups is intended to stand on its own.
Test Cases/Examples:
...
This is a good example.
Rationale:
This proposal brings REDUCE into line with the rest of the sequence
and list modifying and searching functions at the cost of slightly
blurring the meaning of :KEY arguments.
I would not mention the discussion of the name :KEY here at all. Leave it for
the discussion because it's confusing unless presented in full form, and it's
too much work to present here. Maybe just say:
This proposal makes many common situations where REDUCE would be useful
much less cumbersome.
Current practice:
Does anyone currently support this as an extension?
...
It's not worth mentioning in the proposal, but for your general information
so you don't think we didn't notice the question, Symbolics does not currently
support this.
Aesthetics:
Slightly damaged. All :KEY arguments are currently defined to be used
for predicates, this proposal will implicitly broaden :KEY to support
general extraction for any purpose.
I might say "Slightly damaged in one way..." and then have a second paragraph
that says "Slightly improved in another way. Many common situations where
REDUCE could be used would be easier to write and easier to later read."
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
There is no "definition" of :KEY. At best, it's an unwritten rule. It's arguably
just a coincidence. Anyway, the general sentiment of this paragraph is right,
but it should be worded more carefully so that it doesn't set a precedent for
"unwritten rules" having to be too strongly justified.
∂08-Dec-87 1121 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 11:21:10 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 11:18:30 PST
Date: 8 Dec 87 11:18 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Dan L. Pierson <pierson@multimax.ARPA>'s message of Mon, 07 Dec 87
18:40:46 EST
To: cl-cleanup@sail.stanford.edu
cc: pierson@multimax.ARPA
Message-ID: <871208-111830-5089@Xerox>
I support DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL. BTW, Xerox Lisp does not
install the compiled definition.
-- Andy. --
∂08-Dec-87 1123 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 11:22:50 PST
Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Tue 8 Dec 87 14:22:06-EST
Date: Tue, 8 Dec 1987 14:21 EST
Message-ID: <RAM.12356893261.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU, KMP@SCRC-STONY-BROOK.ARPA,
sandra%orion@CS.UTAH.EDU
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Msg of 7 Dec 1987 17:40-EST from Masinter.pa at Xerox.COM
Date: Monday, 7 December 1987 17:40-EST
From: Masinter.pa at Xerox.COM
To: Ram at C.CS.CMU.EDU
cc: KMP at SCRC-STONY-BROOK.ARPA, cl-cleanup at SAIL.STANFORD.EDU,
Masinter.pa at Xerox.COM, sandra%orion at CS.UTAH.EDU
Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
[...] What does (declare (function (integer integer) t) foo) imply?
We've discussed what it could mean, what it should mean, what CLtL
says it means, but I'd to hear about current practice. What, if
anything, do current implementations do with such declarations? Do
any implementations pay attention to the types of arguments in
function declarations?
Our current compiler totally ignores function type declarations.
I am working on a new compiler that currently gives function type
declarations a strict interpretation, i.e. the function must be called
only with two integer arguments. (I suspect that this is like the
RESTRICTIVE-FTYPE declarations that someone from Lucid mentioned.) At
least as an interpretation for FTYPE, this is clearly wrong. I intend
to at least rename this declaration, and perhaps entirely flush it as
a user-visible facility.
I think that we should either entirely flush the concept of "function
types" or change the theory behind them. The CLtL interpretation is
well-defined, but not very useful. The intuitive strict
interpretation is useful, but is not a type declaration, at least in
the sense used in CLtL.
The restrictive interpretation can be modeled as a sort of magic
syntactic shorthand for a bunch of THE declarations at the call site:
(the t (foo (the integer x) (the integer y)))
But under this interpretation, a "function type" isn't a type at all,
since it isn't in any sense the type of the function object being
called. It wouldn't be meaningful to declare a variable or value to
have a function type. A "function type declaration" would be a piece
of magic recognized by the implementation that constrains calls to a
particular function variable.
If we did this, then the concept of a "function type specifier" should
be flushed, since "function types" can't be used in any of the ways
real types can. The "function type" syntax would become part of the
syntax peculiar to a "function type declaration". (A minor beneficial
side-effect is that it would make obvious the restriction on function
types in TYPEP.)
One problem that I have with this interpretation is that it makes the
evaluation of the functional position even more peculiar than it
already is. Since a "function type declaration" would be purely
syntactic, it would only take effect when there was a syntactic match,
i.e. an obvious normal call to a declared function variable. It would
probably be incorrect to do this transformation:
(funcall #'foo x y) ==>
(the t (funcall #'foo (the integer x) (the integer y))))
Rob
∂08-Dec-87 1231 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 12:31:10 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 12:05:20 PST
Date: 8 Dec 87 12:05 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-reply-to: Dan L. Pierson <pierson@multimax.ARPA>'s message of Mon, 07 Dec 87
18:37:19 EST
To: pierson@multimax.ARPA
cc: cl-cleanup@sail.stanford.edu
Message-ID: <871208-120520-5164@Xerox>
In general I favor this proposal, but it needs some cleaning up before I'm happy
with it.
It cleans up a non-uniformity in the arguments passed to the reduction function
that has always bothered me: If there is no initial value, the first call to the
reduction function receives two sequence elements; successive calls receive an
accumulated value and a sequence element. The order of these arguments depends
on :FROM-END as well. I've taken to providing an :INITIAL-VALUE argument just to
avoid cluttering up the reduction function with the hair to handle all this.
In fact, because of this nonsense, the example given in the proposal only works
for sequences with exactly two elements. A more correct example is
(reduce #'(lambda (x y) (+ x (person-age y))) astros :initial-value 0)
NB: Since there's an initial value you can dispense with the &optional, and the
first argument to the reduction function is now always the accumulated value.
Even with this new example, I think I'd still rather write
(reduce #'+ astros :key #'person-age)
The intent of the code seems clearer to me here.
There are a few details missing from the proposal.
1) The key-fn is never applied to the initial value, if any.
2) The wording in CLtL about how the initial value participates in the reduction
will have to be changed a bit.
3) If the specified subsequence contains exactly one element, no initial value
is given, and a key-fn has been provided, it is applied to that element and the
resulting value is returned.
If people are unhappy about using the :KEY keyword for this purpose because of
the aesthetic problems, I'm happy to entertain suggestions for another keyword
to use instead.
-- Andy. --
∂08-Dec-87 1334 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 13:34:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 13:19:30 PST
Date: 8 Dec 87 12:36 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-reply-to: Dan L. Pierson <pierson@multimax.ARPA>'s message of Mon, 07 Dec 87
18:37:19 EST
To: pierson@multimax.ARPA
cc: cl-cleanup@sail.stanford.edu
Message-ID: <871208-131930-5290@Xerox>
This is a good writeup. I think we should add the alternative form
(reduce #'+ (mapcar #'person-age astros))
as the most natural equivalence; the stuff with the &optional arguments is
arcane and bogus in cases where there is an initial value.
I think that it is true that
(reduce <fn> sequence :key <key-fn>) = (reduce <fn> (mapcar <key-fn> sequence))
except of course in the matter of order of evaluation.
∂08-Dec-87 1418 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 14:18:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 14:12:24 PST
Date: 8 Dec 87 14:10 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-reply-to: Masinter.pa's message of 8 Dec 87 12:36 PST
To: Masinter.pa@Xerox.COM
cc: pierson@multimax.ARPA, cl-cleanup@sail.stanford.edu
Message-ID: <871208-141224-5386@Xerox>
Masinter writes:
I think that it is true that
(reduce <fn> sequence :key <key-fn>) = (reduce <fn> (mapcar
<key-fn> sequence))
except of course in the matter of order of evaluation.
Well, that and the fact that MAPCAR doesn't work on arrays...
-- Andy. --
∂08-Dec-87 1620 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 16:16:41 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 16:05:38 PST
Date: 8 Dec 87 15:22 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Tue, 8 Dec 87 12:36 EST
To: cl-cleanup@sail.stanford.edu
Message-ID: <871208-160538-5539@Xerox>
I think we should take a step back and ask what the place of DISASSEMBLE, ED,
TRACE, BREAK, DRIBBLE, INSPECT etc.. should be in the ANSI standard. These are
things for which constructing a denotational semantics is not feasible, cann't
be easily tested with a validation suites, etc.
I think a more global change of status for these is called for; I'd propose that
the ANSI Standard should say something like:
"The following are suggested features for a ANSI Common Lisp programming
environment. Conforming implementations are required to document what, if
anything, these functions do, in detail. However, no portable ANSI Common Lisp
program can rely on the behavior of these functions, because the behavior is
specifically not specified in the standard."
Once we move away from conformance and standard into recommendation, we might
actually be more able to make better progress recommending, for example, that
systems call their GC function (GC) and their exit function (EXIT) etc.
Opinions?
∂08-Dec-87 1644 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87 16:44:47 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA01634; Tue, 8 Dec 87 16:50:18 EST
Message-Id: <8712082150.AA01634@multimax.ARPA>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-Reply-To: Your message of Tue, 08 Dec 87 12:47:00 -0500.
<871208124709.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 08 Dec 87 16:50:09 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
Date: Tue, 8 Dec 87 12:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
There is no "definition" of :KEY. At best, it's an unwritten rule. It's arguably
just a coincidence. Anyway, the general sentiment of this paragraph is right,
but it should be worded more carefully so that it doesn't set a precedent for
"unwritten rules" having to be too strongly justified.
To quote from CLtL page 246: "If an operation tests elements of a
sequence in any manner, the keyword argument :KEY, if not NIL, should
be function of one argument that will extract from an element the part
to be tested in place of the whole element."
This seems like a definition of :KEY to me, though I will cheerfully
agree that it doesn't specify that this is the only legal meaning of
:KEY.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword.
This needs to be more elaborated. You need to say what the :KEY keyword will do.
The proposal part of these write-ups is intended to stand on its own.
The text on page 246 is also the only place that :KEY is documented in
CLtL. However, I agree that a full description should be here both
because this is a slightly different use of :KEY and because our
standard document is likely to be more verbose than CLtL.
∂08-Dec-87 1828 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 18:28:33 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Tue 8 Dec 87 21:28:09-EST
Date: Tue, 8 Dec 1987 21:28 EST
Message-ID: <FAHLMAN.12356970828.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Msg of 8 Dec 1987 18:22-EST from Masinter.pa at Xerox.COM
Explicitly excluding these environment thingies from the standard, and
demoing them to mere "suggested names" seems like a reasonable way to
go.
-- Scott
∂08-Dec-87 1836 CL-Cleanup-mailer Introductions
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 18:36:13 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Tue 8 Dec 87 21:35:51-EST
Date: Tue, 8 Dec 1987 21:35 EST
Message-ID: <FAHLMAN.12356972234.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Introductions
I'm Scott Fahlman of Carnegie-Mellon University, and most of you know
me, I think.
There are three other CMU people on the cleanup list, all full-time CMU
staff members who work with me in the CMU Common Lisp project (formerly
Spice Lisp). Dave McDonald and Bill Chiles are on the list mostly as
observers, making sure that we know about changes so that our
implementation can track them accurately. Chiles has also had some
dealings with the error committee. Rob Maclachlan (please note the
spelling) has been more vocal, especially on issues related to
compilation, types, and I/O.
-- Scott
∂09-Dec-87 0309 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Dec 87 03:03:38 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 DEC 87 03:00:06 PST
Date: 9 Dec 87 02:59 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Ram@C.CS.CMU.EDU's message of Tue, 8 Dec 87 14:21 EST
To: Ram@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871209-030006-1558@Xerox>
I think I understand and agree with most of what you say, in particular "I think
that we should either entirely flush the concept of "function types" or change
the theory behind them. The CLtL interpretation is well-defined, but not very
useful. "
There are two components to your proposal: (1) what is allowed (and what it
means), and (2) how it is described in the standard.
I like the part of your proposal which is to change the interpretation of
function declarations to mean an implicit assertion of argument and value types
(the "restrictive interpretation").
I like defining (declare (type (function (frob grid) bunker) x)) to mean
(funcall x y z) has implicitly means (the bunker (funcall (the function x)
(the frob y) (the grid z)))
I don't see, however, that there is much leverage to removing FUNCTION from the
section on type specifiers. It would do some violence to the otherwise useful
concept of
(deftype binary-arithmetic () '(function (number number) number))
to be used in
(declare (ftype binary-arithmetic x y z)) .
I don't see at all that (funcall #'foo x y) doesn't mean (the t (funcall #'foo
(the integer x) (the integer y)))) given (declare (function foo (integer
integer) t)).
In the type propagation rules, you can transform funcall and apply expressions
using the asserted value of the function argument, and the asserted value type
of #'name is derived from the asserted ftype of name.
In this interpretation, AND would distribute nicely,
Given (proclaim '(function foo (s1 t1) v1)) and (declare (function foo (s2 t2)
v2)) you could assert that
(foo x y) => (the (and v1 v2) (foo (the (and s1 s2) x) (the (and t1 t2) y))).
(OR doesn't distribute as nicely, e.g., given (declare (ftype (or (function (s1
t1) v1) (function (s2 t2) v2)) foo)), there isn't a simple way to describe the
type assertions made for (foo x y).
We might even want to explicitly allow FUNCTION declarations in THE
expressions, as in
(funcall (the binary-arithmetic x) y z).
∂09-Dec-87 0702 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87 07:02:20 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA09306; Wed, 9 Dec 87 08:00:52 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA16131; Wed, 9 Dec 87 08:00:48 MST
Date: Wed, 9 Dec 87 08:00:48 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712091500.AA16131@orion.utah.edu>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Masinter.pa@xerox.com
Cc: Ram@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu, sandra%orion@cs.utah.edu
In-Reply-To: Masinter.pa@Xerox.COM, 9 Dec 87 02:59 PST
Date: 9 Dec 87 02:59 PST
From: Masinter.pa@Xerox.COM
Given (proclaim '(function foo (s1 t1) v1)) and (declare (function foo (s2 t2)
v2)) you could assert that
(foo x y) => (the (and v1 v2) (foo (the (and s1 s2) x) (the (and t1 t2) y))).
I disagree. The DECLARE should shadow the PROCLAIM; see p. 156 of
CLtL. Or is there another proposal in the works to change declaration
shadowing as well? :-)
-Sandra
-------
∂09-Dec-87 0729 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87 07:29:24 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Wed 9 Dec 87 10:28:51-EST
Date: Wed, 9 Dec 1987 10:28 EST
Message-ID: <FAHLMAN.12357112955.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-DECLARATION issues
In-reply-to: Msg of 9 Dec 1987 05:59-EST from Masinter.pa at Xerox.COM
Seems to me that we're trying to overload the type definition for
FUNCTION in ways that are not altogether consistent. I'd suggest the
following:
1. Leave the FUNCTION type specifier alone. It's not terribly useful in
its non-restrictive form, but it is harmless and it does fit in with the
rest of the type system. (Of course, we would make it a full-fledged
type-specifier as discussed in the FUNCTION-TYPE proposal.)
2. Add an extended form for the LIST type specifier so that one can
indicate element type and, perhaps, length. This can be used to say
something useful about rest-args, without having to put in ugly special
syntax for this.
3. Add a new declaration/proclamation, distinct from TYPE, by which
users can tell the compiler restrictive things about what a given
function will accept and what it will return. This notation can be set
up so that you can say things like "if all args are integer, the result
will be" and "if the second arg is spaceship, the result will be
Martian". Obviously this bit will require some careful design so that
we can make it maximally expressive and minimally confusing. I don't
have a proposal ready; maybe Rob does.
4. Let me toss in here a related idea by Dave Touretzky that I've been
waiting to introduce whenever the time is right for a new batch of
issues: the RESTRICT declaration/proclamation. Basically, (DECLARE
(RESTRICT type1 type2)) says that, within the extent covered by this
declaration, anything that is of type1 is guaranteed to be of type2 as
well, where type2 is generally more restrictive. One could say
(RESTRICT NUMBER (INTEGER -1024 1024)), which tells the compiler that
any time it can prove something is a number, it can assume it is a
fixnum. In some contexts, this can replace about six dozen THE
forms. Users find it very awkward to say things like
(the (integer -1024 1024) (+ (the (integer -1024 1024) x)
(the (integer -1024 1024) y))
..yet often that is the only portable way to assure the compiler that it
can generate fixnum-only code on most machines.
The reson I bring up RESTRICT at this time is that I think the function
restriction mentioned in point 3 is related to this. Maybe it should be
called RESTRICT-CALL or something.
-- Scott
∂09-Dec-87 0848 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 9 Dec 87 08:48:03 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA05595; Wed, 9 Dec 87 11:51:24 EST
Message-Id: <8712091651.AA05595@multimax.ARPA>
To: Daniels.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-Reply-To: Your message of 08 Dec 87 14:10:00 -0800.
<871208-141224-5386@Xerox>
Date: Wed, 09 Dec 87 11:51:12 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Masinter writes:
I think that it is true that
(reduce <fn> sequence :key <key-fn>) = (reduce <fn> (mapcar
<key-fn> sequence))
except of course in the matter of order of evaluation.
Well, that and the fact that MAPCAR doesn't work on arrays...
Make that:
(reduce <fn> sequence :key <key-fn>) =
(reduce <fn> (map 'list <key-fn> sequence))
Feel free to replace the "'list" with your favorite sequence type.
I'll change REDUCE-ARGUMENT-EXTRACTION to use this construct as the
present case. You're absolutely right that my previous code was badly
broken and attempts to fix it up produce a real mess. This almost
makes it interesting because the result is as cons-efficient as the
proposed new feature, while the mapping approach builds a whole new,
unecessary structure.
∂09-Dec-87 0955 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 9 Dec 87 09:55:08 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA06214; Wed, 9 Dec 87 12:58:47 EST
Message-Id: <8712091758.AA06214@multimax.ARPA>
To: Masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-Reply-To: Your message of 08 Dec 87 15:22:00 -0800.
<871208-160538-5539@Xerox>
Date: Wed, 09 Dec 87 12:58:41 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
From: Masinter.pa@Xerox.COM
"The following are suggested features for a ANSI Common Lisp programming
environment. Conforming implementations are required to document what, if
anything, these functions do, in detail. However, no portable ANSI Common Lisp
program can rely on the behavior of these functions, because the behavior is
specifically not specified in the standard."
This approach makes a lot of sense, but I think we need to give
somewhat more guidance than just a list of names. We need something
along the lines of:
"The following are suggested features for a ANSI Common Lisp
programming environment. No conforming implementation is required to
support any of these features. However all implementations must
document which of these features they support and must adhere to the
following guidelines for the features they do support. No portable
ANSI Common Lisp program can rely on the behavior of these functions,
because the behavior is sepcifically not specified in the standard."
This would be followed by a set of guidelines that:
1. Guarantee that, for example, ED invokes some sort of
editor.
2. Provide some of the CLtL standard interfaces so that
people porting their programs to a new implementation
will have a fighting chance at simple use of features
TRACE and DRIBBLE without reading the manual.
The second point is important. I was recently a developer at a
software house doing more than 10 simultaneous ports. Each port was
handled by one or more junior porters and developers only got called
in when problems happened. In this sort of environment, the last
thing you want to do is spend an hour or few reading manuals before
looking at the problem.
This approach is sort of like the one take by the FORTH folks for the
Forth-83 standard. They divided Forth up into: the required words,
the optional words with mandatory definitions, and suggested (or were
they experimental) extentions.
∂10-Dec-87 2311 CL-Cleanup-mailer Cleanup issues from Japanese technical working group
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Dec 87 23:10:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 DEC 87 23:10:38 PST
Date: 10 Dec 87 23:10 PST
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@Sail.Stanford.EDU
Subject: Cleanup issues from Japanese technical working group
Message-ID: <871210-231038-2589@Xerox>
I asked for the list of open Common Lisp issues from the JEIDA technical working
group. This is their list.
I've added some comments in <<brackets>>. Some of these will require separate
issues, while many are already being addressed.
----- Begin Forwarded Messages -----
Return-Path: <@RELAY.CS.NET:yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
Message-Id: <8712101502.AA05475@tutics.tut.junet>
Date: Thu, 10 Dec 87 15:02:57 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet@utokyo-relay.CSNET>
To: Masinter.pa
Subject: Re: US work on List standards
Question and Answers about Common Lisp. (Revised)
Q: Michiaki Yasumura (Hitachi)
A: TG/A members
[nn.nn.nn] indicates section numbers in CLtL
*******************************************************************
The following subjects should be clarified.
*******************************************************************
1) CLtL says nothing about whether structure or array is self evaluating
form. [5.1.1]
It is suggested that not only numbers, characters, and bit-vectors,
but also structures, arrays, vectors, packages be self-evaluating forms.
Yuasa: There may possibly be some reason that these objects are not
allowed to be evaluated. But the reason is not known.
This simplification is convenient both for the user and for the implementor.
Note that some implementations such as Exper Common Lisp signal an error
when those objects that CLtL does not explicitly say are self-evaluating
are being evaluated.
<<The Rationale for this could easily be provided in the standard.
Does this need an Issue? >>
2) Arguments of function are evaluated left to right. [12.1]
<<This is clearly stated and should be even more ambiguous given a
formal semantics. I think no issue. >>
3) It should be an error if two variables specified in a single lambda
list are named by a same symbol. [15.2]
<<This was discussed in the CL mail, but I suppose it needs
New issue LAMBDA-LIST-DUPLICATES? >>
4) For mapping functions (MAPCAR, SOME, EVERY, etc.) and DOLIST,
it is an error to perform destructive operations on the mapping argument.
The result will be implementation dependent. [7.8.4]
<<New issue MAPPING-DESTRUCTIVE-INTERACTION?>>
5) Property lists are global. There is no local property list even if
the symbol is locally bound. (Common Sense?) [10.1]
<<This is just confusion; symbols are not variables, they just name them.
I think no issue.>>
*************************************************************************
The following subjects are loosely stated in CLtL, and should be clarified.
*************************************************************************
1) If read-base is 16, `1E0' is read as an integer and not a float. [2.1.3]
<< I think this is a wording change rather than an Issue.>>
2) (LAMBDA (X) X) is both of the LIST type and of the FUNCTION type. [2.13]
Umemura: Cons cells must be regarded as function type objects, since
it is strange to check the syntactic validity when the type
of an object is computed.
<< Issue FUNCTION-TYPE would address this >>
3) DEFTYPE affect only the type checking mechanism and no more and less.
[4.7]
<< I'm not sure what this means. DEFTYPE also affects TYPEP, TYPECASE. >>
4) Symbols whose names begin with & are not allowed in a lambda list. [5.2.2]
<< I don't think this is true. It is a bad idea, but it isn't required.
Issue? >>
5) Same keyword parameter can appear more than once in an actual argument
list. [5.2.2]
This is necessary to overwrite passed keyword arguments.
<< New issue KEYWORD-ARGUMENT-DUPLICATES? >>
6) #C(5/3,7.0) is converted to #C(1.66666,7.0) because
real part and imaginary part must be of the same for efficient
calculation on complex numbers. [2.1.4]
<< This is clear, I thought, from CLtL >>
7) For destructive sequence functions such as DELETE, it is an error
to use the side effect of original data structure.
Implementation dependent result will be returned.
It is possible to defined DELETE as
(defun delete (&rest↓αβ∧¬επλ
!
∞∂⊂⊃∩∪∀∃⊗↔←→≠$≤ by REMF-DESTRUCTION-UNSPECIFIED >>
8) It is an error to apply non-list arguments for the list handling
functions. [15.5]
<< I think is specified. No issue? >>
9) Structures defined with the option :TYPE LIST are simple lists
and there is no way to distinguish these data from lists. [19.5]
<< I this is specified. No issue? >>
**********************************************************
The following subject have problems in CLtL specification.
**********************************************************
1) ------
Q: What happens if a function is defined in a body of a function.
For example:
(defun bar ()
(bar)
(defun bar () (something))
(bar) ) ; <-- Should BAR be affected in the execution of FOO?
A: CLtL says the DEFUN is a simple macro which changes the symbols definition.
So, BAR should be affected.
Problems: If so, the tail merging optimization is very difficult.
We cannot know how to define the effect of DEFUN in order to allow this
optimization.
Yuasa: How about defining only the compiler semantics?
For almost all Common Lisp programs run in compiled code.
<< Unless BAR is proclaimed INLINE, you have to do tail optimization
by indirect thru the function cell. This was discussed at length.
Does this need an issue? FUNCTION-TAIL-RECURSION?>>
2) -----
Q: Is it possible to redefine predefined (built-in) functions and macros
such as DEFUN, AND, OR.
A: CLtL says nothing about this thing, but almost all implementations
allow such redefinition.
Problems: We cannot image what happens.
Suggestion: Redefining a predefined symbol signals an error.
However, Redefining user function does not signals an error.
<< This is issue LISP-SYMBOL-REDEFINITION >>
3) ---
Q: Is there any way to cancel the PROCLAIM.
A: No. There should be such a function.
<< Well, PROCLAIM-LEXICAL had such, but is in trouble. >>
4) ---
Q: Is there any way to escape from Lisp context.
A: Some systems, such as Lisp machine have no concept of escaping.
This is needed for Lisp systems under stock operating systems.
It is necessary to determine the name even if the function
may be implementation dependent.
Recommendation: (QUIT) will be a proper word for this operation.
<< Seems like it goes in the environment section. >>
5) --
Q: Is it possible to UNINTERN the DEFCONSTANTed symbols.
A: CLtL says yes, but it is hard to compile such a program.
Umemura: We should define the semantics of compile-file.
Changing readbase, readmacro, packaged in a file
also introduce similar problems.
<< This seems to be mainly about UNINTERN during file compilation.
seems like this is part of the compiler specification. >>
***************************************************************
These function can be defined in CLtL itself, but should be
added to CLtL for the efficiency or user convenience.
***************************************************************
1) ---
Q: Is there any way to test whether a symbol is special or not?
A: We can define such a function in a tricky way,
But there should be this function, for compiler needs this function
and it seems that almost all implementations support such a function
internally.
<< This has been asked for before. Issue SPECIAL-VARIABLE-TEST ? >>
∂15-Dec-87 1050 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 15 Dec 87 10:50:00 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA18399; Tue, 15 Dec 87 11:45:11 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA02778; Tue, 15 Dec 87 11:45:06 MST
Date: Tue, 15 Dec 87 11:45:06 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712151845.AA02778@orion.utah.edu>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu, sandra%orion@cs.utah.edu
In-Reply-To: Masinter.pa@Xerox.COM, 9 Dec 87 02:59 PST
I'm confused as to what the current status is here. Should I revise my
earlier proposals that deal primarily with syntax, or work on a new one
that tries to address the question of function declaration semantics as
well?
-Sandra
-------
∂15-Dec-87 1128 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Dec 87 11:28:26 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 DEC 87 11:26:03 PST
Date: 15 Dec 87 11:26 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 15
Dec 87 11:45:06 MST
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <871215-112603-1532@Xerox>
I apologize for sidetracking your original proposal with the related one of
whether function argument declarations have semantics at all. It did seem to me
that deciding whether one writes
(function + (&rest number) number)
or
(function + (&rest (list number)) number)
might wait for some resolution of whether there is any conceivable utility,
other than documentation, for making either declaration, lest the issue bee
moot.
However, we probably should go forward with the discussion of the form of the
declaration independent of its semantics, and separate out, say,
FUNCTION-ARGUMENT-TYPE-SEMANTICS, from FUNCTION-TYPE-REST-LIST-ELEMENT.
If there's no objection to doing so, I'll open up another issue name, and
attempt to write up a FUNCTION-ARGUMENT-TYPE-SEMANTICS.
∂16-Dec-87 1538 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (alternate proposal)
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 87 15:38:43 PST
Received: by labrea.stanford.edu; Wed, 16 Dec 87 15:27:56 PST
Received: from gypsy-moth.lucid.com by edsel id AA09557g; Wed, 16 Dec 87 14:25:00 PST
Received: by gypsy-moth id AA01336g; Wed, 16 Dec 87 14:25:56 PST
Date: Wed, 16 Dec 87 14:25:56 PST
From: Ken Olum <edsel!kdo@labrea.stanford.edu>
Message-Id: <8712162225.AA01336@gypsy-moth.lucid.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 23 Oct 87 15:22 PDT <871023-152308-1515@Xerox>
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (alternate proposal)
I don't think this issue has anything to do with symbols. For example,
consider the form
(setf (ldb (byte 8 0) x) (prog1 1 (setf (ldb (byte 8 8) x) 2)))
Suppose that X is 0. This form now sets X to 1. However, if X is
replaced with (CAR X), then the form will set (CAR X) to #x201. In
order to have constant behavior, GETF and LDB must ALWAYS completely
evaluate their subform, whether it is a symbol or not. If we do this
with all setf-methods then we might as well flush the idea of an
access-form since this must always be no more than a local variable
reference. Furthermore the access-form must always be defined even
if the case is just SETF, because you will always access it as EB
points out in a previous message.
Furthermore, I think this behavior is unnatural. Many applications
set up flag-words and the like, and a side-effect of computing a value
for one flag might well be the setting of another flag in the same
word. In this case the same sub-place is being used to store various
objects, and there should be as little interaction between the setting
of the different objects as possible.
Therefore, I propose that we change the definition of a subform for
this order-of-evaluation issue and keep the methods on both pages 105
and 106. See SETF-METHOD-FOR-SYMBOLS:CHANGE-MEANING-OF-SUBFORM below.
!
ISSUE: SETF-METHOD-FOR-SYMBOLS
References: CLtL pp. 105, 106, 99. Issue: PUSH-EVALUATION-ORDER.
Category: CHANGE
Edit history: Version 1 Moon 21 Sep 87
Version 2 Masinter 23-Oct-87
Version 3 Masinter 11-Nov-87
Version 4 KDO 4-Dec-87
Problem description:
The description of SETF in CLtL and various SETF methods are
inconsistent. The description on page 99 clearly requires side-effects
to be elaborated in left-to-right order; however, the combination of the
sample setf-method for LDB on p.106 and the sample setf-method for
symbols given on p. 105 results in incorrect order of evaluation.
Test Case A: Given
(LET* ((R (LIST 'A 1 'B 2 'C 3))
(S R))
(SETF (GETF R 'B) (PROGN (SETQ R NIL) 6))
(VALUES R S))
If side-effects are elaborated in left-to-right order, the setq of R to
NIL should not affect the result, since it occurs after R is read and
before R is written, and therefore the value of both R and S should be
(A 1 B 6 C 3).
A typical result in an implementation that believes CLtL p.105 more than
CLtL p.99 is R = (B 6) and S = (A 1 B 2 C 3).
Test Case B: Given:
(LET((A 0))
(INCF (LDB (BYTE 2 2) A) (SETQ A 2))
A)
Does this return 8, 10, or 2? If p. 99's description of order of
evaluation is correct, this should return 8.
It was pointed out that it is possible to get the required result for
the test case by modifying the get-setf-method for GETF (and other
setf-able items) to set up the bindings when the modified form is a
symbol, as is done in Spice Lisp.
However, we believe that user programs are much more likely to have
copied the setf method for LDB given on p.106 than the setf method for
symbols schematized on p.105, and this is the simplest change to achieve
compatibility and correct behavior.
Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE
Change the example of the result of
(GET-SETF-METHOD 'FOO) from
NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO
(as currently described in CLtL) to return, for example,
(#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175
Rationale:
The general principle mentioned on p.99 should override the specific
example on p.105. The latter is probably just a mistake.
Current practice:
Symbolics and Lucid return the incorrect result mentioned in the test
case A. (Symbolics plans to fix this in the next release.) Franz and
Xerox returns something else: R = nil and S = (a 1 b 6 c 3); Xerox
returns A=10 in Test Case B. HP Common Lisp produces the recommended
value.
Spice Lisp returns the recommended value for the test case A, even
though it uses the suggested value for the setf-method for symbols,
because the get-setf-method for GETF introduces additional temporary
bindings.
Adoption Cost:
SETF is an intricate part of Common Lisp, and the fact that not all
implementations currently return the same thing indicates that some care
might be required in updating implementations. However, in some
implementations changing what get-setf-method returns when its argument
is a symbol is the only change required.
It's been pointed out that this change might cause less efficient code
to be produced in some cases, since setf methods will involve more
temporary variables, however Moon believes that the optimizations are
not difficult and probably are already done by most implementations.
Cost of non-adoption:
Users will think SETF is complicated and hard to understand, because
implementations won't conform to a simple general principle that
side-effects are elaborated in left-to-right order.
Benefits:
Improved portability of Common Lisp programs.
Conversion Cost:
This change is incompatible because it changes the result of some forms
that are not erroneous. However, it's unlikely that very many users are
intentionally depending on the current behavior. In addition, the
current behavior is not consistent across implementations, which makes
changing it less problematic.
Esthetics:
See "cost of non-adoption".
Discussion:
A specification of Common Lisp would do well to included some better
examples of precisely what is meant by the "`obvious' semantics"
mentioned on page 99.
This proposal is consistent with PUSH-EVALUATION-ORDER:ITEM in affirming
the left-right order of evaluation of subforms of generalized variable
access forms.
It was pointed out that it is possible to get the required result for
the test case by modifying the get-setf-method for GETF (and other
setf-able items) to set up the bindings when the modified form is a
symbol, as is done in Spice Lisp.
However, we believe that user programs are much more likely to have
copied the setf method for LDB given on p.106 than the setf method for
symbols schematized on p.105, and this is the simplest change to achieve
compatibility and correct behavior.
Proposal: SETF-METHOD-FOR-SYMBOLS:CHANGE-MEANING-OF-SUBFORM
Keep the old definition for symbols as examplified on p. 105 and the
definition for LDB on p. 106. Specify that "subforms of
generalized-variable references" on p. 99 does not includes subforms
which will be stored into, but only those necessary to specify the
place to store. In other words if the setf-method for a form must
recusively make use of the setf-method for a subform, that that
subform (but not any sub-subforms) is permitted to be evaluted at the
time of the store instead of in its lexical position.
Benefits:
Anyone who has copied examples from p.105 and p.106 will continue to
be able to use them.
Setf of (LDB ... X) will be consistant with (LDB ... (CAR X)) and all
other subplaces.
It is very unlikely that anyone is depending on the left-to-right
evaluation in this case, but quite possible that someone is depending
on the non-left-to-right evaluation for maintaining several bit-fields
in a symbol value.
∂17-Dec-87 1736 CL-Cleanup-mailer Cleanup issues from Japanese technical working group
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:35:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306483; Thu 17-Dec-87 20:35:35 EST
Date: Thu, 17 Dec 87 20:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Cleanup issues from Japanese technical working group
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <871210-231038-2589@Xerox>
Message-ID: <19871218013528.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I have comments on excerpts from this. For most of the issues
raised, I have no comment. Feel free to forward these comments
back to our Japanese friends if desired.
1) CLtL says nothing about whether structure or array is self evaluating
form. [5.1.1]
It is suggested that not only numbers, characters, and bit-vectors,
but also structures, arrays, vectors, packages be self-evaluating forms.
Yuasa: There may possibly be some reason that these objects are not
allowed to be evaluated. But the reason is not known.
This simplification is convenient both for the user and for the implementor.
Note that some implementations such as Exper Common Lisp signal an error
when those objects that CLtL does not explicitly say are self-evaluating
are being evaluated.
<<The Rationale for this could easily be provided in the standard.
Does this need an Issue? >>
It's not true that CLtL says nothing about this; the bottom of page 54
in the English edition says evaluating any other object is an error.
I don't know what the rationale was; unless somebody knows, we can't easily
provide it in the standard!
At Symbolics we pondered this for a while and settled on the idea that
only objects of type (OR CONS SYMBOL) do anything special when evaluated,
and all other objects evaluate to themselves. We haven't had any problems
as a result of this.
CLtL says something about implementation-dependent extensions for
evaluating other types of objects, but we decided that this didn't make
sense for any of the object types defined by CLtL. An implementation
could certainly invent a new, non-COMMON object type with a new way of
evaluating it, and then that (OR CONS SYMBOL) would be extended to (OR
CONS SYMBOL other-type) in that implementation. But since a portable
program presumably wouldn't use any objects of that
implementation-dependent type, this should't interfere with portability
even if we define that all objects of types defined by CLtL, other than
CONS and SYMBOL, are self-quoting.
Evidently current practice varies between implementations. This needs an
issue if we want to change it, but since "is an error" allows complete
implementation-dependent freedom, we don't have to say anything if we
think the status quo is okay.
1) If read-base is 16, `1E0' is read as an integer and not a float. [2.1.3]
<< I think this is a wording change rather than an Issue.>>
I don't think this is a problem at all, since 22.1.2 (page 343) is very
explicit about this.
5) Same keyword parameter can appear more than once in an actual argument
list. [5.2.2]
This is necessary to overwrite passed keyword arguments.
<< New issue KEYWORD-ARGUMENT-DUPLICATES? >>
Not an issue, 5.2.2 (page 62 in the English edition) is already very
explicit about this "If more than one such argument pair matches,
it is not an error; the leftmost argument pair is used."
4) ---
Q: Is there any way to escape from Lisp context.
A: Some systems, such as Lisp machine have no concept of escaping.
This is needed for Lisp systems under stock operating systems.
It is necessary to determine the name even if the function
may be implementation dependent.
Recommendation: (QUIT) will be a proper word for this operation.
<< Seems like it goes in the environment section. >>
I remember this was discussed at length a couple years ago, and the
conclusion was that the semantics of quitting varied so much between
implementations that there was no point in trying to standardize
anything. Even without thinking about multiprocess systems, nor about
Lisp machines, you have to ask whether after quitting the Lisp vanishes
or can be restarted, whether a command string can be returned to the
operating system, whether a success/failure code is required to be
returned to the operating system, etc. Finally it is unclear how a
portable program could usefully benefit from this.
∂17-Dec-87 1740 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:40:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306486; Thu 17-Dec-87 20:39:48 EST
Date: Thu, 17 Dec 87 20:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
To: Dan L. Pierson <pierson@MULTIMAX.ARPA>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8712072340.AA01767@multimax.ARPA>
Message-ID: <19871218013945.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL as well as
KMP's suggested improvement to the test case, which I was
going to suggest myself. The COMPILED-FUNCTION type
specifier is not well-defined and if I remember correctly
the FUNCTION-TYPE cleanup issue proposes to remove it.
∂17-Dec-87 1745 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:45:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306494; Thu 17-Dec-87 20:45:27 EST
Date: Thu, 17 Dec 87 20:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871208-160538-5539@Xerox>
Message-ID: <19871218014525.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 8 Dec 87 15:22 PST
From: Masinter.pa@Xerox.COM
I think we should take a step back and ask what the place of DISASSEMBLE, ED,
TRACE, BREAK, DRIBBLE, INSPECT etc.. should be in the ANSI standard. These are
things for which constructing a denotational semantics is not feasible, cann't
be easily tested with a validation suites, etc.
I think a more global change of status for these is called for; I'd propose that
the ANSI Standard should say something like:
"The following are suggested features for a ANSI Common Lisp programming
environment. Conforming implementations are required to document what, if
anything, these functions do, in detail. However, no portable ANSI Common Lisp
program can rely on the behavior of these functions, because the behavior is
specifically not specified in the standard."
This seems like a reasonable idea, although it's perhaps not in the domain of
the Cleanup committee.
Once we move away from conformance and standard into recommendation, we might
actually be more able to make better progress recommending, for example, that
systems call their GC function (GC) and their exit function (EXIT) etc.
I think this would be a mistake. The functions listed earlier are to be called
by users and generally are not useful to call from programs. The only reason those
functions were ever in CLtL as functions is that Common Lisp didn't want to assume
that some kind of command processor, separate from Lisp evaluation, exists since
opinions on how this should work diverge so wildly.
GC and EXIT are in a different category. GC is likely to be called by programs,
except that as we found when we discussed it a while back, it doesn't seem to be
possible to say anything at all implementation-independent about the semantics
of this, which makes it not very useful for portable programs. EXIT surely must
be for programs, rather than users, since every operating system already has a
way for users to get out; but again there is no portable semantics.
While it's useful to have some "suggested features" for users, to ease learning
how to use a new Common Lisp implementation as well as to give implementors an
idea of the minimum environment expected, it's not useful to have "suggested
features" for programs, since if they are only suggested, no portable program
can use them.
∂17-Dec-87 1757 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:57:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306500; Thu 17-Dec-87 20:57:01 EST
Date: Thu, 17 Dec 87 20:56 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
To: Dan L. Pierson <pierson@MULTIMAX.ARPA>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8712072337.AA01737@multimax.ARPA>
Message-ID: <19871218015659.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor REDUCE-ARGUMENT-EXTRACTION:KEY.
I'd like to see a version 2 of this proposal, amended according to
the comments received. The changes would all be to the form of the
proposal, not its substance, but would make it more approvable.
Proposals containing test cases that have not been tested are
a real no-no!
∂17-Dec-87 1805 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION issues
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 18:05:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306504; Thu 17-Dec-87 21:05:03 EST
Date: Thu, 17 Dec 87 21:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-DECLARATION issues
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12357112955.BABYL@C.CS.CMU.EDU>
Message-ID: <19871218020501.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 9 Dec 1987 10:28 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
2. Add an extended form for the LIST type specifier so that one can
indicate element type and, perhaps, length. This can be used to say
something useful about rest-args, without having to put in ugly special
syntax for this.
I very strongly prefer having the thing after the &rest in a function
type-specifier refer to each remaining argument, as Steele suggested two
years ago, rather than having it refer to the value of the &rest parameter,
as you seem to be assuming. This is partly because I very strongly prefer
having the function type-specifier be a description of arguments rather
than a description of parameters.
Thus I prefer
(function + (&rest number) number)
over
(function + (&rest (list number)) number)
I really have no opinion on the other features being discussed in this
conversation, including the very existence of the list form of the
function type-specifier. All this stuff seems both overcomplicated and
useless to me, but that's not an informed opinion.
∂17-Dec-87 1812 CL-Cleanup-mailer Cleanup issues from Japanese technical working group
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 18:12:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Thu 17 Dec 87 21:12:34-EST
Date: Thu, 17 Dec 1987 21:12 EST
Message-ID: <FAHLMAN.12359327290.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Cleanup issues from Japanese technical working group
In-reply-to: Msg of 17 Dec 1987 20:35-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
It's not true that CLtL says nothing about this; the bottom of page 54
in the English edition says evaluating any other object is an error.
I don't know what the rationale was; unless somebody knows, we can't easily
provide it in the standard!
At Symbolics we pondered this for a while and settled on the idea that
only objects of type (OR CONS SYMBOL) do anything special when evaluated,
and all other objects evaluate to themselves. We haven't had any problems
as a result of this.
I remember some of the discussions on this issue (though I no longer
remember which side I was on -- scary!). A number of people wanted to make all
objects other than Conses and Symbols be self-evaluating; a number of
other people didn't want to close off the space of possible extensions
in this way. The latter group won.
In retrospect, it seems clear that this was a mistake -- nobody has used
the added freedom as far as I know, and the need to quote such things as
vectors has definitely led to confusion among new users and an
occasional spurious bug report. I'd support a move to change this, so
that we could all assume self-evaluating objects when we're writing
portable code. Since "it is an error" to eval objects of miscellaneous
types, implementations are legally free to adopt the self-eval
convention, but I would argue that it is a bit treacherous for their
users if they do, since the local users will be in for a nasty surprise
whenever they move to a system that doesn't use this convetion.
On the Quit issue, I think that Masinter has suggested the right way to
handle this: ed, dribble, and friends should be suggested names for
certain environment-related operations, but nothing more. The standard
would explicitly say that these environment functions may or may not
exist in any given implementation, and that what they do will vary from
one environment to another. CLtL currently says a bit too much about
some of these things, which causes people to want to say even more.
-- Scott
∂17-Dec-87 1823 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 18:22:55 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Thu 17 Dec 87 21:22:49-EST
Date: Thu, 17 Dec 1987 21:22 EST
Message-ID: <FAHLMAN.12359329156.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-DECLARATION issues
In-reply-to: Msg of 17 Dec 1987 21:05-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I very strongly prefer having the thing after the &rest in a function
type-specifier refer to each remaining argument, as Steele suggested two
years ago, rather than having it refer to the value of the &rest parameter,
as you seem to be assuming. This is partly because I very strongly prefer
having the function type-specifier be a description of arguments rather
than a description of parameters.
Thus I prefer
(function + (&rest number) number)
over
(function + (&rest (list number)) number)
Hmmm...I never thought about it this way. If we look at the syntax you
prefer as a special case for talking about the elements in the rest
list, then this is a hideous kludge. On the other hand, if we look at
this as a way of talking about the type of each of the rest arguments,
then it has a certain elegance. I wouldn't object, as long as it's
explained this way.
We may still want to adopt a better type specifier for LIST, but that is
a separable issue.
-- Scott
∂18-Dec-87 1439 CL-Cleanup-mailer whether random objects self-evaluate (was cleaup issues from Japan)
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Dec 87 14:39:50 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa20706; 18 Dec 87 17:33 EST
Received: from tektronix.tek.com by RELAY.CS.NET id bz29779; 18 Dec 87 17:26 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA17683; Fri, 18 Dec 87 11:41:33 PST
Received: by tekchips.TEK.COM (5.51/6.24)
id AA22225; Fri, 18 Dec 87 11:40:04 PST
Message-Id: <8712181940.AA22225@tekchips.TEK.COM>
To: Fahlman@C.CS.CMU.EDU
Cc: Moon@SCRC-STONY-BROOK.ARPA, CL-CLEANUP@SAIL.STANFORD.EDU,
willc%tekchips.tek.com@RELAY.CS.NET
Subject: whether random objects self-evaluate (was cleaup issues from Japan)
In-Reply-To: Your message of Thu, 17 Dec 1987 21:12 EST.
<FAHLMAN.12359327290.BABYL@C.CS.CMU.EDU>
Date: 18 Dec 87 11:40:02 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
Let me report on the Scheme situation and my experience. As in Common Lisp,
it is "an error" to evaluate a random object, but most implementations
extend the language by allowing at least some random objects (notably
the empty list, since only a few implementations yet distinguish the empty
list from #f) to evaluate to themselves. MacScheme allows all random objects
to evaluate to themselves, but unlike Symbolics I have found this to be
a (minor) problem, and I recommend that implementors avoid my mistake.
The problem: In writing a macro using backquote I sometimes leave out a
quote mark, insert an extra comma, or put a comma in the wrong place.
Then an expanded macro can look like
(... #<PROCEDURE> ...)
when I wanted it to look like
(... '#<PROCEDURE foo> ...)
or
(... (lambda (...) ...) ...).
I would like to get an error message from the incremental compiler, because
I never deliberately write code with unquoted procedures, but with
self-evaluating procedures no error will occur until the expression is
executed, and then the values seen in the debugger can seem very strange.
In my code, this kind of macro bug almost always shows up as a procedure
that was closed in the wrong environment, but if I'm unlucky the incorrect
procedure will pass control to an altogether unfamiliar part of the system
before trapping on some unrelated error such as taking the car of the empty
list.
As better macro facilities become more universal, this is of course
becoming less of a problem.
Peace, Will
∂18-Dec-87 1759 CL-Cleanup-mailer whether random objects self-evaluate (was cleaup issues from Japan)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 17:58:59 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Fri 18 Dec 87 20:58:45-EST
Date: Fri, 18 Dec 1987 20:58 EST
Message-ID: <FAHLMAN.12359586922.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: willc%tekchips.tek.com@RELAY.CS.NET
Cc: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: whether random objects self-evaluate (was cleaup issues from Japan)
Will,
It would be easy enough to say that most objects are self-evaluating,
but that function objects (strict definition) signal an error if you
evaluate them. Then again, it would be nice to avoid making odd
exceptions of this kind -- I've heard tell that some people think Common
Lisp already is something of a kludge. I wonder if the problem you cite
is as likely to occur in Common Lisp as it is in Scheme. I've never
seen this in my own coding, but that might be because I am terribly
conservative in my use of backquotery. What do others think?
-- Scott
∂21-Dec-87 1924 CL-Cleanup-mailer SETF-METHOD-FOR-SYMBOLS Issue
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 21 Dec 87 19:22:17 PST
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA16788; Mon, 21 Dec 87 15:10:11 PST
Date: Mon, 21 Dec 87 15:10:11 PST
Message-Id: <8712212310.AA16788@decwrl.dec.com>
From: greek%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: SETF-METHOD-FOR-SYMBOLS Issue
I spent some time reading the issue entitled SETF-METHOD-FOR-SYMBOLS.
Seems to me it avoids the real question.
Consider Test Case A. Once the (GETF ...) and (PROGN ...) are
evaluated, what happens. We notice that the key B already appears in
the list, so we replace its value with 6. Then do we store the list
back in R? If so, R will be (A 1 B 6 C 3). If not, it will be NIL.
Now if the key does not appear in the list, we must cons it on the front
and then are forced to store it back in B. So perhaps for consistency
we should always store it back.
So I guess my question is: is the place in (SETF (GETF R ...) ...)
R or is it the list in R or is the pair in the list in R?
- Paul Anagnostopoulos
∂30-Dec-87 1625 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 30 Dec 87 16:25:13 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA18793; Wed, 30 Dec 87 19:29:57 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA19273; Wed, 30 Dec 87 19:26:34 EST
Message-Id: <8712310026.AA19273@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
Date: Wed, 30 Dec 87 19:26:32 EST
From: Dan L. Pierson <pierson@mist>
Issue: DISASSEMBLE-SIDE-EFFECT
References: DISASSEMBLE (p. 439), COMPILE (p. 439)
Category: CLARIFICATION
Edit history: Version 2 by Pierson 12/30/87
Status: For Internal Discussion
Problem description:
The definition of DISASSEMBLE says that "if the relevant function is
not a compiled function, it is first compiled.". The definition of
COMPILE says that "If name is a non-nil symbol, then the
compiled-function is installed as the global function definition of
the symbol...". Several implementations have taken this to mean that
if DISASSEMBLE is passed a symbol which has an uncompiled function
definition, then it has the side-effect of (COMPILE 'symbol).
Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL):
Clarify that when DISASSEMBLE compiles a function, it will never
install the newly compiled function.
Test Cases/Examples:
(DEFUN F (A) (1+ A))
(EQ (SYMBOL-FUNCTION 'F)
(PROGN (DISASSEMBLE 'F)
(SYMBOL-FUNCTION 'F)))
This code will return T if this proposal is adopted. Some current
implementations will return T, some will return NIL.
Rationale:
Several current implementations of DISASSEMBLE have surprising side
effects, especially for new users.
Current practice:
Allegro CL and Vax Lisp install the compiled definition. Lucid,
Symbolics, Xerox, and KCL don't install it. [[This is from an informal
survey at the last meeting; please correct any mistakes.]]
Cost to Implementors:
Some implementations will have to make a simple change.
Cost to Users:
Very little. DISASSEMBLE is really part of the environment and is
probably not called by much, if any user code.
Cost of non-Adoption:
DISASSEMBLE will continue to surprise less experienced users.
Benefits:
DISASSEMBLE will become the predictable debugging function it was
meant to be.
Aesthetics:
Some who worried that DISASSEMBLE was supposed to install the compiled
function may find that the language has become a little cleaner.
Discussion:
∂30-Dec-87 1634 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 30 Dec 87 16:34:14 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA18840; Wed, 30 Dec 87 19:39:01 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA19317; Wed, 30 Dec 87 19:35:38 EST
Message-Id: <8712310035.AA19317@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
Date: Wed, 30 Dec 87 19:35:36 EST
From: Dan L. Pierson <pierson@mist>
Issue: REDUCE-ARGUMENT-EXTRACTION
References: REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313),
Category: ADDITION
Edit history: Version 2 by Pierson 12/30/87
Issue: For Internal Discussion
Problem description:
REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword described as
follows:
If a :KEY argument is supplied, its value must be a function of one
argument which will be used to extract the values to reduce. The :KEY
function will be applied exactly once to each element of the sequence
in the order implied by the reduction order but not to the value of
the :INITIAL-VALUE argument, if any.
Test Cases/Examples:
Using REDUCE to obtain the total of the ages of the possibly empty
sequence of astronauts ASTROS, would currently require:
(REDUCE #'+ (MAP 'LIST #'PERSON-AGE ASTROS))
If this proposal is adopted, the same result could be obtained without
creating a new list by:
(REDUCE #'+ ASTROS :KEY #'PERSON-AGE)
Rationale:
This proposal makes many common situations where REDUCE would be useful
much less cumbersome.
Current practice:
Does anyone currently support this as an extension?
Cost to Implementors:
This will require most implementations to make a trivial modification
to REDUCE. Implementations which wish to use this as an opportunity to
further optimize compiled calls to REDUCE will have to undertake more
work (which would be much more difficult today).
Cost to Users:
None, this is an upward compatible extension.
Cost of non-Adoption:
REDUCE will continue to be more difficult to use than other sequence
functions on sequences of complex objects.
Benefits:
REDUCE will become easier to use on sequences of complex objects. It
will be easier for compilers to convert some calls to REDUCE into
efficient loops.
Aesthetics:
Slightly damaged in one way. All :KEY arguments are currently defined
to be used for predicates, this proposal will implicitly broaden :KEY
to support general extraction for any purpose.
Slightly improved in another way. Many common situations where REDUCE
could be used would be easier to write and easier to later read.
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
There is some controversy over whether the "definition" of :KEY
arguments on page 246 of CLtL really constitutes a definition or just
an "unwritten rule".
∂31-Dec-87 1126 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 31 Dec 87 11:26:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 313154; Thu 31-Dec-87 14:26:24 EST
Date: Thu, 31 Dec 87 14:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
To: Dan L. Pierson <pierson@multimax.com>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8712310035.AA19317@mist.UUCP>
Message-ID: <19871231192614.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks fine to me.
Current practice: Symbolics does not have :KEY in REDUCE currently.
∂31-Dec-87 1723 CL-Cleanup-mailer Releasing potentially confusing info to the CL community
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 31 Dec 87 17:23:01 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 313392; Thu 31-Dec-87 20:22:54 EST
Date: Thu, 31 Dec 87 20:22 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Releasing potentially confusing info to the CL community
To: masinter.PARC@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871231-163511-2608@Xerox>
Message-ID: <871231202220.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[Common-Lisp removed; CL-Cleanup added.]
Date: 31 Dec 87 16:34:23 PST (Thursday)
From: masinter.PARC@Xerox.COM
To: COMMON-LISP@SAIL.STANFORD.EDU
There will probably be a letter ballot to X3J13 to confirm the cleanup items
accepted by voice vote at the recent X3J13 meetings. I'd say that these changes
would then has as much `official' status as anything.
...
Which is to say: "none". I would say that this is a misleading statement.
Our committee has no charter to legislate changes to CL as it exists now.
The committee which could do that has not met for two years. It was not even
clear whether it had the power to make changes when it did meet.
I'm firmly of the belief that people should not be encouraged to assume that
present-day CL is other than CLtL. CLtL is a target that can be hit. If people
start randomizing some but not all dialects in a disorganized fashion to try to
take "cleanup" changes into effect, there will be even more chaos than there is
already. Some changes are not compatible. The others are only compatible if you
assume that all implementations are changed in lockstep; if some implementations
change and others do not, then porting code from changed implementations to
non-changed implementations may be expensive. Our current environmental impact
statements do not discuss this I-think-peculiar-and-undesirable situation.
I very very strongly believe that the chunking size of any information to the CL
community should be considerably larger (ie, something like a "draft proposed standard")
than these proposals -- never something trivially separable like this. Otherwise
you get into a non-linear situation where one CL implementation has informally made
changes A, B, and C and others have made changes C, D, and E and you can't compare
them. On the other hand, it is easy to compare CLtL to draft CL-88 or perhaps-not-draft
CL-90 because the changes will be sufficiently bundled that we can afford to give
them a name. I'm loathe to think that CL's will be identified by non-linear names
like CLtL+FLET-fix+...
Either that or it might work to number the decisions and say that if you implement
any cleanups, you must implement all the cleanups which precede it so that a single
revision number may be assigned to your implementation. I'd have to think more about
this if anyone wanted to pursue it.
-kmp
∂31-Dec-87 1749 CL-Cleanup-mailer Re: Releasing potentially confusing info to the CL community
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 31 Dec 87 17:49:30 PST
Received: from Burger.ms by ArpaGateway.ms ; 31 DEC 87 17:48:25 PST
Sender: "Larry_Masinter.PARC"@Xerox.COM
Date: 31 Dec 87 17:47:39 PST (Thursday)
Subject: Re: Releasing potentially confusing info to the CL community
From: masinter.PARC@Xerox.COM
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-to: KMP%STONY-BROOK.SCRC.Symbolics:COM's message of 31 Dec 87 17:23:13
PST (Thursday)
Message-ID: <871231-174825-2644@Xerox>
Sigh. Present-day CL isn't CLtL either... since most present-day CL
implementations have bugs, have places where they differ from CLtL, have lots of
variations. I think that we can dissimenate information that X3J13 has
"endorsed" some changes in a letter ballot, and once the changes have been
endorsed, implementors are encouraged to go ahead and adopt those changes and
document them.
I hear your concern to be that we want to reduce the amount of chaos in the CL
world, and encourage compatibility. If so, I agree whole-heartedly. The issue
then comes down to whether releasing X3J13-adopted resolutions is likely to
increase or decrease people's understanding of where ambiguities in CLtL might
lie and what they can watch out for. I think the mere existance of the issue and
the Discussion in fact are very informative for most users, and will help them
understand areas that they have to watch out for. From that perspective, isn't
releasing the `approved' drafts doing everyone a service? We do talk about
current practice and whether this is a compatible change from 'current'
implementations, etc.
∂01-Jan-88 1245 CL-Cleanup-mailer New issue: FLET-DECLARATIONS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jan 88 12:44:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 313515; Fri 1-Jan-88 15:45:15 EST
Date: Fri, 1 Jan 88 15:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New issue: FLET-DECLARATIONS
To: Cl-Cleanup@SAIL.STANFORD.EDU
cc: Hornig@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19880101204506.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
This comes from Steele's 1985 list. I thought that the Cleanup
committee had picked this one up long ago, but in looking over the
status list it seems like it's never been written up. Perhaps it's too
non-controversial? I think we may have discussed this at a face to face
meeting last year and decided we were afraid of anything that touches
upon declaration scoping. However, I think there is only one possible
declaration scoping rule for these that is consistent with CLtL.
Issue: FLET-DECLARATIONS
References: FLET, LABELS, MACROLET (CLtL p.113)
X3J13 document 86-003 item 113
Category: ADDITION
Edit history: Version 1, Moon, 1 Jan 1988
Problem description:
Declarations are not allowed before the body of FLET, LABELS, and
MACROLET, even though Common Lisp allows declarations in other seemingly
analogous places, such as LET.
Proposal (FLET-DECLARATIONS:ALLOW):
Change the syntax of FLET, LABELS, and MACROLET to allow declarations
between the list of local function/macro definitions and the body forms.
In MACROLET, an invocation of one of the macros locally defined by that
MACROLET is permitted to expand into a DECLARE (assuming Common Lisp is
not changed to forbid any macros to expand into DECLARE).
The scope of such declarations in FLET and LABELS includes the bodies
of the locally defined functions, when the declarations are pervasive.
Non-pervasive declarations have no effect on those bodies, except when
LABELS includes the body in the scope of a function non-pervasively
declared. This paragraph follows directly from CLtL p.155 if the
locally defined function bodies are treated like initialization forms.
(This paragraph will be superseded by a proposal on declaration
scoping that Hornig plans to make soon.)
The scope of such declarations does not include the bodies of the
macro expander functions defined by MACROLET. This is consistent with
the existing rule that the bodies of those functions are in the global
environment, not the local lexical environment. This rule is required
in order to permit macros to expand into DECLARE, as noted above.
Test Cases/Examples:
(defun example (y l)
(flet ((attach (x)
(setq l (append l (list x)))))
(declare (inline attach))
(dolist (x y)
(unless (null (cdr x))
(attach x)))
l))
(example '((a apple apricot) (b banana) (c cherry) (d) (e))
'((1) (2) (3) (4 2) (5) (6 3 2)))
=> ((1) (2) (3) (4 2) (5) (6 3 2) (a apple apricot) (b banana) (c cherry))
The above function is erroneous in current Common Lisp. With this
proposal, it would have an intuitively obvious meaning.
Rationale:
This will make the syntax of FLET and LET consistent. This will make
it possible to attach declarations to function bindings; currently only
variable bindings can have attached declarations.
Current practice:
I do not know of any Common Lisp implementations that allow declarations
there.
Cost to Implementors:
The compilation and interpretation of three special forms will have to
be changed, however the same techniques already developed for
declarations in LET should be applicable.
Cost to Users:
No cost since this is an upward-compatible addition.
Cost of non-adoption:
Unnecessary inconsistency in the syntax of Common Lisp.
Benefits:
There is no major benefit but the language will be more consistent.
Esthetics:
Makes the language more consistent.
Discussion:
We need to resolve this for CLOS, because CLOS introduces two new
special forms similar to FLET and LABELS and we need to make their
syntax consistent.
∂03-Jan-88 1322 CL-Cleanup-mailer cleanup status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Jan 88 13:21:55 PST
Received: from Burger.ms by ArpaGateway.ms ; 03 JAN 88 13:03:43 PST
Sender: "Larry_Masinter.PARC"@Xerox.COM
Date: 2 Jan 88 23:04:12 PST (Saturday)
Subject: cleanup status
From: masinter.PARC@Xerox.COM
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880103-130343-1016@Xerox>
Kent: I composed the following as a follow-up to mail to
common-lisp@sail.stanford.edu. Would this address your concerns?
- - - - - - - - - - -
My recent message prompted enough debate that I thought I would clarify what I
meant in my recent message about FLET. Some assumptions:
X3J13 is attempting to define an ANSI standard for Common Lisp.
X3J13 is starting with "Common Lisp the Language" by Guy L. Steele, Jr. and
considering various clarifications, changes, additions, enhancements,
modifications.
The "cleanup committee" of X3J13 is considering those minor clarifications,
changes, additions, enhancements, modifications as do not fit within the charter
of the other subcommittee's of X3J13 (namely objects, windows & graphics,
characters, iteration, compilation, validation, and possibly some others that I
forget.)
The process for various cleanups is that we (the cleanup committee) consider
proposals either that we generate (e.g., based on Guy Steele's original list of
proposed modifications), that we get from the community, or are based on mail to
common-lisp@Sail.stanford.edu that seems to have reached some convergence.
We produce a writeup (similar to the one I mailed for FLET-IMPLICIT-BLOCK) for
consideration by X3J13. X3J13 then can vote on a ballot which essentially says
("we believe the ANSI standard for Common Lisp should reflect the following
change/addition/enhancement" etc.)
Until there's an official standard, there isn't an official standard. Until
there's an official standard, the best an implementor can do is to document the
ways in which the implementation differs from CLtL.
The cleanup proposals, in their various draft forms, are a good indication of
those places where CLtL is ambiguous, lacking, or subject to change; those
cleanup proposals endorsed by X3J13 are a very good indication of what the ANSI
standard will look like. However, the result of the standard process will be a
single standard with (we hope) no options. An implementation will either conform
or it will not.
They are, of course, not official until there is an official standard that
includes them.
What's it all mean to you?
Well, if you have strong opinions about any of the proposals, make sure your
X3J13 representative hears about them. If you would like some additional
changes, please give them to your X3J13 representative to submit.
∂03-Jan-88 1814 CL-Cleanup-mailer cleanup status
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jan 88 18:13:55 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 313876; Sun 3-Jan-88 21:14:04 EST
Date: Sun, 3 Jan 88 21:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cleanup status
To: masinter.PARC@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880103-130343-1016@Xerox>
Message-ID: <880103211335.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 2 Jan 88 23:04:12 PST (Saturday)
From: masinter.PARC@Xerox.COM
Kent: I composed the following as a follow-up to mail to
common-lisp@sail.stanford.edu. Would this address your concerns?
It helps considerably, and it may be that it expresses the majority viewpoint.
But there's one paragraph that really misses my preference. I've marked it
below.
- - - - - - - - - - -
My recent message prompted enough debate that I thought I would clarify what I
meant in my recent message about FLET. Some assumptions:
X3J13 is attempting to define an ANSI standard for Common Lisp.
X3J13 is starting with "Common Lisp the Language" by Guy L. Steele, Jr. and
considering various clarifications, changes, additions, enhancements,
modifications.
The "cleanup committee" of X3J13 is considering those minor clarifications,
changes, additions, enhancements, modifications as do not fit within the charter
of the other subcommittee's of X3J13 (namely objects, windows & graphics,
characters, iteration, compilation, validation, and possibly some others that I
forget.)
The process for various cleanups is that we (the cleanup committee) consider
proposals either that we generate (e.g., based on Guy Steele's original list of
proposed modifications), that we get from the community, or are based on mail to
common-lisp@Sail.stanford.edu that seems to have reached some convergence.
We produce a writeup (similar to the one I mailed for FLET-IMPLICIT-BLOCK) for
consideration by X3J13. X3J13 then can vote on a ballot which essentially says
("we believe the ANSI standard for Common Lisp should reflect the following
change/addition/enhancement" etc.)
Until there's an official standard, there isn't an official standard. Until
there's an official standard, the best an implementor can do is to document the
ways in which the implementation differs from CLtL.
If I had my way, this previous paragraph would be (what seems to me)
radically different. I would say something more like:
The information contained in these proposals is provided for informational
purposes only and is not a suggestion that implementors should implement the
changes mentioned.
In fact, implementors are strongly encouraged not to implement any changes
which are incompatible with CLtL, since the principle value of CLtL as a
standard is that it has no competitors. If implementors pick and choose
from CLtL and whichever of these modifications they find easy or interesting,
the state of informal standardization in the Common Lisp community will be
lessened.
Extensions mentioned in these writeups which are compatible extensions can,
of course, be added at any time but should not be described as Common Lisp.
Until an ANSI or ISO Common Lisp standard is available, the name Common Lisp
should refer only to what is in CLtL for the sake of everyone's sanity.
These extensions may be referred to as "proposed extensions" which might
someday be part of a future Common Lisp standard.
The cleanup proposals, in their various draft forms, are a good indication of
those places where CLtL is ambiguous, lacking, or subject to change; those
cleanup proposals endorsed by X3J13 are a very good indication of what the ANSI
standard will look like. However, the result of the standard process will be a
single standard with (we hope) no options. An implementation will either conform
or it will not.
You might mention here that even though they have received endorsement in isolation,
they may be later superseded by other proposals or rescinded on the basis of
"new evidence".
They are, of course, not official until there is an official standard that
includes them.
What's it all mean to you?
Well, if you have strong opinions about any of the proposals, make sure your
X3J13 representative hears about them. If you would like some additional
changes, please give them to your X3J13 representative to submit.
The rest of this is quite good.
∂03-Jan-88 2012 CL-Cleanup-mailer cleanup status
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jan 88 20:11:59 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Sun 3 Jan 88 23:11:43-EST
Date: Sun, 3 Jan 1988 23:11 EST
Message-ID: <FAHLMAN.12363805431.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: cleanup status
In-reply-to: Msg of 3 Jan 1988 21:13-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Well, for what it's worth, I tend to agree with Masinter on this rather
than KMP. I think that it is unreasonable to tell implementors to stick
with CLtL and to ignore all the individual proposals that have been
adopted until ANSI and ISO formally adopt a new standard for all of
Common Lisp. Maybe that has to be our legal position so that this
committee doesn't get sued, but in a rational world (meaning one in
which all the lawyers and those who traffic with them have been killed
off), it would make sense for implementors to track these changes as
they are adopted, or perhaps in discrete batches. I grant that it is
wrong to pick and choose among these issues; in a given release you
should adopt all of them up to some particular cutoff date, and should
clearly state what you have done.
Most of these items, after all, resolve some ambiguity in CLtL. To
ignore them is to perpetuate a situation where no standardization
currently exists. Some others (the error system and CLOS, but also some
smaller ones) address omissions from CLtL that people are dealing with
in various incompatible ways. In very few cases are we proposing a
truly incompatible change, and where we do it is usually in some case
where the existing situation is unworkable or is incompatible with some
of the above-mentioned extensions. In each case, we have addressed the
issue of how existing code can be updated to fit into the new system.
Obviously it creates some portability problems if implementations track
these changes with different delays, but I think that the situation we
would get if we advised people to wait a few years until this is done
would be much worse in practice. I'm not sure what the current official
statement is on when we might expect an official standard or even an
approved draft standard from X3J13, but we can't really expect people to
stand pat until the great day arrives.
-- Scott
∂04-Jan-88 0852 CL-Cleanup-mailer Re: cleanup status
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 08:52:25 PST
Date: 4 Jan 1988 11:50-EST
Sender: MATHIS@A.ISI.EDU
Subject: Re: cleanup status
From: MATHIS@A.ISI.EDU
To: KMP@SCRC-STONY-BROOK.ARPA
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 4-Jan-88 11:50:38.MATHIS>
In-Reply-To: <880103211335.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I usually keep quiet on this list, but I think the proposed
message of Larry's with Kent's modifications is coming pretty
close to something we should distribute to the whole community.
I get requests for X3J13 documents and send them out with some
form of disclaimer - this is only a working draft of something
under consideration. But people want to know what's going on.
After the upcoming Palo Alto meeting, I expect we will have more
documents which have achieved some form of voted status, but
which we still do not want to be considered any kind of
incremental version of the standard.
The clean-up committee has been considering two kinds of things
-- one, clarifications of the current CLtL; and two, things that
go (slightly?) beyond the book. We should try to clearly
identify which is which and put together appropriate information
for wider distribution.
People who want to be involved with the discussions and decision
making should be working within X3J13; but we also have a
responsibility for providing authoritative information on what we
are doing and what implications it may have for current and
future implementations of the "standard."
Bob
∂04-Jan-88 1147 CL-Cleanup-mailer Re: New issue: FLET-DECLARATIONS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jan 88 11:47:42 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 JAN 88 11:45:03 PST
Date: Mon, 4 Jan 88 11:44:49 PST
From: Pavel.pa@Xerox.COM
Subject: Re: New issue: FLET-DECLARATIONS
In-reply-to: <19880101204506.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Cl-Cleanup@SAIL.STANFORD.EDU, Hornig@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880104-114503-2255@Xerox>
For the current practice section, the Xerox Lisp compiler (and maybe
interpreter, I don't remember for sure and don't immediately have access to a
Lisp image) already supports all of these declarations with the specified scope.
Pavel
∂04-Jan-88 1309 CL-Cleanup-mailer Re: cleanup status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jan 88 13:09:35 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 JAN 88 13:09:08 PST
Date: 4 Jan 88 13:08 PST
From: Masinter.pa@Xerox.COM
Subject: Re: cleanup status
In-reply-to: various
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880104-130908-2402@Xerox>
When all is said in done, it doesn't matter much what we "recommend"
implementors do; they'll do what they please, including shipping things that
don't implement lexical scoping correctly.
It is probably just as well to leave out what we recommend to implementors and
leave our recommendation to users, viz: note that these are proposed likely
changes to the standard and to watch out for them.
∂04-Jan-88 1832 CL-Cleanup-mailer &REST lists
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jan 88 18:32:43 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 314827; Mon 4-Jan-88 21:32:30 EST
Date: Mon, 4 Jan 88 21:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: &REST lists
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12364037774.BABYL@C.CS.CMU.EDU>
Message-ID: <880104213156.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[Common-Lisp removed; I can't bear to be heard by such multitudes.
CL-Cleanup added.]
Date: Mon, 4 Jan 1988 20:27 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Is there general agreement on whether it is valid Common Lisp to
destructively modify (RPLACA, RPLACD) the list to which a &REST
parameter is bound? I can't find a reference in CLtL for this.
I think there's general agreement that &rest args are supposed to be
righteous lists with indefinite extent, so RPLAC'ing them ought to be
legal.
However, this was one part of the Common Lisp spec that several early
implementations deliberately chose to deviate from in the interest of
greater efficiency. (Symbolics and TI were able to gain considerable
efficiency by consing rest args on the stack.) Both companies had plans
to fix this eventually, stack-consing only when the compiler could prove
it was safe to do so, but I don't know if this has finally been
accomplished and distributed to all users.
I think TI has already fixed it. Symbolics' Cloe also fixes it.
Symbolics Genera plans to fix it at some unspecified future date.
But anyway, the rplaca/rplacd problem is not related to the issue of stack
allocation. It's the following problem, which comes up in conventional
architectures as well:
(DEFVAR *MY-LIST* '(A B C))
(DEFUN FOO (&REST X) (EQ X *MY-LIST*))
(APPLY #'FOO *MY-LIST*) => T ;on Symbolics systems and probably
; many stock hardware implementations
This implies that
(DEFUN BAR (&REST X) (RPLACA X 'D))
(APPLY #'BAR *MY-LIST*)
*MY-LIST* => (D B C) ;on Symbolics systems and probably many stock
; hardware implementations
∂04-Jan-88 2035 CL-Cleanup-mailer &REST lists
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 20:35:28 PST
Received: by labrea.stanford.edu; Mon, 4 Jan 88 20:35:23 PST
Received: from kent-state.lucid.com by edsel id AA13360g; Mon, 4 Jan 88 20:27:31 PST
Received: by kent-state id AA00227g; Mon, 4 Jan 88 20:29:31 PST
Date: Mon, 4 Jan 88 20:29:31 PST
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8801050429.AA00227@kent-state.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: Fahlman@c.cs.cmu.edu, CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Mon, 4 Jan 88 21:31 EST <880104213156.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: &REST lists
Date: Mon, 4 Jan 88 21:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Mon, 4 Jan 1988 20:27 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Is there general agreement on whether it is valid Common Lisp to
destructively modify (RPLACA, RPLACD) the list to which a &REST
parameter is bound? I can't find a reference in CLtL for this.
I think there's general agreement that &rest args are supposed to be
righteous lists with indefinite extent, so RPLAC'ing them ought to be
legal.
...
I think TI has already fixed it. Symbolics' Cloe also fixes it.
Symbolics Genera plans to fix it at some unspecified future date.
But anyway, the rplaca/rplacd problem is not related to the issue of stack
allocation. It's the following problem, which comes up in conventional
architectures as well:
(DEFVAR *MY-LIST* '(A B C))
(DEFUN FOO (&REST X) (EQ X *MY-LIST*))
(APPLY #'FOO *MY-LIST*) => T ;on Symbolics systems and probably
; many stock hardware implementations
This implies that
(DEFUN BAR (&REST X) (RPLACA X 'D))
(APPLY #'BAR *MY-LIST*)
*MY-LIST* => (D B C) ;on Symbolics systems and probably many stock
; hardware implementations
The Revised↑3 Report on Scheme specifies that the equivalent of a
&REST argument must be a newly allocated list, to avoid precisely this
problem.
∂05-Jan-88 0521 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 5 Jan 88 05:21:13 PST
Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 156176; Tue 5-Jan-88 08:21:23 EST
Date: Tue, 5 Jan 88 08:21 EST
From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871119-175949-1009@Xerox>
Message-ID: <19880105132119.9.HORNIG@WINTER.SCRC.Symbolics.COM>
Issue: DECLARATION-SCOPING
References: Section 9.1 (pp. 153-157).
Category: CHANGE
Edit history: V1: Hornig@Symbolics.COM -- 5 January 1988
Problem description:
The description of the scope of declarations made with DECLARE is both
unclear (although unambiguous) and arguably a mistake. The issue is
whether the scope of some or all of the declarations includes code
appearing in the non-body part of the special form containing the
declaration.
Proposal DECLARATION-SCOPING:LIKE-VARIABLE:
For the purposes of this proposal, we divide all declarations introduced
with DECLARE into two classes. When a declaration of a variable appears
before the body of a special form or lambda-expression that binds that
variable, the declaration is called `normal'. All other declarations
are called `free'. This division replaces the division into pervasive,
nonpervasive, and SPECIAL declarations appearing in CLtL.
The scope of a `normal' declaration is exactly the scope of the
associated lexical variable or function. If the declaration is
associated with a special variable, the scope is the scope the variable
would have had if it had not been special. `Free' declarations are
scoped as if they appeared in a new LOCALLY form which surrounded the
entire special form of which the declaration appears at the beginning of
the body.
SPECIAL declarations may be either `normal', affecting both a binding
and references, or `free', affecting only references. TYPE and IGNORE
declarations may only be `normal'. (There has been some discussion in
X3J13 of permitting `free' TYPE declarations.)
If Common Lisp is extended to permit declarations in FLET and LABELS
forms, then declarations of functions (FTYPE, FUNCTION, INLINE, and
NOTINLINE) which appear before the body of a FLET or LABELS form which
defines that function are also `normal'.
Common Lisp is ambiguous about whether a variable may be bound several
times by a single form. It has been proposed that multiple bindings be
permitted for LET*, DO*, PROG* forms and for &AUX variables in lambda
expressions. If multiple bindings are permitted, `normal' declarations
are treated as if there were a separate `normal' declaration for each of
the bindings.
Examples:
;;; Some examples of `free' and `normal' declarations.
(let ((a 1))
(declare (optimize speed)) ;this is a `free' declaration
(let ((b 2))
(declare (type integer b)) ;this is a `normal' declaration
(declare (special a)) ;this is a `free' declaration
()))
;;; This example applies if you believe that FLET may have declarations.
(flet ((foo (x) (1+ x)))
(declare (notinline foo)) ;this is a `normal' declaration
(declare (notinline 1+)) ;this is a `free' declaration
())
;;; The following code is from Pavel.
;;; It produces 7 in existing implementations.
;;; If the proposal is adopted, it will produce 8.
(let ((foo 6)) ;a special binding of FOO
(declare (special foo)) ;`normal' declaration
(let ((foo 7)) ;a lexical binding of FOO
(let ((foo (1+ foo))) ;is the second FOO special or not?
(declare (special foo)) ;`normal' declaration
foo)))
;;; Treatment of LET* under the proposal if multiple bindings of the same name are allowed.
;;; This form produces the value 9.
(let ((foo 6)) ;a special binding of FOO
(declare (special foo)) ;`normal' declaration
(let ((foo 7)) ;a lexical binding of FOO
(let* ((foo (1+ foo)) ;special binding, lexical reference
(foo (1+ foo))) ;special binding, special reference
(declare (special foo)) ;`normal' declaration, applies to both bindings
foo)) ;special reference
Rationale:
`Normal' declarations are made to control a particular binding of a
variable and should be scoped the same way as that binding. This is as
true of `normal' declarations which were pervasive under the old rules
as it is of those that were not.
Current practice:
The `normal'/`free' division based on context replaces CLtL's static
pervasive/nonpervasive/SPECIAL division. Most implementations implement
the rules in CLtL. Symbolics currently implements rules based on
Zetalisp which are different from both this proposal and Common Lisp.
Symbolics plans to change to Common Lisp rules in the future.
Cost to Implementors:
The cost of implementing this change should be moderate. The change
will be localized to a handful of places in the compiler and interpreter
which apply declarations to variables. The other cost would be in
providing tools for users to find programs whose meaning will change.
Cost to Users:
The proposal changes only the treatment of `normal' declarations. This
change will break very few existing production programs.
It is possible to mechanically examine a program to determine whether
its behavior would change under the new rules. This permits an
implementation to provide a transition tool to ease conversion to the
new definition.
Cost of non-adoption:
The ability of a `normal' declaration to affect code outside the scope
of the variable which it appears to declare has led to endless confusion
and discussion at Symbolics, on the Common-Lisp mailing list, and
elsewhere. It will continue to do so unless it is smoothed over somehow.
Benefits:
The costs of non-adoption will be avoided.
Aesthetics:
The distinction between `normal' and `free' declarations introduced by
this proposal is a natural one.
Discussion:
A proposal to forbid `free' declarations except in LOCALLY forms and a
proposal to have `free' declarations affect only the body were discarded
as being too incompatible.
The mapping from the existing pervasive/nonpervasive/SPECIAL division of
declarations and the one proposed here is complex. In general,
nonpervasive declarations are `normal' and pervasive declarations are
`free'. SPECIAL declarations are either `normal' or `free' based on
their context, and are no longer treated as a special case.
Some historical support for having `free' and `normal' declarations:
Date: Tue, 20 Dec 83 15:50 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Declarations
To: Common-Lisp@SU-AI.ARPA
...
There are two disjoint classes of declaration: those that are attached
to a particular variable binding, and those that are not. Note that I
am not discussing proclamations here; they have their own scoping rules
which are different from the rules for declarations.
The scoping rule for the first kind of declaration is that it applies to
precisely the text that is in the lexical scope of the variable binding
with which it is associated. Such declarations are shadowed by a
variable binding for the same name inside their scope. Since the
lexical scoping rules are very well and precisely defined, we already
understand everything about this kind of declaration.
The scoping rule for the second kind of declaration is that it is
pervasive. The declaration is attached to a lambda-expression or to a
form (one of the special forms listed on page 125). The declaration
applies to all text inside that expression or form; there are no special
cases such as init-forms of LET or DO. Such declarations are shadowed
by a conflicting declaration inside their scope.
Possible names for the two kinds of declaration are "lexical" and
"pervasive" or "variable" and "non-variable."
...
∂05-Jan-88 0938 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jan 88 09:37:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 315295; 5 Jan 88 12:35:50 EST
Date: Tue, 5 Jan 88 12:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
In-Reply-To: <19880105132119.9.HORNIG@WINTER.SCRC.Symbolics.COM>
Message-ID: <19880105173525.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I'm strongly in favor of DECLARATION-SCOPING:LIKE-VARIABLE; I think
it nicely settles a long-standing problem with Common Lisp. I support
this even though I'm usually opposed to incompatible changes.
∂05-Jan-88 1345 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jan 88 13:45:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JAN 88 13:45:00 PST
Date: Tue, 5 Jan 88 13:44:36 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: DECLARATION-SCOPE
In-reply-to: <19880105132119.9.HORNIG@WINTER.SCRC.Symbolics.COM>
To: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880105-134500-4150@Xerox>
Unsurprisingly, since it's so close to what I informally proposed a year or two
ago, I generally favor this proposal; it is much much better than the status
quo. I do have a few concerns, though:
1) It is not clear to me that free declarations should cover the entire form. I
note, in particular, that none of the discussion or rationale mentions the
scoping of free declarations. The alternative that seems more natural to me has
them covering only the body of the special form in which they appear, not the
entire special form. Charles, could you discuss this?
2) I would very much like to see more detail in the proposal. In particular, I
would like a complete listing of the types of declarations and their kinds
(normal vs. free). Conceivably, a list of all of the macros and special forms
supporting declarations and the scopes in each case should also be included. It
may be, however, that this description is implied by the (sometimes nonexistent)
definitions of the semantics of the various macros and special forms.
3) I don't like using the name ``normal'' for one half of a dichotomy,
especially considering that the other half is named ``free''. Is there any
reason not to call the others ``bound'' instead of ``normal''?
Pavel
∂05-Jan-88 1430 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 5 Jan 88 14:30:28 PST
Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 156483; Tue 5-Jan-88 17:30:38 EST
Date: Tue, 5 Jan 88 17:30 EST
From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARATION-SCOPE
To: Pavel.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880105-134500-4150@Xerox>
Message-ID: <19880105223028.7.HORNIG@WINTER.SCRC.Symbolics.COM>
Date: Tue, 5 Jan 88 13:44:36 PST
From: Pavel.pa@Xerox.COM
Unsurprisingly, since it's so close to what I informally proposed a year or two
ago, I generally favor this proposal; it is much much better than the status
quo. I do have a few concerns, though:
1) It is not clear to me that free declarations should cover the entire form. I
note, in particular, that none of the discussion or rationale mentions the
scoping of free declarations. The alternative that seems more natural to me has
them covering only the body of the special form in which they appear, not the
entire special form. Charles, could you discuss this?
I was trying for greater compatibility. Most `free' declarations are
currently pervasive and apply to the entire form. The intent of the
proposal was to leave them mostly as they are now. I would consider
changing them to apply only to the body to be a separable and separate
change.
2) I would very much like to see more detail in the proposal. In particular, I
would like a complete listing of the types of declarations and their kinds
(normal vs. free). Conceivably, a list of all of the macros and special forms
supporting declarations and the scopes in each case should also be included. It
may be, however, that this description is implied by the (sometimes nonexistent)
definitions of the semantics of the various macros and special forms.
When I started to do this, I got bogged down in all sorts of unrelated
issues. For example, are free TYPE declarations permitted in Common
Lisp? I didn't want this proposal to become a vehicle for all sorts of
unrelated changes or claraifications to declaration processing.
3) I don't like using the name ``normal'' for one half of a dichotomy,
especially considering that the other half is named ``free''. Is there any
reason not to call the others ``bound'' instead of ``normal''?
I'd love to use a better name. I hope others will comment on this.
∂05-Jan-88 1458 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jan 88 14:58:10 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 315732; Tue 5-Jan-88 17:57:50 EST
Date: Tue, 5 Jan 88 17:57 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARATION-SCOPE
To: Pavel.pa@Xerox.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
Hornig@ALDERAAN.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880105-134500-4150@Xerox>,
<19880105173525.2.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<19880105132119.9.HORNIG@WINTER.SCRC.Symbolics.COM>
Message-ID: <880105175714.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I concur with Moon's supportive remarks about Hornig's proposal.
Date: Tue, 5 Jan 88 13:44:36 PST
From: Pavel.pa@Xerox.COM
... It is not clear to me that free declarations should cover the entire form. ...
We discussed this internally before Hornig sent the proposal. I and others here
wanted free declarations to cover the entire form mainly because you need to be
able to declare things in the lambda list of a DEFUN form and you can't put a
LOCALLY around the outside of the DEFUN or the defun will no longer be at top
level (and hence may not get compiled in some implementations). eg, consider
(DEFUN FOO (&OPTIONAL (X Z) (Y Z))
(DECLARE (SPECIAL Z))
...)
If you don't have the proposed semantics, you have to write:
(LOCALLY (DECLARE (SPECIAL Z))
(DEFUN FOO (&OPTIONAL (X Z) (Y Z))
...))
which doesn't really work for the reasons cited above, or
(DEFUN FOO (&OPTIONAL (X (LOCALLY (DECLARE (SPECIAL Z)) Z))
(Y (LOCALLY (DECLARE (SPECIAL Z)) Z)))
...)
which works but is very tedious to write.
∂05-Jan-88 1644 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jan 88 16:44:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JAN 88 16:42:09 PST
Date: Tue, 5 Jan 88 16:41:43 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: DECLARATION-SCOPE
In-reply-to: <880105175714.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Hornig@ALDERAAN.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880105-164209-4496@Xerox>
Kent points out that having free declarations cover the entire form allows one
to conveniently cover the expressions in &optional, &key and &aux expressions.
In some sense, those expressions are a part of the ``body'' of the lambda
expression. Perhaps a more picky definition of ``body'' would be better than
the blanket coverage. That is, let declarations in lambda forms cover the
entire form but those in, say, LET forms only cover the body. This allows me to
understand LET as a macro expanding into a simple call of a LAMBDA without any
caveats about declaration parsing.
Pavel
∂05-Jan-88 1922 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 19:22:16 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Tue 5 Jan 88 22:22:19-EST
Date: Tue, 5 Jan 1988 22:22 EST
Message-ID: <FAHLMAN.12364320725.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: DECLARATION-SCOPE
DECLARATION-SCOPE:LIKE-VARIABLE looks good to me.
I agree that "normal" is a somewhat loaded term. "Bound" seems wrong.
How about calling these "binding-related declarations"? Not a
critically important issue in any case.
Is there any effective difference between saying that "free" declarations
surround the whole form and saying that they surround only the body, but
that the init forms are part of the body? If not, the former way of
stating it seems clearer.
-- Scott
∂05-Jan-88 1958 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jan 88 19:58:42 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JAN 88 19:57:40 PST
Date: Tue, 5 Jan 88 19:57:09 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: DECLARATION-SCOPE
In-reply-to: <FAHLMAN.12364320725.BABYL@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880105-195740-4775@Xerox>
Scott asks, ``Is there any effective difference between saying that "free"
declarations surround the whole form and saying that they surround only the
body, but that the init forms are part of the body? If not, the former way of
stating it seems clearer.''
I assume that this is addressed to my suggestion that free declarations in
LAMBDA-forms cover the default-value expressions in &optional, &aux, and &key
parameters. The point is that I would rather that such declarations didn't
cover the init-expressions in LET and the bodies of the lexical functions in
FLET and LABELS. If you macroexpand LET in the obvious way, with the
declarations inside the LAMBDA form, then the init forms are outside of the
scope of the free declarations, as I would desire.
I think that the reason that I want this is that in the following:
(let ((foo init-expression))
(declare ((bound-declaration foo)
(free-declaration)))
body)
the free declaration covers the init expression while the bound one does not. I
think of declarations as appearing at the head of the code that they cover and
so I'd want both of these declarations to cover only the body. In fact, I think
that I would rather that the free declarations in a LAMBDA form only cover the
real body, and not the default-value expressions, for just this reason. I guess
that I'm not impressed by Kent's example since I don't see very much use for
local declarations around default-value expressions. Perhaps he'll show me some
startlingly clear-cut example of this being useful.
Bound declarations, on the other hand, should have identical scope with the
variable to which they refer. This seems intuitive since they are, in effect,
changing the overal meaning of that variable.
Pavel
∂06-Jan-88 0736 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 07:36:46 PST
Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Wed 6 Jan 88 10:36:51-EST
Date: Wed, 6 Jan 1988 10:29 EST
Message-ID: <RAM.12364453185.BABYL@>
Sender: RAM
From: Ram at c.cs.cmu.edu
To: Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup at SAIL.STANFORD.EDU,
Hornig at ALDERAAN.SCRC.Symbolics.COM,
Moon at STONY-BROOK.SCRC.Symbolics.COM, Pavel.pa at Xerox.COM
Subject: Issue: DECLARATION-SCOPE
In-reply-to: Msg of 5 Jan 1988 17:57-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
ReSent-Date: Wed 6 Jan 88 10:36:50-EST
ReSent-From: Rob.MacLachlan@C.CS.CMU.EDU
ReSent-To: cl-cleanup@SAIL.STANFORD.EDU
ReSent-Message-ID: <12364454448.17.RAM@C.CS.CMU.EDU>
Date: Tuesday, 5 January 1988 17:57-EST
From: Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup at SAIL.STANFORD.EDU
Re: Issue: DECLARATION-SCOPE
[...] I and others here wanted free declarations to cover the
entire form mainly because you need to be able to declare things
in the lambda list of a DEFUN form and you can't put a LOCALLY
around the outside of the DEFUN or the defun will no longer be at
top level (and hence may not get compiled in some
implementations).
I think that this argument is pretty weak, since the concept of "at
top level" doesn't belong in the language (and isn't currently
defined). Any implementation that doesn't compile a definition
when a LOCALLY (or anything else) is wrapped around it is a broken
implementation.
Rob
∂06-Jan-88 1334 CL-Cleanup-mailer cleanup status
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 13:34:21 PST
Received: by labrea.stanford.edu; Wed, 6 Jan 88 13:34:23 PST
Received: from bhopal.lucid.com by edsel id AA20541g; Wed, 6 Jan 88 12:48:49 PST
Received: by bhopal id AA11867g; Wed, 6 Jan 88 12:51:10 PST
Date: Wed, 6 Jan 88 12:51:10 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8801062051.AA11867@bhopal.lucid.com>
To: labrea!MATHIS%A.ISI.EDU@labrea.stanford.edu
Cc: labrea!cl-cleanup%SAIL@labrea.stanford.edu
In-Reply-To: MATHIS@A.ISI.EDU's message of 4 Jan 1988 11:50-EST <[A.ISI.EDU] 4-Jan-88 11:50:38.MATHIS>
Subject: cleanup status
re:
People who want to be involved with the discussions and decision
making should be working within X3J13; but we also have a
responsibility for providing authoritative information on what we
are doing and what implications it may have for current and
future implementations of the "standard."
This seems to me a succinct, reasonable statement of policy regarding
"outsiders". There's probably no need for us to lecture the vendors
on how closely the must adhere to CLtL -- it's their responsibility to
document their deviations and extensions.
-- JonL --
∂06-Jan-88 1414 CL-Cleanup-mailer cleanup status
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 Jan 88 14:14:24 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 316518; Wed 6-Jan-88 17:13:58 EST
Date: Wed, 6 Jan 88 17:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cleanup status
To: edsel!jonl@labrea.stanford.edu
cc: CL-Cleanup@SAIL.STANFORD.EDU, MATHIS@ADA20.ISI.EDU
In-Reply-To: <8801062051.AA11867@bhopal.lucid.com>
Message-ID: <880106171310.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 6 Jan 88 12:51:10 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
... There's probably no need for us to lecture the vendors
on how closely the must adhere to CLtL -- it's their responsibility to
document their deviations and extensions.
I'm sorry, but I disagree. I do not believe that we with our vendors'
hats on do have the wisdom or the freedom from conflict of interest to
make that decision correctly.
When there was only CLtL, it was obvious what was the right thing and
what was not. It is no longer obvious because our committee is randomizing
things. Our committee must speak clearly to the community about what we
intend so that people who want to adhere to that advice can do so.
It is in vendors' best interest to add as many whizzy features as they
can because it makes for more bullet items on marketing literature, because
bug fixes sound (naively) like an improvement over non-bug fixes, and because
the more you can make your implementation different than CL, the more locked
into your product your customer base becomes.
On the other hand, I believe it is in the community's best interest for
there to be a clear source of authority. For better or worse, a standard
exists with certain features people can depend upon. If people go
changing things around at random, application vendors get screwed trying
to keep up with the different rates of change on the different platforms.
I'm speaking from experience as a Macsyma maintainer (large 3rd party product)
not from my current position as a lisp developer.
In Cloe, the LISP package does exactly what the LISP package in CLtL says
it should. If we wanted to extend anything, we did it on a proprietary package
that shadowed the LISP symbol. For example, CLOE:IF takes a body but LISP:IF
is true to the standard. CLOE:CHAR-EQUAL fixes the CHAR-EQUAL mess, but
LISP:CHAR-EQUAL does what CLtL losingly says it should. I think this is the
right approach for all vendors to take until a standard is reached.
If we don't say this to the community, who can?
If chaos results, who is to blame but us?
∂06-Jan-88 1804 CL-Cleanup-mailer cleanup status
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 18:04:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Wed 6 Jan 88 21:04:28-EST
Date: Wed, 6 Jan 1988 21:04 EST
Message-ID: <FAHLMAN.12364568696.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: cleanup status
In-reply-to: Msg of 6 Jan 1988 17:13-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
If chaos results, who is to blame but us?
Well, maybe there is some middle ground between chaos and living with
CLtL, as is, for two or three more galactic rotations. If those are the
only two choices, I'll take chaos.
∂06-Jan-88 2034 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 20:34:17 PST
Received: by labrea.stanford.edu; Wed, 6 Jan 88 20:34:19 PST
Received: from bhopal.lucid.com by edsel id AA00386g; Wed, 6 Jan 88 20:23:40 PST
Received: by bhopal id AA14597g; Wed, 6 Jan 88 20:26:00 PST
Date: Wed, 6 Jan 88 20:26:00 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8801070426.AA14597@bhopal.lucid.com>
To: labrea!Hornig%ALDERAAN.SCRC.Symbolics.COM@labrea.stanford.edu
Cc: labrea!cl-cleanup%SAIL@labrea.stanford.edu
In-Reply-To: Charles Hornig's message of Tue, 5 Jan 88 08:21 EST <19880105132119.9.HORNIG@WINTER.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE
I welcome this proposal wholeheartedly -- it irons out another of those
brainos for which no one can now even remember a decent rationale.
However, there is one point I'd like to see pressed further. You propose:
The scope of a `normal' declaration is exactly the scope of the
associated lexical variable or function. . . .
SPECIAL declarations may be either `normal', affecting both a binding
and references, or `free', affecting only references. TYPE and IGNORE
declarations may only be `normal'. (There has been some discussion in
X3J13 of permitting `free' TYPE declarations.)
I think it is very shortsighted to limit the TYPE and IGNORE declarations
this way. In so far as IGNORE is merely advice to the compiler to stop
issuing worthless "bound, but unreferenced" warning messages, there is
no incompatiblity with it being in a LOCALLY form; it just means inhibit
warning messages for instances found in this lexical range.
Now the probable rationale for limiting the TYPE declaration must have
been so that it could affect the way in which bindings occur [e.g., in
pdp10 MacLisp, a flonum is stored on a float pdl, but a regular variable
is stored on the regpdl.] It is all well and fine if the user-supplied
scoping information can include the binding; but what if it can't? is it
so bad that the supplied information can be only partly useful in
optimization? Isn't it much better to permit the compiler to use the
useful part than to prohibit it from noticing at all? Take, for example:
(let ((x <some-value>))
(if (floatp x)
(locally (type float x)
(+ x 3.4))
(if (integerp x)
(ash x -3)
(error "What the heck"))))
If the compiler is prohibited from noticing the LOCALLY type declaration,
then it can't open-code the "+" operation; otherwise, it can open-code it.
True, it will be fetching x from a regular "pointer" location rather than
from a floating-point register (or whatever), but at least it will be
doing something that can make an order of magnitude difference in speed
(at least with Lucid's compiler).
After all, nothing compels a conforming compiler to do anything *different*
with a binding when it notices a TYPE declaration affecting the variable
being bound.
This particular problem may be more than you wanted to bite off; if so,
maybe I'll be able to find the time to submit a separate proposal on it.
But since you've taken the plunge already on declaration scoping (and
since I've been so busy with product deadlines etc.) I thought you may
want to field the whole matter.
-- JonL --
∂06-Jan-88 2318 CL-Cleanup-mailer Issue: DECLARE-MACROS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Jan 88 23:18:05 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 88 23:18:53 PST
Date: 6 Jan 88 23:18 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DECLARE-MACROS
to: cl-cleanup@sail.stanford.edu
Message-ID: <880106-231853-6452@Xerox>
I thought that while there were some objections to DECLARE-MACROS the proposal
recieved very strong endorsement from many members of the community. I thought
we needed to address the objections and resubmit it.
Does anyone else have any notes or recollection?
----- Begin Forwarded Messages -----
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 04 JAN 88 19:09:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 314856; Mon 4-Jan-88 22:08:36 EST
Date: Mon, 4 Jan 88 22:08 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: New issue: FLET-DECLARATIONS
To: Masinter.pa
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880104-170649-2879@Xerox>
Message-ID: <19880105030822.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 4 Jan 88 17:06 PST
From: Masinter.pa@Xerox.COM
I think we should presume in future cleanup issues that DECLARE-MACROS has
been
accepted. Your writeup sentence "This rule is required in order to permit
macros
to expand into DECLARE, as noted above." should probably be changed.
Really? I had pretty well assumed that DECLARE-MACROS was being withdrawn,
because
so many people had surfaced who depend on macros expanding into declarations, so
that it would be a significant incompatible change. From a language cleanliness
point of view, I'd like macros not to expand into declarations, but from a
practical
point of view I no longer care; at one point I had mistakenly claimed that this
was
a major source of slowness in our compiler, but that turned out not to be true.
It's related to a source of slowness, and fixing the slowness is made more
complex
by the need to worry about macros expanding into declarations, but removing the
feature from the language really wouldn't help us very much. I was just
confused
on that point.
----- End Forwarded Messages -----
∂06-Jan-88 2331 CL-Cleanup-mailer Cleanup status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Jan 88 23:29:07 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 88 23:29:40 PST
Date: 6 Jan 88 23:28 PST
From: Masinter.pa@Xerox.COM
Subject: Cleanup status
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880106-232940-6463@Xerox>
OK, here's another try.
My recent message prompted enough debate that I thought I would clarify what I
meant in my recent message about FLET. Some assumptions:
X3J13 is attempting to define an ANSI standard for Common Lisp.
X3J13 is starting with "Common Lisp the Language" by Guy L. Steele, Jr. and
considering various clarifications, changes, additions, enhancements,
modifications.
The "cleanup committee" of X3J13 is considering those minor clarifications,
changes, additions, enhancements, modifications as do not fit within the charter
of the other subcommittee's of X3J13 (namely objects, windows & graphics,
characters, iteration, compilation, validation, and possibly some others that I
forget.)
The process for various cleanups is that we (the cleanup committee) consider
proposals either that we generate (e.g., based on Guy Steele's original list of
proposed modifications), that we get from the community, or are based on mail to
common-lisp@Sail.stanford.edu that seems to have reached some convergence.
We produce a writeup (similar to the one I mailed for FLET-IMPLICIT-BLOCK) for
consideration by X3J13. X3J13 then can vote on a ballot which essentially says
("we believe the ANSI standard for Common Lisp should reflect the following
change/addition/enhancement" etc.)
The cleanup proposals, in their various draft forms, are a good indication of
those places where CLtL is ambiguous, lacking, or subject to change; those
cleanup proposals endorsed by X3J13 are a very good indication of what the ANSI
standard will look like. However, the result of the standard process will be a
single standard with (we hope) no options. An implementation will either conform
or it will not.
If implementors want our advice (unlikely as that might be), we'd advise them to
quickly adopt those proposals which resolve ambiguities in CLtL and (as
"Proposed Extensions likely to be in the Common Lisp standard") to implement
those proposals that are extensions.
However, we would advise implementors not to release (at least as "Common Lisp")
implementations with the proposals that are incompatible changes; to do
otherwise would increase the diversity of "Common Lisp" implementations for
users, rather than decrease it.
Most strongly, of course, we'd advise implementors to document their
implementation carefully in these areas, so that users might at least #+ and #-
around problem areas.
Part of the reason is that, even though the proposals have received endorsement
in isolation, they may be later superseded by other proposals or rescinded on
the basis of "new evidence".
What's it all mean to users of Common Lisp?
Well, of course, we hope the proposals themselves cntain useful information,
and explain why there was an issue at all, and the reasons for our choice.
If you have strong opinions about any of the proposals, make sure your X3J13
representative hears about them. If you would like some additional changes,
please give them to your X3J13 representative to submit.
∂06-Jan-88 2356 CL-Cleanup-mailer cleanup status
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 23:56:48 PST
Received: by labrea.stanford.edu; Wed, 6 Jan 88 23:56:35 PST
Received: from bhopal.lucid.com by edsel id AA00572g; Wed, 6 Jan 88 21:52:33 PST
Received: by bhopal id AA14990g; Wed, 6 Jan 88 21:54:55 PST
Date: Wed, 6 Jan 88 21:54:55 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8801070554.AA14990@bhopal.lucid.com>
To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Cc: labrea!CL-Cleanup%SAIL@labrea.stanford.edu,
labrea!MATHIS%ADA20.ISI.EDU@labrea.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 6 Jan 88 17:13 EST <880106171310.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: cleanup status
re: If we don't say this to the community, who can?
The validation committee.
There seem to be two choices here:
-- restrict information as to how the cleanup is going, as a means of
exerting authority over the vendors (whom you say you don't trust).
-- disseminate information so that cooperative vendors, who are continuing
their individual development plans anyway, can act accordingly.
Scott and I favor the latter approach; and I'd just as soon leave the
policing of vendors up to another authority [maybe even the marketplace?].
I suggest you take your concerns to the validation committee. Maybe that
will resurrect it from it's current death-like status.
-- JonL --
∂06-Jan-88 2358 CL-Cleanup-mailer cleanup status
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 23:58:10 PST
Received: by labrea.stanford.edu; Wed, 6 Jan 88 23:57:57 PST
Received: from bhopal.lucid.com by edsel id AA00588g; Wed, 6 Jan 88 21:57:35 PST
Received: by bhopal id AA15006g; Wed, 6 Jan 88 21:59:58 PST
Date: Wed, 6 Jan 88 21:59:58 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8801070559.AA15006@bhopal.lucid.com>
To: labrea!Fahlman%C.CS.CMU.EDU@labrea.stanford.edu
Cc: labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Wed, 6 Jan 1988 21:04 EST <FAHLMAN.12364568696.BABYL@C.CS.CMU.EDU>
Subject: cleanup status
re: Well, maybe there is some middle ground between chaos and living with
CLtL, as is, for two or three more galactic rotations. If those are the
only two choices, I'll take chaos.
Hmmm, there's one viewpoint that says "Lots of CLtL *is* chaos". In fact,
isn't that why this committee exists in the first place? to "clean up"
the chaos?
-- JonL --
∂07-Jan-88 0026 CL-Cleanup-mailer your proposed revision
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Jan 88 00:26:42 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 316777; Thu 7-Jan-88 03:26:13 EST
Date: Thu, 7 Jan 88 03:25 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: your proposed revision
To: Masinter.PARC@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880106-232940-6463@Xerox>
Message-ID: <880107032551.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
This looks better, and maybe it's the best I can hope for within this group,
which apparently largely disagrees with me.
But for the record, I'm absolutely not happy with any recommendation that
people run out and implement any of this unless we name the subsets which we
are encouraging them to implement in some way that does not change daily.
If it does turn out that we change any of these, we may end up feeling guilty
for having encouraged people to adopt what even now seem like compatible
changes because in the future we will have to consider any further change as
not only potentially in conflict with CLtL but also potentially in conflict
with the supposedly non-binding changes we announced earlier and strongly
encouraged people to rush out and implement.
Moreoever, even what seems like a compatible change will cause headache for
people who learn to depend on the new feature and then port to a CL that
doesn't have it. Since I myself am involved in the maintenance of a Lisp,
and since I'm very conservative about what goes into that Lisp, I will be
unhappy if our users come complaining to me that other lisps support one
of these extensions (with no official status) and claims that it is my Lisp
which is faulty for not providing it. I think it is unfair of this committee
to put me in such a position and I think that's exactly what you are doing.
I will be in a damned-if-i-do and damned-if-i-don't position if you make
these changes non-binding while still urging everyone to rush out and
implement them. I would rather see you simply observe that it is possible
to make some extensions now if they want, but not do any form of encouraging
or urging. Even an explicit plug for implementors who want to maintain
the status quo would be in order in my opinion.
In any case, I think that explicit wording should be given in your message
saying that even if they provide these proposed changes, they should document
them as deviations from the standard. Your remarks about "proposed changes
likely to..." are not clear about whether this is a phrase they should
say to themselves to keep their conscience clean or to their customers for
the sake of truth in advertising. I think both, but I can see some people
preferring to do only the former.
Mostly, I feel like I am saying the same thing over and over and getting
nowhere. I think you understand my position, so if I haven't convinced you
of its importance either to me personally, to me as an implementor, or to
the community at large, perhaps it is about time for me to give up and be
silent. Just didn't want anyone to construe that silence as some form of
consent...
∂07-Jan-88 0555 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 7 Jan 88 05:55:26 PST
Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 156925; Thu 7-Jan-88 08:55:37 EST
Date: Thu, 7 Jan 88 08:55 EST
From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8801070426.AA14597@bhopal.lucid.com>
Message-ID: <19880107135530.3.HORNIG@WINTER.SCRC.Symbolics.COM>
Date: Wed, 6 Jan 88 20:26:00 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
I welcome this proposal wholeheartedly -- it irons out another of those
brainos for which no one can now even remember a decent rationale.
However, there is one point I'd like to see pressed further. You propose:
The scope of a `normal' declaration is exactly the scope of the
associated lexical variable or function. . . .
SPECIAL declarations may be either `normal', affecting both a binding
and references, or `free', affecting only references. TYPE and IGNORE
declarations may only be `normal'. (There has been some discussion in
X3J13 of permitting `free' TYPE declarations.)
I think it is very shortsighted to limit the TYPE and IGNORE declarations
this way. In so far as IGNORE is merely advice to the compiler to stop
issuing worthless "bound, but unreferenced" warning messages, there is
no incompatiblity with it being in a LOCALLY form; it just means inhibit
warning messages for instances found in this lexical range.
....
This particular problem may be more than you wanted to bite off; if so,
maybe I'll be able to find the time to submit a separate proposal on it.
But since you've taken the plunge already on declaration scoping (and
since I've been so busy with product deadlines etc.) I thought you may
want to field the whole matter.
My intention was only to restate what was already in CLtL. I would be
happy to see a proposal to permit `free' TYPE declarations. I am trying
not to let the DECLARATION-SCOPING proposal get side-tracked again
trying to become a "fix all bugs with declarations" proposal.
∂07-Jan-88 1224 CL-Cleanup-mailer your proposed revision
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 7 Jan 88 12:24:00 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 7 Jan 88 15:23:37 EST
Received: by kali.think.com; Thu, 7 Jan 88 15:23:33 EST
Date: Thu, 7 Jan 88 15:23:33 EST
From: gls@Think.COM
Message-Id: <8801072023.AA02073@kali.think.com>
To: Masinter.PARC@xerox.com, KMP@stony-brook.scrc.symbolics.com,
CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 7 Jan 88 03:25 EST <880107032551.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: your proposed revision
I think Larry has done a very good job on the latest draft. However,
I must agree with KMP on one point. In our capacity as members of X3J13,
I don't think it is wise to encourage anyone to depend on any action
of X3J13 except for a draft explicitly voted out for public examination.
To do otherwise could conceivably put us in a position of liability.
The minutes of our meetings and the records of our votes are available,
and anyone can get them and choose whether or not to track our progress.
It is not our place, however, to encourage (or discourage) someone in this.
--Guy
∂11-Jan-88 1150 CL-Cleanup-mailer paper for IWoLES
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 88 11:49:56 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 88 11:50:13 PST
Date: 11 Jan 88 11:47 PST
From: Masinter.pa@Xerox.COM
Subject: paper for IWoLES
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880111-115013-4302@Xerox>
I've committed to producing a paper for IWoLES (International Workshop on LISP
Evolution and Standardization) next month. I took my draft letter to Common Lisp
and a few other things and tried to turn it into a paper.
I need to send this off right away, but I thought, since it purports to speak
for the cleanup process as a whole, I should run it by you.
\documentstyle{article}
\title{Common Lisp Cleanup}
\author{Larry Masinter}
\date{10 January 1988}
\evensidemargin=0cm
\oddsidemargin=0cm
\topmargin=0cm
\textheight=22.5cm
\textwidth=16.5cm
\columnwidth=\textwidth
\begin{document}
\maketitle
This paper describes some of the activities of the ``cleanup'' sub-committee of
the ANSI X3J13 group. It describes some fundamental assumptions of our work in
this sub-committee, the process we use to consider changes, and a sampler of
some of the changes we are considering.
\section{Assumptions.}
We believed the only reasonable way to obtain a standard for Lisp was to start
with a known, widely implemented description, namely ``Common Lisp the
Language'' by Guy L. Steele Jr. ({\em CLtL}) and to consider individually
various clarifications, changes, additions, enhancements, modifications.
Common Lisp ``works''. It is widely implemented. Common Lisp has a relatively
small kernel of semantics, facilities for extensions, and a large library of
data types and operations on them. It is a good starting point for a Lisp
standard. We do not believe that it is necessary to start over to design a good
Lisp standard. Even if one favors modifications to the fundamentals of the
language semantics (e.g., function and variable name scoping), most of the
library of data types and operations of Common Lisp will continue to form a good
basis for applications and it is valuable to clarify the operation of the
library.
There are three kinds of problems with CLtL we would like to resolve in creating
a standard.
First, CLtL had its roots in a user's level description of a programming system;
although it is wonderfully specific as user manuals go, there are numerous
places that allow more implementation flexibility than is desirable in a
standard. In a standard, we would expect that ambiguities to be either
eliminated or else {em explicitly} allowed.
Secondly, CLtL was written and published without extensive prior use of some of
its features; a few have turned out to be unworkable or useless and not
implemented. We hope to change or remove those features.
Third, we've discovered that there are features that exist in nearly in every
implementation but with different names and calling conventions or (in a very
few instances) are logical extensions of the current specification. We would
like to augment the standard by providing access from the standard language to
those features.
\section {The process.}
The cleanup subcommittee considers those minor changes that are not being
addressed by any of the other single-topic subcommittees of X3J13 (objects,
windows and graphics, characters, iteration, compilation, validation, and a few
others.)
We consider proposals both internally generated by members of the cleanup
committee or are received from members of the community.
Almost all work of the committee is handled via electronic mail. We rarely meet
as a group in person. Most decisions are made by consensus. When we cannot agree
by consensus whether to endorse a proposal, we may present it to X3J13 for
voting with the various points of view represented in the writeup; we believe
our responsibility is to fully describe the issues, and allow the larger
community to vote.
We attempt to analyze the costs and benefits for each proposed modification.
Each proposal, considered individually, must make the language better--enough
better to be worth the cost of making a change. To this end, we require that
each proposal be accompanied by an analysis of the various costs and benefits.
Of course, there are conflicts in the interpretation of costs and benefits.
There are some general principles of good programming language design: programs
should be easy to read; programs should be easy to write; the language should
allow users to write efficient prgrams. These goals sometimes work against each
other: for example, adding features makes the job easier for the program writer,
but harder for the reader. These conflicts in desired make the design process
difficult, because it is not possible to optimize all of the design goals
simultaneously.
The process of explicitly addressing costs and benefits has successfully
eliminated arguments based merely on personal preference. Most often, what
initially seems like a matter of taste in fact has roots in a more explicit
judgment of benefit over cost. By adopting an explicit format for those items,
we've managed to expose the underlying principles.
We only consider ``complete'' proposals. While we've discussed some open
problems, we generally avoid ``design by committee.'' Rather, after some initial
discussion, a single individual will produce a proposal.
\subsection {Elements of a proposal.}
These are the important elements of the ``cleanup'' proposals we develop:
\paragraph {Category.}
We attempt to distinguish between a clarification (proposal to resolve an
ambiguity or case of under-specified situation in CLtL), a change (proposal to
make an incompatible change to the language), and an addition (proposal to add
an upward compatible feature.) The category of a proposal will likely dictate
what a responsible implementor of Common Lisp would do prior to the acceptance
of a new draft standard; e.g., clarifications can be adopted immediately, while
incompatible changes might wait until there is an official standard or be
implemented in a separate "package", at which time incompatible changes can be
adopted all at once.
\paragraph {Problem Description.}
Suprisingly, requiring an explicit description of the problem, indpendent of
some design for its solution, has been most helpful in avoiding unnecessary
changes to the language. Why does anything need to happen at all? (``If it
ain't broke, don't fix it.'')
\paragraph {Proposal.}
We expect proposals to separate out the description of the proposal from the
arguments for it. Again, this simple measure helps lend a great deal of
objectivity to the process. While our proposals are expected to be precise and
accompanied by test cases and examples, we generally look to the editor and
editorial committee of X3J13 to actually produce the specification that reflects
the proposal.
\paragraph {Current practice.}
What do current Common Lisp implementations do? Current implementations (at
least implementation that attempt to be faithful to CLtL) often give us good
indication of what implementors believed CLtL to mean. We put some faith that
they attempted a reasonable interpretation. In cases where no implementation
exactly matches CLtL, this is a good indication that CLtL's description is
flawed.
\paragraph {Costs.}
Every change or resolution costs something to adopt: to implementors (What does
it take to change a non-conforming implementation to a conforming one? Does this
affect some, one, many functions? Is public-domain code available?), and to
current users (to convert existing user code or tools.) We hope to give a
measure of whether the changes required for each are small or large. In general,
we take cost to users more seriously than cost to implementors.
\paragraph {Benefits.}
Benefits are diverse: our goals are to improve the portability of the language,
its performance, the cleanliness of its semantics, and its aesthetics. Our major
concern is with allowing important applications of Common Lisp to work well
across many different implementations.
\section {Open issues.}
\renewcommand{\descriptionlabel}[1]{\hspace\labelsep $\bullet$ }
This section lists most of the proposals currently being considered, in an
extremely abbreviated form. Many of these issues have {\em not} been adopted and
many {\em will not be}; they are listed here to give an idea of the kinds of
issues the cleanup committee is currently addressing. New issues--especially
that has affected the portability of any current program--are welcome.
{\em Reminder: these proposals have not been accepted; they are not part of any
standard. This is a list of issues considered, not of issues passed. While some
have been endorsed by X3J13, others are likely to be rejected.}
\paragraph {Clarifications.}
These are cases where CLtL does not specify behavior; usually these are also
cases where implementations actually differ and users have found code
non-portable.
\begin{description}
\item[append-dotted] \verb|(APPEND '(A . B) '(E F))| is not an error, returns
\verb|(A E F)|.
\item[colon-number] \verb|:123| is an error and not a keyword symbol.
\item[declaration-scope] Specify more precisely the scope of declarations.
\item[compiler-warning-break] \verb|*BREAK-ON-WARNINGS*| applies to compiler
warnings too.
\item[flet-implicit-block] The bodies of functions defined in \verb|FLET|,
\verb|MACROLET| and \verb|LABELS| have implicit \verb|BLOCK|s wrapped around
them in the same manner as \verb|DEFUN| and \verb|DEFMACRO| bodies.
\item[defvar-documentation] In \verb|(DEFVAR x y documentation)|, documentation
is not evaluated.
\item[defvar-initialization] In \verb|(DEFVAR x y)|, y is evaluated when
\verb|DEFVAR| is.
\item[pathname-stream] Pathnames can be obtained only from streams opened with
pathnames (or synonym streams.
\item[push-evaluation-order] \verb|(PUSH (A) (CAR (B)))| evaluates\verb|(A)|
before \verb|(B)|.
\item[remf-destruction-unspecified] What side effects are allowed/possible by
REMF, NREVERSE etc.?
\item[setf-method-for-symbols] Examples in CLtL of \verb|SETF|-method for
symbols and \verb|LDB| are inconsistent with left-to-right evaluation order.
Change them.
\item[shadow-already-present] What does SHADOW do if symbol is already there?
\item[sharpsign-plus-minus-package] Elements of \verb|*FEATURES*| are in the
keyword package.
\item[sharpsign-plus-minus-number] Numeric \verb|*FEATURES*| are not allowed.
\item[unwind-protect-non-local-exit] Exit from cleanup clause of
\verb|UNWIND-PROTECT| overrides any unwind in progress.
\item[adjust-array-displacement] More precise rules for interaction of
\verb|ADJUST-ARRAY| and displaced arrays.
\item[do-symbols-duplicates] Can \verb|DO-SYMBOLS| visit a symbol more than
once?
\item[format-uparrow-scope] What is the scope of \verb|~↑| in \verb|FORMAT|
loops?
\item[function-argument-type-semantics] What are the semantics of argument types
in \verb|FUNCTION| declarations?
\item[lisp-symbol-redefinition] It is illegal (non-portable) to redefine or
shadow with \verb|FLET|, \verb|MACROLET|, \verb|LABELS| functions defined in
CLtL.
\item[princ-character] \verb|(PRINC #\C)| prints C.
\item[import-setf-symbol-package] \verb|IMPORT| has no effect on a symbol's home
package.
\item[format-op-c] \verb|(format t "~C" '#\C)| prints C.
\item[disassemble-side-effect] \verb|DISASSEMBLE| has no side-effects.
\end {description}
\paragraph {Additions.}
These are some new features we are considering adding to Common Lisp.
\begin {description}
\item[aref-1d] Add \verb|(ROW-MAJOR-AREF X N)| to reference n-th row-major
element of an array.
\item[format-comma-interval] Add option to \verb|FORMAT| to specify intervals
other than 3 between digit delimiter character.
\item[get-setf-method-environment] Add an environment argument to
\verb|GET-SETF-METHOD|.
\item[keyword-argument-name-package] Allow arbitrary symbols as keyword-argument
tokens.
\item[sequence-functions-exclude-arrays] Allow some sequence functions to work
on multi-dimensional arrays.
\item[assoc-rassoc-if-key] Add \verb|:KEY| argument to \verb|ASSOC-IF|.
\item[reduce-argument-extraction] Add \verb|:KEY| argument to \verb|REDUCE|.
\item[setf-function-vs-macro] Allow {\tt(DEFUN (SETF FN) (VALUE ARGUMENTS ...)
...)} to define what \verb|(SETF (FN ...) value)| means.
\item[pathname-subdirectory-list] Recommend that directory component of a
pathname be a list in a hierarchical file system.
\item[format-atsign-colon] \verb|@:| and \verb|:@| are the same in format
directives.
\item[stream-class-access] Add functions for finding out stream class, accessing
parts.
\item[structure-definition-access] Add functions for getting at \verb|DEFSTRUCT|
accessor slots.
\item[trace-function-only] Enhance TRACE arguments.
\end {description}
\paragraph {Changes.}
These proposals are generally incompatible changes to the language, although in
some cases they are consistent with CLtL.
\begin {description}
\item Require \verb|STREAM|, \verb|PACKAGE|, \verb|PATHNAME|, \verb|READTABLE|,
\verb|RANDOM-STATE| be disjoint types.
\item[pathname-symbol] Symbols do not automatically coerce to pathnames, e.g.,
\verb|(LOAD 'FILE)| is not allowed.
\item[declare-macros] \verb|(LET (A B) (MY-DECLARE) ...)| Disallow macros
expanding into declarations.
\item[function-type] Change the \verb|FUNCTION| type to be distinct from any
other type, and change \verb|FUNCTIONP| to accept only \verb|FUNCTION| objects
(not symbols or lists that begin with \verb|LAMBDA|.). Require the
\verb|FUNCTION| always returns a \verb|FUNCTION| object. Disallow automatic
coercion from symbols to functions by \verb|FUNCALL|, \verb|APPLY|, etc.
\item[defmacro-body-lexical-environment] Allow \verb|DEFMACRO| and
\verb|DEFTYPE| bodies to have a lexical environment.
\end {description}
\section {Open problems.}
There are a number of areas that are currently not being addressed, either by
the cleanup committee or by other current committee's of X3J13. We would like to
see some attempts at standardizing on those areas that are most concern to users
attempting to write portable code.
One is that with the acceptance of a reasonable signal system, the hard work of
specifying the signals which may be raised by various error conditions remain.
We would like to make a part of the standard interface to functions the classes
of errors they can invoke under various circumstances.
No work is currently going on in the area of specifying reference to
multi-programming features, although many implementations of Common Lisp include
them.
There are several problems in the language specification for which we have no
good proposals. Most of these involve interactions of the many functions in the
Common Lisp library, e.g., how \verb|EQUAL| behaves on \verb|DEFSTRUCT| objects.
We believe these items need to be standardized, but have not found a reasonable
design.
\end{document}
∂14-Jan-88 2023 CL-Cleanup-mailer [Jan Zubkoff <edsel!jlz@labrea.stanford.edu>: mailings]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:23:07 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 17:49:06 PST
Date: 14 Jan 88 17:48 PST
From: Masinter.pa@Xerox.COM
Subject: [Jan Zubkoff <edsel!jlz@labrea.stanford.edu>: mailings]
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880114-174906-4688@Xerox>
I am unfortunately going to be away for two weeks starting on Monday. (Rather
suddenly.) When I get back, I will try to gather up all of the issues that are
ready for release for mailing out and do a mailing. The time will be pretty
short. I'm going to at least try to get an updated status list out before I
leave, and mark the ones that seem ripe for harvesting.
Let me urge you to try to reach some convergence on the open issues in the next
two weeks. We need to get more things behind us if we're going to have a draft
standard by the end of the year.
I know you've seen this, but ...
This is a reminder that any subcommittee papers need to be mailed by Friday 2/5
in order to reach committee members in time. That's only 3 weeks from Friday
folks...
∂14-Jan-88 2023 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:23:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 18:43:08 PST
Date: 14 Jan 88 18:42 PST
From: Masinter.pa@Xerox.COM
to: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Subject: Issue: APPEND-DOTTED (Version 5)
Message-ID: <880114-184308-4782@Xerox>
Sigh, making a status list, I come across little edits that are hard to avoid
making. This version incorporates a few typos and a report on Current Practice.
Please don't reply unless you have some objections, there'll be an opportunity
to say "OK" to the whole group.
!
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of what
happens if an argument to APPEND is a dotted list. The only case explicitly
mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any LISP
object, which becomes the tail end of the constructed list. For example, (append
'(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list to be
returned.
In the degenerate case where there is no last cons (i.e., the argument is NIL)
in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument is a
non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are the
same, since these two might legitimately differ in situations involving dotted
lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number of
implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17) => 17,
where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted list.
Xerox Common Lisp signals an error on APPEND and implements the proposed
interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those implementations
which don't already implement it. However, implementations which have microcoded
APPEND or NCONC incompatibly may find the small change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect only NIL
when SAFETY is 0. In this case, depending on implementation details, requiring
an ATOM check rather than a NULL check may slow things down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC can
therefore produce dotted lists, some readers may have (incorrectly) assumed that
APPEND and NCONC can reliably deal in general with dotted lists, something that
doesn't appear to be guaranteed by a strict reading. The proposed extension
would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the language
will depend largely on how they view the relation between lists and dotted
lists. Those who view dotted lists as a special kind of list may feel
differently than those who view lists as a special kind of dotted list.
Discussion:
The cleanup committee supports this proposal.
∂14-Jan-88 2023 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:23:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 19:46:17 PST
Date: 14 Jan 88 19:45 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARATION-SCOPE
In-reply-to: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>'s message of
Thu, 7 Jan 88 08:55 EST
To: Hornig@ALDERAAN.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880114-194617-4828@Xerox>
In order for this proposal to go out in the mailing to X3J13 committee members,
we will need a version of the proposal that reflects, either in the cost/benefit
analysis, or in the discussion, the topics mentioned in the mail so far.
If you want to separate out the issues of type declarations into a separate
proposal, then this proposal is misnamed, it probably should be
DECLARE-SPECIAL-SCOPE and you need another one that is DECLARE-TYPE-SCOPE.
Personally, I think we are close enough to attempt a comprehensive set of rules
for DECLARATION-SCOPE and that you should go for it; there's not that much time.
∂14-Jan-88 2024 CL-Cleanup-mailer Re: New issue: FLET-DECLARATIONS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:23:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 20:18:27 PST
Date: 14 Jan 88 20:17 PST
From: Masinter.pa@Xerox.COM
Subject: Re: New issue: FLET-DECLARATIONS
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Fri, 1 Jan 88 15:45 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Cl-Cleanup@SAIL.STANFORD.EDU, Hornig@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880114-201827-4858@Xerox>
I think this issue would be ready to mail out with just a few changes:
a) I think it is independent of whether DECLARE-MACROS passes. Certainly if
DECLARE-MACROS doesn't pass, it is even more important, but as written it seems
like it more intertwined.
B) It should probably reference DECLARATION-SCOPE.
c) That at least one CL implementation does this is probably support (in Current
Practice)
I support this proposal.
∂14-Jan-88 2023 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:23:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 20:04:21 PST
Date: 14 Jan 88 20:03 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
In-reply-to: Dan L. Pierson <pierson@mist.ARPA>'s message of Wed, 30 Dec 87
19:26:32 EST
To: pierson@mist.ARPA
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880114-200421-4849@Xerox>
I think we can ship a version 3 that has the [[]] remarks removed. Probably we
want to add to the Discussion section.
What do folks think about a paragraph like:
DISASSEMBLE is an environment feature; some question has been raised as to the
place and force of environment features in the standard. However, this proposal
stands if DISASSEMBLE is part of the standard language.
∂14-Jan-88 2045 CL-Cleanup-mailer Re: Issue: LAST-N (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:45:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 20:45:06 PST
Date: 14 Jan 88 20:44 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: LAST-N (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Fri, 4 Dec 87 16:49 EST
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880114-204506-4881@Xerox>
For the record, I'm opposed to this proposal. Its a random addition that I can't
imagine using more than once every 2 years.
Implementationally it turns a simple primitive LAST into a complex one. Of
course you can optimize it, but that makes the implementation even more complex.
∂14-Jan-88 2054 CL-Cleanup-mailer Re: Issue: LOAD-TIME-EVAL (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:53:54 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 20:54:32 PST
Date: 14 Jan 88 20:53 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: LOAD-TIME-EVAL (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Thu, 12 Nov 87 18:48 EST
To: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <880114-205432-4891@Xerox>
The last mail on this topic was 12 November.
Jul 23: Jim Kempf's version 2 mailed
Nov 11: mail about a few typos and bugs in it which he agreed to adopt.
Nov 12: Kent Pitman mailed version 3
Dave Moon replied.
Version 2 is incompatible with Version 3.
Do we go back to version 2 (#, as currently spec'd, allowed only within constants?)
∂14-Jan-88 2111 CL-Cleanup-mailer Issue status: READY FOR LETTER BALLOT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 21:11:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 21:12:23 PST
Date: 14 Jan 88 21:11 PST
From: Masinter.pa@Xerox.COM
Subject: Issue status: READY FOR LETTER BALLOT
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880114-211223-4922@Xerox>
Just to get them out of the other list, I've separated out into a separate
message those issues that I think are, as of today, ready for sending out in
letter ballot form; they were either endorsed by X3J13 at a previous meeting (if
it says so) or else there's been no objections to the last version mailed and
the discussion is conclusive.
New for this meeting:
- ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87)
(Interaction of ADJUST-ARRAY and displaced arrays)
- APPEND-DOTTED (Version 5, 14-Jan-88)
(What happens to CDR of last CONS? in other
than last arg?)
- ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87)
(Extend ASSOC-IF, etc. to allow :KEY)
- COMPILER-WARNING-BREAK (Version 4,23-Nov-87 )
(Does *BREAK-ON-WARNING* affect the compiler?)
- DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87)
(Documentation string is not evaluated.)
- DEFVAR-INIT-TIME (Version 2, 29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
- DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87)
( DO-SYMBOLS can the same symbol twice?)
- PATHNAME-SYMBOL (Version 3, 23-OCT-87)
(Do symbols automaticly coerce to pathnames?)
- PUSH-EVALUATION-ORDER (Version 5,25-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
- REDUCE-ARGUMENT-EXTRACTION (version 2, 30 Dec 87)
(Add :KEY to REDUCE)
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
(What does SHADOW do if symbol is already there?)
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
( *FEATURES* are in the keyword package)
Already passed:
- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed X3J13/Jun87
Version 7 passed X3j13/Nov87
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Version 1 passed X3J13/Nov87
- COMPILER-WARNING-STREAM (Version 6, 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87
- DEFVAR-INITIALIZATION (Version 4, Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
- FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
- FORMAT-ATSIGN-COLON (Version 4, 5-jun-87)
(@: == :@ in format)
Version 4 passed X3J13/Jun87.
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Version 2 passed X3J13/Nov87
- FORMAT-OP-C (Version 5, 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 passed X3J13/Nov87.
- IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Version 8 passed X3J13/Nov87
- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Version 6 passed X3J13/Nov 87
- PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
∂14-Jan-88 2116 CL-Cleanup-mailer Issue status: PENDING
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 21:16:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 21:17:18 PST
Date: 14 Jan 88 21:16 PST
From: Masinter.pa@Xerox.COM
Subject: Issue status: PENDING
To: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <880114-211718-4930@Xerox>
This is my current list of pending issues. This list is not as accurate; I've
not carefully checked it against the latest versions of all of the issue mail
files. However, I don't think I'll have a chance to do that before I leave, so
here 'tis.
I hope that some of these can be turned into final, endorsed proposals (we're
very close on a number of them) so that they can be included in the mailing for
the March meeting. Please.
In discussion.
- DECLARE-MACROS (Version 2, 9-Nov-87)
(Disallow macros expanding into declarations.)
Kent will resubmit.
- DECLARATION-SCOPE (Version 1, 5-Jan-88)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
should include INLINE, TYPE declarations
- DISASSEMBLE-SIDE-EFFECT (version 2)
(DISASSEMBLE doesn't smash the def if not compiled)
nearly ready.
- FLET-DECLARATION (Version 1, 1 Jan 88)
(Allow declarations in FLET, MACROLET)
nearly ready
- FORMAT-COLON-UPARROW-SCOPE (Version 1)
(what iteration does ~:↑ exit from?)
Common-Lisp mailing list discussion Nov 87
Nearly ready
- FUNCTION-ARGUMENT-TYPE-SEMANTICS (not yet submitted)
I'm hoping to get this one out when I get back, but I know its hopeless.
Maybe I can mail it out *not* in time for a letter ballot but
in time for discussion.
- FUNCTION-TYPE-KEY-NAME (Version 1, 1 Dec 87)
(allow type (FUNCTION (SEQUENCE FUNCTION &KEY
(:KEY FUNCTION)) SEQUENCE) )
needs minor edits as per KMP
- FUNCTION-TYPE (Version 7,8, 9-Nov-87, 14-Nov-87)
(Change definition of FUNCTIONP, function type ...)
Discussed at X3J13, new proposal due.
Not eady for release
- LOAD-TIME-EVAL (Version 3, 11-Nov-87)
(New function/macro/special form for evaluation
when compiled file is loaded?)
nearly ready for release
- PROCLAIM-LEXICAL (Version 5, 14-Nov-87)
(add LEXICAL, GLOBAL, CONSTANT proclaimation)
- REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 )
(Specification of side-effect behavior in CL)
DEFINED, VAGUE and IN-BETWEEN
Not ready for release
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4, 11-Nov-87)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Could be ready for release
- TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
? Ready for release?
- UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87)
(What happens with non-local exits out of UNWIND-PROTECT
cleanup clauses?)
Not ready for release
Need volunteer:
- ADJUST-ARRAY-FILL-POINTER
- CONSTANT-SIDE-EFFECTS (not yet submitted)
(It is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Will take on if no compiler proposal
- DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
- EQUAL-STRUCTURE (not yet submitted)
(Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.)
What do EQUAL EQUALP and friends do
on structures?
(ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu,
Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU)
- FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just
an open file-stream. Let it take a keyword argument :ELEMENT-TYPE,
defaulting to STRING-CHAR for non-stream arguments and to the
element-type of the stream for a stream argument."
Need volunteer to write up.
- FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Steele? will write up.
- FUNCTION-TYPE-REST-LIST-ELEMENT (not yet submitted)
(allow &rest <type> in function types to refer to element
type rather than list)
Disscussed at length in the past.
sandra%orion@cs.utah.edu.
- FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace etc)
Mail from Moon 6-Jun.
cf SETF-FUNCTION-VS-MACRO.
(SMH!franz@ucbarpa.berkeley.edu, JonL, RWK)
- LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
Merge with SPECIAL-FORM-SHADOW
Needs volunteer
- MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
re-extracted from ENVIRONMENT-ARGUMENTS
CLOS committee to submit?
- PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
make :DIRECTORY a list?
Need volunteer to rewrite.
- PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components, etc
in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
- REDUCE-ARGUMENT-EXTRACTION (no proposal)
Mail on COMMON-LISP about adding a new keyword argument
to REDUCE to extract the appropriate value.
- SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
- STANDARD-INPUT-INITIAL-BINDING (from ISSUES.TXT file)
(P 328) "Remove the requirement that *STANDARD-INPUT*, etc., must
be initially bound to synonym streams to *TERMINAL-IO*; demote
this to the level of an implementation suggestion. This is to
allow flexibility of implementation, for example to allow UNIX
redirection to win."
Need volunteer to submit
- STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc
were CLOS classes?
- STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Need volunteer to write up
- SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end
of the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array
out-of-bounds.)"
Need volunteer to write up
- TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
- VECTOR-PUSH-EXTEND-DEFAULT (no proposal yet)
CLtL says that vectors are extended by a "reasonable" amount. What's that?
Hold: Awaiting action from another committee.
- DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS)
(Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e.,
not a subclass.)
Useful after CLOS
- DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
Interacts with compiler proposal'
- DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DRIBBLE-TECHNIQUE (Version 1)
(editorial board remove DRIBBLE from standard language -> standard
environment)
- FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Awaiting error proposal.
- IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions
- IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Awaiting error proposal
- SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
Tabled: Awaiting new proposal.
- ADJUST-ARRAY-NOT-ADJUSTABLE (Version 1, 22-Apr-87)
(ADJUST-ARRAY on non-adjustable arrays returns copy)
extend COPY-ARRAY instead?
Tabled until resubmitted
- DEFINITION-FUNCTIONS (no formal proposal)
(Extensions for documentation-type for delete-definition
for type FUNCTION, VARIABLE, TYPE. )
Rough draft mailed 9-Oct-87.
JonL may mail something.
- EVAL-DEFEATS-LINKER (Version 1, 12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE
Wait on FUNCTION-TYPE, LOAD-TIME-EVAL
Propose #., #, changes independently.
- EXPORT-COORDINATION (no formal proposal)
Add new macros for defining, export at same time
Too many interactions with package system
- GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
- KEYWORD-KEYWORDS (version 1)
- OPEN-KEYWORDS (Version 1, 17-Jul-87)
Discussion 9-Nov-87
Questionable; needs stronger justification.
Tabled until resubmitted.
- PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal
interaction must or even ought to work."
- PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
- REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
Doesn't really solve our problems?
- SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
Table until resubmitted
∂15-Jan-88 1056 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 10:56:18 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Fri 15 Jan 88 13:49:12-EST
Date: Fri, 15 Jan 1988 13:49 EST
Message-ID: <FAHLMAN.12366848744.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
What do folks think about a paragraph like:
DISASSEMBLE is an environment feature; some question has been raised as to the
place and force of environment features in the standard. However, this proposal
stands if DISASSEMBLE is part of the standard language.
It would be cleaner to go ahead and clarify that these environment
things are mere suggestions and will not be part of the standard. But
if that can't be done in time, or if it is not within the charter of our
committee to say such a thing, then this sort of clarification seems
reasonable.
-- Scott
∂15-Jan-88 1327 CL-Cleanup-mailer New, improved FUNCTION-TYPE-KEY-NAME proposal
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jan 88 13:26:53 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA22311; Fri, 15 Jan 88 14:25:40 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA12185; Fri, 15 Jan 88 14:25:34 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8801152125.AA12185@orion.utah.edu>
Date: Fri, 15 Jan 88 14:25:32 MST
Subject: New, improved FUNCTION-TYPE-KEY-NAME proposal
To: cl-cleanup@sail.stanford.edu
Issue: FUNCTION-TYPE-KEY-NAME
References: CLtL p.47-48, 61
Category: CLARIFICATION, CHANGE
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(from comments by Kent Pitman)
Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier
uses a syntax similar to the usual lambda list syntax to specify which
types go with which lambda list variables. However, there is a problem
with &KEY lambda variables because CLtL does not specify how the types
specified in the FUNCTION declaration are matched up to either the actual
arguments passed to the function, or the lambda variables in the function
definition (since the ordering of keyword arguments is arbitrary).
Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD):
(1) Specify that the &KEY parameters in a FUNCTION type specifier lambda
list should be supplied as lists of the form (<keyword> <type>). The
<keyword> must be a valid keyword-name symbol.
(2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda
list.
Test Case:
The type of the function MAKE-LIST could be declared as:
(FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)
Rationale:
(1) This specifies a direct correspondence between the argument type and
its matching keyword. All of the information is in one place, and the user
does not have to remember (or even know) the order in which &KEY arguments
appear in the actual function definition.
(2) This is probably an oversight in the original specification.
Current practice:
Many Common Lisp implementations currently ignore FUNCTION type
declarations. The situation regarding type specifications for keyword
arguments is so ambiguous that few users attempt to use them.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier or keyword arguments
in a FUNCTION type specifier may continue to do so. This proposal should
not involve massive amounts of code to be rewritten.
Conversion Cost:
Because the current situation is so ambiguous, FUNCTION type specifiers and
particularly the specification of keyword argument types are not widely used.
However, since this is an incompatible change, it would be nice if
implementations check for, and warn about, old-style usage.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
The syntax is fairly obvious and is analogous to the (<keyword> <variable>)
lambda list syntax.
Discussion:
-------
∂15-Jan-88 1327 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jan 88 13:27:24 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA22350; Fri, 15 Jan 88 14:26:23 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA12191; Fri, 15 Jan 88 14:26:17 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8801152126.AA12191@orion.utah.edu>
Date: Fri, 15 Jan 88 14:26:15 MST
Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
To: cl-cleanup@sail.stanford.edu
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Related issues: FUNCTION-TYPE-KEY-NAME
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables. However, this is actually of limited
usefulness in the context of a declaration, where one normally wants type
information about the actual arguments which can be passed to the function
rather than the lambda variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem
that the corresponding type given in the FUNCTION declaration must also be
LIST, but since this provides no information about the actual arguments,
some users/implementors have instead adopted the convention of supplying
the type of the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the
type specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.
Test Case:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must
be LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Many Common Lisp
implementations currently ignore FUNCTION type declarations.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do
so. Probably only a small amount of code would have to be written/changed
in implementations that currently think that the type of the &REST parameter
must be LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must
be LIST will have to change their code. However, because this issue is so
unclear, the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
Ugly. Since the argument type syntax used by the FUNCTION type specifier
mirrors normal lambda-list syntax, it is confusing to make the &REST type
to refer to the types of the actual arguments rather than the type of the
matching lambda variable.
Discussion:
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:EXTEND-LIST-TYPE):
(1) Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST refers to the type of the corresponding lambda variable and must
be LIST or a subtype of LIST.
(2) Introduce a list form of the LIST type specifier, (LIST <type>). If
the type is specified, then it indicates that the list is a true list
(that is, finite and null-terminated), and that the value of each
successive CAR of the list is a member of type <type>.
Test Case:
The type of the function + would be specified as:
(FUNCTION (&REST (LIST NUMBER)) NUMBER)
Rationale:
(1) It is clear that a &REST lambda variable must be bound to a list.
Since the FUNCTION type syntax follows lambda-list syntax rather than
function call syntax, it is more consistent to make the type correspond to
the type of the lambda variable rather than that of the actual arguments.
(2) Introducing a list LIST type specifier would allow the FUNCTION type
specifier to be more useful for its intended purpose. It would also be
useful on its own. For example, a compiler may be able to optimize
calls to functions such as MAPCAR that operate on successive elements of
a list if information is available about the type of items in the list.
The motivation for making this part of the standard is that the syntax
of the LIST type cannot cannot be extended by user code. The motivation
for making (LIST <type>) specify a true list is that leaving the issue
unresolved would probably introduce more problems than it solves; see
also the discussion under "esthetics" below.
Current practice:
There does not appear to be any concensus on this issue. Many Common Lisp
implementations currently ignore FUNCTION type declarations.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to
do so. It should be a fairly straightforward to implement the list
form of the LIST type specifiers.
Cost to Users:
Users who have been using the convention that the &REST type parameter
specifies the type of the actual arguments will have to change their code.
However, because this issue is so unclear, the FUNCTION type specifier is
probably not used very much.
Since there is no list form of the LIST type specifier defined now, adding
it should not affect user code. The semantics of the non-list form remain
unchanged.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
Since the argument type syntax used by the FUNCTION type specifier mirrors
normal lambda-list syntax, it would be cleaner and less confusing to provide
the type of the lambda variable rather than the type of the actual arguments.
On the issue of why (LIST <type>) should imply a true list, the notion
of a list of <type> implies a certain bias or asymmetry in the list
structure: the CARs of each cons contain an element of type <type> and
the CDRs contain a link to the next cons. Moreover, in most
applications of the extended form of the LIST type specifier, one would
almost certainly want to use it to specify a true list. (For example,
CLtL routinely uses the term ``list'' to mean ``true list'', and states
that it is an error to pass a dotted list to a function where the
corresponding argument is described as a list.)
If there is a need to specify the component types of lists being used as
trees, it would probably make more sense to define a list form of the
CONS type specifier that allows the types of both the CAR and CDR to be
supplied.
Discussion:
-------
∂15-Jan-88 1450 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jan 88 14:49:59 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JAN 88 14:48:47 PST
Date: 15 Jan 88 14:48 PST
From: Masinter.pa@Xerox.COM
Subject: Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Fri, 15
Jan 88 14:26:15 MST
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880115-144847-6100@Xerox>
I don't think we can release a proposal with two choices. This issue is not
important enough for us to debate two choices before X3J13.
I propose a majority vote of the individuals who care to vote in response to
this message.
For the record, my vote is USE-ACTUAL-ARGUMENT-TYPE; the simplicity of the
declarations and the ugliness of the alternative, as well as the weight of
current practice, argue for it.
∂15-Jan-88 1511 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jan 88 14:49:59 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JAN 88 14:48:47 PST
Date: 15 Jan 88 14:48 PST
From: Masinter.pa@Xerox.COM
Subject: Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Fri, 15
Jan 88 14:26:15 MST
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880115-144847-6100@Xerox>
I don't think we can release a proposal with two choices. This issue is not
important enough for us to debate two choices before X3J13.
I propose a majority vote of the individuals who care to vote in response to
this message.
For the record, my vote is USE-ACTUAL-ARGUMENT-TYPE; the simplicity of the
declarations and the ugliness of the alternative, as well as the weight of
current practice, argue for it.
∂15-Jan-88 1516 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 15:15:52 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Fri 15 Jan 88 18:15:45-EST
Date: Fri, 15 Jan 1988 18:15 EST
Message-ID: <FAHLMAN.12366897279.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
In-reply-to: Msg of 15 Jan 1988 16:26-EST from sandra%orion at cs.utah.edu (Sandra J Loosemore)
I think we should go with USE-ACTUAL-ARGUMENT-TYPE as the sole proposed
option. Earlier I argued against this, but as I said in a previous
message, I found Moon's arguments on this issue to be persuasive: we can
consider the types specified in the FUNCTION specifier to be the types
of the arguments rather than the types of the parameters as seen on the
receiving end. In fact, given this shift in viewpoint, I no longer
consider this option to be ugly. I'd change the comment in the
aesthetics section from "Ugly." to "Some may consider this ugly." and
point out the alternative way of looking at this.
-- Scott
∂15-Jan-88 1724 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jan 88 14:49:59 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JAN 88 14:48:47 PST
Date: 15 Jan 88 14:48 PST
From: Masinter.pa@Xerox.COM
Subject: Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Fri, 15
Jan 88 14:26:15 MST
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880115-144847-6100@Xerox>
I don't think we can release a proposal with two choices. This issue is not
important enough for us to debate two choices before X3J13.
I propose a majority vote of the individuals who care to vote in response to
this message.
For the record, my vote is USE-ACTUAL-ARGUMENT-TYPE; the simplicity of the
declarations and the ugliness of the alternative, as well as the weight of
current practice, argue for it.
∂15-Jan-88 1724 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 15:15:52 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Fri 15 Jan 88 18:15:45-EST
Date: Fri, 15 Jan 1988 18:15 EST
Message-ID: <FAHLMAN.12366897279.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
In-reply-to: Msg of 15 Jan 1988 16:26-EST from sandra%orion at cs.utah.edu (Sandra J Loosemore)
I think we should go with USE-ACTUAL-ARGUMENT-TYPE as the sole proposed
option. Earlier I argued against this, but as I said in a previous
message, I found Moon's arguments on this issue to be persuasive: we can
consider the types specified in the FUNCTION specifier to be the types
of the arguments rather than the types of the parameters as seen on the
receiving end. In fact, given this shift in viewpoint, I no longer
consider this option to be ugly. I'd change the comment in the
aesthetics section from "Ugly." to "Some may consider this ugly." and
point out the alternative way of looking at this.
-- Scott
∂15-Jan-88 1741 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jan 88 17:41:01 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA27567; Fri, 15 Jan 88 16:57:17 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA12554; Fri, 15 Jan 88 16:57:12 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8801152357.AA12554@orion.utah.edu>
Date: Fri, 15 Jan 88 16:57:09 MST
Subject: Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>, Fri, 15 Jan 1988 18:15 EST
As I'm not on the cl-cleanup mailing list, I think I may have missed out
on some of the discussion relating to FUNCTION declaration semantics.
If there is now a concensus that FUNCTION declarations describe calls to
the function and not the function itself, I agree that the
USE-ACTUAL-ARGUMENT-TYPE option is not really as "ugly" as it would be
otherwise, and it's certainly simpler than the alternative.
Perhaps someone who is actually on the cleanup committee should "adopt"
this proposal at this point, and do whatever needs to be done to it to
get it to the point where you all think it's ready to be voted on? I
volunteered to write it up, not make it into a life-long crusade....
-Sandra
-------
∂18-Jan-88 1618 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 18 Jan 88 16:18:36 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Mon, 18 Jan 88 16:47:00 EST
Received: by kali.think.com; Mon, 18 Jan 88 16:46:55 EST
Date: Mon, 18 Jan 88 16:46:55 EST
From: gls@Think.COM
Message-Id: <8801182146.AA14007@kali.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 2)
Issue: FORMAT-COLON-UPARROW-SCOPE
References: CLtL p. 406 and also p. 403
Category: CLARIFICATION
Edit history: version 1: Guy Steele, 30 November 1987
version 2: Guy Steele, 18 January 1988
Problem description:
Implementations currently differ on the question of what is tested by the
FORMAT command "~:↑". Some implementations test to see whether any
arguments remain in the sublist for the current iteration step; others test
to see whether any sublists remain. The text on page 406 is not clear
on this point. The two behaviors are presented below as two proposals.
Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{.
The entire iteration process is terminated if and only if the sublist
that is supplying the arguments for the current iteration step is the
last sublist (in the case of ~:{) or the last FORMAT argument (~:@{).
Note that ~:↑ is *not* equivalent to ~:#↑; the latter terminates the
entire iteration if and only if no arguments remain for the current
iteration step.
Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{.
The entire iteration process is terminated if and only if no more arguments
remain for the current iteration step. Thus ~:↑ is equivalent to ~:#↑,
just as ~↑ is equivalent to ~#↑.
Test Cases/Examples:
(format nil "~:{~@?~:↑...~}" '(("a") ("b")))
Under proposal FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS
this yields "a...b".
Under proposal FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS
this yields "a".
Rationale:
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS is desirable
because otherwise there is no way to test whether any sublists remain.
The text on page 406 may be construed to hint at this proposal
indirectly. To quote Nick Gall:
If one thinks about the intent of the parenthetical
(because in the standard case it tests for remaining arguments of
the current step only)
one should agree that "a...b" will be returned. In referring to ~↑ as
the "standard case", which tests the arguments remaining in the
current argument sublist, this parenthetical implies that there is
an `other case', which tests `something else.' The only `other case'
discussed is ~:↑, which therefore must test `something else.' I claim
that the parentheical makes no sense if we interpret ~:↑ as testing
the same condition as ~↑. If they both test the same condition, why
have the parenthetical explanation?
If ~:↑ doesn't test the same condition as ~↑, then what does it test?
I claim that the only test that makes sense is for ~:↑ to test the
only thing that affects the "entire iteration process:" the number of
sublists. When there are no more sublists, "the entire iteration
process" is terminated.
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS is desirable
only because it maintains the equivalence of ~:#↑ and ~:↑ and because
some implementations have been produced that take this approach.
Current practice:
Implementations using FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS
include Symbolics Common Lisp and TI Lisp.
Implementations using FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS
include Kyoto Common Lisp, Allegro Common Lisp, GCLISP, and VAXLISP.
Cost to Implementors:
One or the other batch of implementors will have to make a small change,
probably a one-liner.
Cost to Users:
It is unlikely that much user code depends on the behavior
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS, but it is
possible. The author of this writeup (Steele) judges it somewhat more
likely that user code might depend on the behavior
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Cost of non-adoption:
Users would have to be warned not to use ~:↑ in code that is meant to be
portable.
Benefits:
Elimination of yet one more ambiguity.
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS allows greater
semantic power (there are more things one can test).
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS maintains an
elegant but useless symmetry.
Esthetics:
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr.
Discussion:
Guy Steele very strongly prefers the interpretation
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
David Moon, Kent Pitman, Pavel Curtis, Dan Pierson, Rob Poor, and Nick Gall
favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Kevin Layer and Rich Robbins have spoken in favor of
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS.
Historical note: Steele first implemented this "feature", in Zetalisp, and
so the code in Symbolics Common Lisp is likely a direct descendant of the
original code. This might cause some to give weight to Steele's opinion.
There are two arguments against such credence. First, there is no reason
why the original code should be regarded as part of the specification of
Common Lisp any more than any other implementation; plainly, Steele botched
the specification when he wrote the book. Second, a professor of
literature (I believe) once told Isaac Asimov concerning a short story of
his (I quote from memory): "Tell me, Dr. Asimov, just because you wrote the
story, what makes you think you know what it means?"
∂18-Jan-88 1831 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 2)
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 18:31:24 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Mon 18 Jan 88 21:31:19-EST
Date: Mon, 18 Jan 1988 21:31 EST
Message-ID: <FAHLMAN.12367719313.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 2)
In-reply-to: Msg of 18 Jan 1988 16:46-EST from gls at Think.COM
CMU Common Lisp (known as Spice Lisp in spicier days) seems to implement
TEST-FOR-REMAINING-ARGUMENTS. Some other implementations may have taken
their cue from us.
Nevertheless, following the herd, I favor TEST-FOR-REMAINING-SUBLISTS.
-- Scott
∂19-Jan-88 1539 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 19 Jan 88 15:38:50 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA02319; Tue, 19 Jan 88 18:38:04 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA20676; Tue, 19 Jan 88 18:39:06 EST
Message-Id: <8801192339.AA20676@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Cc: franz!smh%berkeley.edu@multimax
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
Date: Tue, 19 Jan 88 18:39:04 EST
From: Dan L. Pierson <pierson@mist>
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Status: For Internal Discussion
Problem description:
CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*. This requirement
hampers the integration of Common Lisp with operating systems such as
Unix which support input-output redirection.
Proposal (STANDARD-INPUT-INITIAL-BINDING:TERMINAL-IO-OPTIONAL):
The initial bindings of *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, *DEBUG-IO*, and
*TERMINAL-IO* are undefined. Implementors are encouraged to make them
all refer to the user's console (possibly via *TERMINAL-IO*) if it
makes sense in the current invocation of Common Lisp.
Test Cases/Examples:
A Unix implementation is currently unable to legally support standard
error output even though Common Lisp defines *ERROR-OUTPUT* because
*ERROR-OUTPUT* is required to start out bound to the same stream as
*STANDARD-OUTPUT*.
A workstation environnment which provides stream access to windows as
an extension is currently forbidden to make trace output appear in a
separate window by default.
Rationale:
The language is CLtL prevents implementations from doing sensible
things.
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.
Cost to Implementors:
None required, implementors would be given more freedom to tailor
their implementations to the target harware and operating system.
Cost to Users:
No direct costs because this proposal doesn't require any
implementation to change.
Cost of non-Adoption:
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations.
Aesthetics:
While the aesthetics of the language won't change much, the aesthetics
of environments would be allowed to improve.
Discussion:
This proposal carefully tries not to answer questions like the
following: When is and isn't real access to the terminal via
*TERMINAL-IO* desired? It certainly isn't for batch programs. For
Unix which of different std{in,out,err} is *TERMINAL-IO* bound to?
The KCL binding of *TERMINAL-IO* is a stream with no associated
pathname(s). CLtL makes this more likely than not, which is not a
good thing in the Unix environment. Do we need another proposal to
determine stream types and access components of two-way streams? Does
STREAM-CLASS-ACCESS cover this area?
∂21-Jan-88 0802 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 21 Jan 88 08:02:26 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA24101; Thu, 21 Jan 88 11:02:59 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA26178; Thu, 21 Jan 88 11:04:05 EST
Message-Id: <8801211604.AA26178@mist.UUCP>
To: Masinter.pa%Xerox.COM@multimax
Cc: sandra%orion%cs.utah.edu@multimax, cl-cleanup%sail.stanford.edu@multimax
Subject: Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
In-Reply-To: Your message of 15 Jan 88 14:48:00 -0800.
<880115-144847-6100@Xerox>
Date: Thu, 21 Jan 88 11:04:02 EST
From: Dan L. Pierson <pierson@mist>
My vote is for USE-ACTUAL-ARGUMENT-TYPE for &rest args in function
specs. It may or may not damage the pure aesthetics of the language,
but, since the resulting code is easier to read and write, it seems
like an aesthetic improvement to me.
I would like to see a separate proposal for a parameterized LIST type
specifier; I think that it would be useful outside function specs.
∂21-Jan-88 0810 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 21 Jan 88 08:09:57 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA24169; Thu, 21 Jan 88 11:10:10 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA26219; Thu, 21 Jan 88 11:11:16 EST
Message-Id: <8801211611.AA26219@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
Date: Thu, 21 Jan 88 11:11:14 EST
From: Dan L. Pierson <pierson@mist>
Issue: DISASSEMBLE-SIDE-EFFECT
References: DISASSEMBLE (p. 439), COMPILE (p. 439)
Category: CLARIFICATION
Edit history: Version 2 by Pierson 12/30/87
Version 3 by Pierson 1/21/88
Status: Ready For Release?
Problem description:
The definition of DISASSEMBLE says that "if the relevant function is
not a compiled function, it is first compiled.". The definition of
COMPILE says that "If name is a non-nil symbol, then the
compiled-function is installed as the global function definition of
the symbol...". Several implementations have taken this to mean that
if DISASSEMBLE is passed a symbol which has an uncompiled function
definition, then it has the side-effect of (COMPILE 'symbol).
Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL):
Clarify that when DISASSEMBLE compiles a function, it will never
install the newly compiled function.
Test Cases/Examples:
(DEFUN F (A) (1+ A))
(EQ (SYMBOL-FUNCTION 'F)
(PROGN (DISASSEMBLE 'F)
(SYMBOL-FUNCTION 'F)))
This code will return T if this proposal is adopted. Some current
implementations will return T, some will return NIL.
Rationale:
Several current implementations of DISASSEMBLE have surprising side
effects, especially for new users.
Current practice:
Allegro CL and Vax Lisp install the compiled definition. Lucid,
Symbolics, Xerox, and KCL don't install it.
Cost to Implementors:
Some implementations will have to make a simple change.
Cost to Users:
Very little. DISASSEMBLE is really part of the environment and is
probably not called by much, if any user code.
Cost of non-Adoption:
DISASSEMBLE will continue to surprise less experienced users.
Benefits:
DISASSEMBLE will become the predictable debugging function it was
meant to be.
Aesthetics:
Some who worried that DISASSEMBLE was supposed to install the compiled
function may find that the language has become a little cleaner.
Discussion:
DISASSEMBLE is an environment feature; some question has been raised
as to the place and force of environment features in the standard.
However, this proposal stands if DISASSEMBLE is part of the standard
language.
∂26-Jan-88 1244 CL-Cleanup-mailer Issue: REMF-MULTIPLE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Jan 88 12:44:38 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 328834; Tue 26-Jan-88 15:44:51 EST
Date: Tue, 26 Jan 88 15:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-MULTIPLE
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880126154442.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: REMF-MULTIPLE
References: REMPROP (p166), REMF (p167)
Category: CLARIFICATION
Edit history: 26-Jan-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The descriptions of REMF and REMPROP are not explicit about what happens in
the case that a duplicated indicator occurs on the plist. One or both indicators
might be removed.
Proposal (REMF-MULITPLE:REMOVE-ONE):
Clarify that REMF and REMPROP at most one indicator/value pair from the designated plist.
Rationale:
In a property list maintained by the normal property list operations, there will
only be one property by each name. This approach won't waste time trying to remove
other properties which are not present in the first place.
Proposal (REMF-MULTIPLE:REMOVE-ALL):
Clarify that REMF and REMPROP remove all matching indicator/value pairs from the
designated plist.
Rationale:
In a property list maintained by other operations than the standard ones,
this might be useful. Also, since the return value of REMF and REMPROP is
not well-defined, iterating to remove more than one property is expensive
because you have to start over from the head of the list.
Test Case:
;; Case #1 - removing symbol properties,etc. using REMPROP
(DEFUN REMF-MULTIPLE-TEST-1 ()
(LET ((SYMBOL (GENSYM)))
(SETF (SYMBOL-PLIST SYMBOL) (LIST 'A 'B 'C 'D 'A 'B 'C 'D))
(FORMAT T "~&Before: ~S~%" (SYMBOL-PLIST SYMBOL))
(REMPROP SYMBOL 'A)
(FORMAT T "~&After: ~S~%" (SYMBOL-PLIST SYMBOL))
(FORMAT T "~&This implementation uses REMF-MULTIPLE:~:[REMOVE-ALL~;REMOVE-ONE~] ~
for REMPROP.~%"
(GET SYMBOL 'A))))
;; Case #2 - removing keywords,etc. using REMF
(DEFUN REMF-MULTIPLE-TEST-2 ()
(LABELS ((HELPER (&REST ARGUMENTS &KEY (A 1) (B 2))
(FORMAT T "~&Helper received: ~S~%" ARGUMENTS)
(LIST A B))
(DRIVER (&REST ARGUMENTS)
(FORMAT T "~&Helper received: ~S~%" ARGUMENTS)
(SETQ ARGUMENTS (COPY-LIST ARGUMENTS))
(REMF ARGUMENTS ':A)
(APPLY #'HELPER ARGUMENTS)))
(LET ((RESULT (DRIVER :A 3 :B 4 :A 5 :B 6)))
(FORMAT T "~&Returned: ~S~%" RESULT)
(FORMAT T "~&This implementation uses REMF-MULTIPLE:~:[REMOVE-ALL~;REMOVE-ONE~] ~
for REMF.~%"
(= (CAR RESULT) 5)))))
Current Practice:
Symbolics implements REMF-MULTIPLE:REMOVE-ONE.
Cost to Implementors:
For implementations needing to change, the cost of a change is probably very
small in most cases. Implementations needing change which do REMPROP and/or REMF
in microcode might have a slightly harder time, but any change should still be
very localized.
Cost to Users:
None. Users must tread lightly on this issue right now because it is not well-defined.
Cost of Non-Adoption:
The language description would continue to be vague for no particularly good reason.
Benefits:
Users who want to use REMPROP or REMF in situations which involve lists that might
have duplicated elements would be able to do so more reliably.
Aesthetics:
There is probably no particular aesthetic reason to think one of these solutions
is better than the other, but having the issue nailed down is probably an aesthetic
improvement.
Discussion:
Pitman is agnostic on this for now. There are advantages to both.
If everybody already implements REMOVE-ONE, that would seem the way to go.
∂26-Jan-88 1307 CL-Cleanup-mailer Issue: EXPORT-IMPORT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Jan 88 13:07:09 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 328851; 26 Jan 88 16:07:13 EST
Date: Tue, 26 Jan 88 16:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXPORT-IMPORT
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880126160702.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: EXPORT-IMPORT
References: EXPORT (p186)
Category: CLARIFICATION
Edit history: 26-Jan-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The description of EXPORT in CLtL says that it makes its argument symbols
``become accessible as external symbols in PACKAGE.'' It does not specify
how much work EXPORT should be willing to go through in order to make this
happen.
Proposal (EXPORT-IMPORT:YES):
Clarify that if the symbols which are specified to EXPORT are not in
[the argument] PACKAGE then EXPORT should do an implicit IMPORT of those
symbols and then should EXPORT them.
Rationale:
In most cases where a package is going to export symbols from another
package, the idiom
(IMPORT '(symbol-a symbol-b ...)) (EXPORT '(symbol-a symbol-b ...))
must be written. Maintaining both lists consistently is more error-prone
and it would be simpler if one could just write the EXPORT call and not
worry about the import.
Proposal (EXPORT-IMPORT:NO):
Clarify that if the symbols which are specified to EXPORT are not in
[the argument] PACKAGE then EXPORT should signal a continuable error.
If continued, EXPORT should IMPORT the indicated symbols and continue.
Rationale:
The package system is very tricky and setting things up correctly is
very difficult. The programmer should be asked to be explicit about
intent so that the system can diagnose as many potential errors as possible.
Test Case:
(MAKE-PACKAGE 'EXPORT-TEST-PACKAGE :USE '())
(EXPORT '(CAR CDR CONS) (FIND-PACKAGE "EXPORT-TEST-PACKAGE"))
Current Practice:
Symbolics implements EXPORT-IMPORT:NO. (The error we signal says you can
"Proceed without any special action." which doesn't make it completely clear
that it will do the implicit import, but that's apparently what happens.)
[Pitman is pretty sure several implementations implement EXPORT-IMPORT:YES
because we get a lot of bug reports from people who seem to think this is
something guaranteed but who cannot cite a passage saying where. Hopefully
people will volunteer more cases here.]
Cost to Implementors:
Presumably this change would be very isolated and easy for implementors to make.
Cost to Users:
EXPORT-IMPORT:YES is upward-compatible, though produces diminished error checking.
A change to EXPORT-IMPORT:NO might cause some users to have to write an explicit
call to IMPORT in some package declarations. Since continuing the error mentioned
in the EXPORT-IMPORT:NO spec will produce the EXPORT-IMPORT:YES behavior, though,
the incompatibility should be easy to work around in a transition period.
Cost of Non-Adoption:
Users will continue to be frustrated by a vague description of EXPORT.
Benefits:
Users will know clearly what EXPORT does in a case which seems to come up fairly
often in practice.
Aesthetics:
There are aesthetic pluses and minuses to both approaches. The most important
thing is to get this nailed down.
Discussion:
Pitman supports EXPORT-IMPORT:NO.
∂27-Jan-88 0714 CL-Cleanup-mailer Issue: EXPORT-IMPORT
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 07:14:35 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Wed 27 Jan 88 10:14:51-EST
Date: Wed, 27 Jan 1988 10:14 EST
Message-ID: <FAHLMAN.12369955463.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: EXPORT-IMPORT
In-reply-to: Msg of 26 Jan 1988 16:07-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
CMU Common Lisp (formerly Spice Lisp) implements NO. Presumably several
derived implementations follow us in this. I don't have a strong
opinion on this, one way or the other, but the "NO" option seems less
likely to cause confusion, so I'm mildly in favor of "NO".
-- Scott
∂28-Jan-88 0424 CL-Cleanup-mailer Issue: EXPORT-IMPORT
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 04:24:17 PST
Received: by labrea.Stanford.EDU; Thu, 28 Jan 88 04:24:30 PST
Received: from bhopal.lucid.com by edsel id AA23832g; Thu, 28 Jan 88 04:14:23 PST
Received: by bhopal id AA03482g; Thu, 28 Jan 88 04:18:15 PST
Date: Thu, 28 Jan 88 04:18:15 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8801281218.AA03482@bhopal.lucid.com>
To: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU
Subject: Issue: EXPORT-IMPORT
Lucid Common Lisp implements NO (offering an error continuation option of
importing the unavailable symbol).
Although I'll admit that the proposal has some pragmatic merit, it hardly
seems a pressing issue. Since Kent favors NO too, then I wonder where the
interest if pushing it comes from?
-- JonL --
∂03-Feb-88 0750 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:50:47 PST
Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 165444; Wed 3-Feb-88 09:13:15 EST
Date: Wed, 3 Feb 88 09:13 EST
From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE (Version 2)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880203034640.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19880203141314.4.HORNIG@WINTER.SCRC.Symbolics.COM>
Date: Tue, 2 Feb 88 22:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
...
Here is a revision that addresses the only two suggested changes above
where it was actually possible to take any action. I'd like to see this
sent out, since I think this issue is important. I didn't check with Hornig
before rewriting his proposal, so I hope I have not done any damage to it.
I am happy with Moon's revisions.
...
∂03-Feb-88 0755 CL-Cleanup-mailer Issue: EXPORT-IMPORT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:55:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334267; Tue 2-Feb-88 20:22:39 EST
Date: Tue, 2 Feb 88 20:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXPORT-IMPORT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880126160702.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880203012230.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor EXPORT-IMPORT:NO. I don't know of any implementations whose
current practice is EXPORT-IMPORT:YES. I agree that it would be good to
document more explicitly than CLtL which cases are errors.
∂03-Feb-88 0755 CL-Cleanup-mailer Issue: REMF-MULTIPLE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:55:51 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334269; Tue 2-Feb-88 20:28:42 EST
Date: Tue, 2 Feb 88 20:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-MULTIPLE
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880126154442.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880203012838.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor withdrawal of the REMF-MULTIPLE issue.
Here's why: The only thing that CLtL pages 163-167 says about
duplicated indicators on plists is that there aren't any
(first line on page 164). Contrary to what I thought, it does
not even guarantee that GETF returns the first occurrence.
If we're going to extend Common Lisp to allow duplicated indicators on
plists, we should do it for all the property list functions, not
just REMF and REMPROP.
∂03-Feb-88 0756 CL-Cleanup-mailer New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:56:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334273; Tue 2-Feb-88 20:36:34 EST
Date: Tue, 2 Feb 88 20:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2)
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8801152125.AA12185@orion.utah.edu>
Message-ID: <19880203013624.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD.
However, I'd like to point out a pitfall in the syntax, which I feel
should be documented in the discussion section. It may not be evident
to a user whether the proper declaration for MAKE-LIST is
(FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)
or
(FUNCTION MAKE-LIST ((INTEGER 0) &KEY (INITIAL-ELEMENT T)) LIST)
The former is what you propose, but the latter is more analogous to regular
lambda lists. If the former is correct, it would not be valid for a
compiler to diagnose the latter as invalid (note that X3J13 accepted
KEYWORD-ARGUMENT-NAME-PACKAGE in November). I don't see any way around
this problem, as I think the former declaration, as you proposed, probably
is the more desirable choice.
Also you didn't say in your proposal whether you intend that such a
declaration, without &ALLOW-OTHER-KEYS, is also a declaration that only
the listed keywords are valid. This should be stated explicitly.
∂03-Feb-88 0757 CL-Cleanup-mailer Issue: FLET-DECLARATIONS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:56:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334282; Tue 2-Feb-88 21:04:33 EST
Date: Tue, 2 Feb 88 21:04 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLET-DECLARATIONS (Version 2)
To: Cl-Cleanup@SAIL.STANFORD.EDU
cc: Hornig@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19880101204506.6.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<880104-114503-2255@Xerox>,
<880114-201827-4858@Xerox>
Message-ID: <19880203020430.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 14 Jan 88 20:17 PST
From: Masinter.pa@Xerox.COM
I think this issue would be ready to mail out with just a few changes....
Here's the revised version, with your suggested changes. I don't think
anyone has said they don't support this, so it should be ready to mail out.
Issue: FLET-DECLARATIONS
References: FLET, LABELS, MACROLET (CLtL p.113)
X3J13 document 86-003 item 113
Cleanup issue DECLARATION-SCOPE.
Cleanup issue DECLARE-MACROS.
Category: ADDITION
Edit history: Version 1, Moon, 1 Jan 1988
Version 2, Moon, 2 Feb 1988 (edits suggested by Masinter)
Problem description:
Declarations are not allowed before the body of FLET, LABELS, and
MACROLET, even though Common Lisp allows declarations in other seemingly
analogous places, such as LET.
Proposal (FLET-DECLARATIONS:ALLOW):
Change the syntax of FLET, LABELS, and MACROLET to allow declarations
between the list of local function/macro definitions and the body forms.
The scope of such declarations in FLET and LABELS includes the bodies
of the locally defined functions, when the declarations are pervasive.
Non-pervasive declarations have no effect on those bodies, except when
LABELS includes the body in the scope of a function non-pervasively
declared. This paragraph follows directly from CLtL p.155 if the
locally defined function bodies are treated like initialization forms.
(This paragraph will be superseded by cleanup issue DECLARATION-SCOPE
if it passes.)
The scope of such declarations does not include the bodies of the
macro expander functions defined by MACROLET. This is consistent with
the existing rule that the bodies of those functions are in the global
environment, not the local lexical environment.
If cleanup issue DECLARE-MACROS is not passed, in MACROLET an
invocation of one of the macros locally defined by that MACROLET is
permitted to expand into a DECLARE.
Test Cases/Examples:
(defun example (y l)
(flet ((attach (x)
(setq l (append l (list x)))))
(declare (inline attach))
(dolist (x y)
(unless (null (cdr x))
(attach x)))
l))
(example '((a apple apricot) (b banana) (c cherry) (d) (e))
'((1) (2) (3) (4 2) (5) (6 3 2)))
=> ((1) (2) (3) (4 2) (5) (6 3 2) (a apple apricot) (b banana) (c cherry))
The above function is erroneous in current Common Lisp. With this
proposal, it would have an intuitively obvious meaning.
Rationale:
This will make the syntax of FLET and LET consistent. This will make
it possible to attach declarations to function bindings; currently only
variable bindings can have attached declarations.
Current practice:
Xerox Common Lisp implements FLET-DECLARATIONS:ALLOW.
Symbolics Common Lisp does not allow declarations in this position.
Cost to Implementors:
The compilation and interpretation of three special forms will have to
be changed, however the same techniques already developed for
declarations in LET should be applicable.
Cost to Users:
No cost since this is an upward-compatible addition.
Cost of non-adoption:
Unnecessary inconsistency in the syntax of Common Lisp.
Benefits:
There is no major benefit but the language will be more consistent.
Esthetics:
Makes the language more consistent.
Discussion:
We need to resolve this for CLOS, because CLOS introduces two new
special forms similar to FLET and LABELS and we need to make their
syntax consistent with FLET and LABELS.
∂03-Feb-88 0757 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:57:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334287; Tue 2-Feb-88 21:25:34 EST
Date: Tue, 2 Feb 88 21:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 4)
To: cl-cleanup@SAIL.STANFORD.EDU, kempf%hplabsz@hplabs.hp.com, kempf%hplabs@hplabs.hp.com
In-Reply-To: <870723-155014-1175@Xerox>,
<871111-021711-6498@Xerox>,
<880114-205432-4891@Xerox>
Message-ID: <19880203022524.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 14 Jan 88 20:53 PST
From: Masinter.pa@Xerox.COM
The last mail on this topic was 12 November.
Jul 23: Jim Kempf's version 2 mailed
Nov 11: mail about a few typos and bugs in it which he agreed to adopt.
Nov 12: Kent Pitman mailed version 3
Dave Moon replied.
Version 2 is incompatible with Version 3.
Do we go back to version 2 (#, as currently spec'd, allowed only within constants?)
Yes. Here's a version 4, which is version 2 with your suggested corrections.
I don't know if this meets Kent's requirements, since I never figured out
precisely what they were.
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category: ADDITION
Edit history: Version 2 submitted 7/17/87, James Kempf.
Version 3, Pitman, 11/12/87 (alternate direction)
Version 4, Moon, 2/1/88 (Version 2 with edits suggested by Masinter)
Problem description:
The specification of #, (load time evaluation) in Common Lisp provides
a means, during compilation, of arranging for the evaluation of a
quoted or (in some implementations) unquoted form within embedded forms
processed by the reader, when the compiled file is loaded.
Inhibition of processing when a file is loaded into the interpreter
is possible using (EVAL-WHEN (LOAD) ... ). Code which is returned
during macroexpansion, however, is not processed by the reader, so
there is no way to arrange for deferral of processing until compiled
file load time in macroexpanded code.
Proposal (LOAD-TIME-EVAL:MAKE-LOAD-TIME-EVAL):
Add the function MAKE-LOAD-TIME-EVAL:
(MAKE-LOAD-TIME-EVAL <form> <env>) => <object>
<form> is a Lisp form, <env> is an environment of the sort received
by the &ENVIRONMENT argument to a macro, and <object> is the result
of evaluating <form>.
When MAKE-LOAD-TIME-EVAL is called from the interpreter or the COMPILE
function, it simply evaluates <form> in the null lexical environment
and returns its value. When MAKE-LOAD-TIME-EVAL is called during a
file compilation, the <object> is a special object that is recognized
at load time, when it occurs inside a constant. At load time,
<form> is evaluated and its value is substituted for <object>. This
is the same mechanism that the #, reader macro uses.
MAKE-LOAD-TIME-EVAL uses its <env> argument and/or dynamic state to
determine whether it is being called during a file compilation.
Until Common Lisp is modified to specify the semantics of file compilation
more precisely, this is necessarily implementation dependent.
Example 1:
(defmacro print-software-version (&environment env)
`(quote ,(make-load-time-eval '(format T "~A~%" (software-version))
env)))
When interpreted or processed during invocation of COMPILE, this
macro prints the value of (software-version) at macro expansion
time and expands into (quote nil). When macroexpanded during a
file compilation, printing is deferred until the compiled file is
loaded, and the constant is still (quote nil).
Example 2:
(defmacro table-of-tables (&rest predicates &environment env)
`(quote ,(mapcar #'(lambda (predicate)
`(,predicate
,(make-load-time-eval
`(make-hash-table :test ',predicate)
env)))
predicates)))
(table-of-tables eql equal) expands into
(quote ((eql #<table :test eql>) (equal #<table :test equal>)))
except that when macroexpanded during a file compilation,
the tables are not created until load time. This example
shows that the <object> returned by make-load-time-eval is
recognized even when it is interior to a quoted constant.
Rationale:
Currently, there is no portable way to arrange for code returned
from a macro to defer evaluation until load time.
Current practice:
Currently, every version of Common Lisp is required to implement
compiler hooks for #, but, since this is only recognized by the
reader, there is no portable way to achieve the same effect. Users
of Portable CommonLoops are encouraged to implement something similar.
Adoption Cost:
The cost to implementors will depend on how #, is implemented.
In some implementations, the primitives for implementing
MAKE-LOAD-TIME-EVAL may already exist, in others, more substantial
changes may be required.
Cost of non-adoption:
There are numerous possible uses for this facility. Version control
and system building facilities (such as the example) and optimization
of method invocation in the Common Lisp Object System come immediately
to mind. While every implementation of Common Lisp could certainly
provide an implementation specific facility, portability would suffer.
Benefits:
Portability. May make extensions to the Common Lisp Object system
via. the metaobject protocol easier.
Conversion Cost:
Most applications developers should not see much difference.
Esthetics:
The proposal fills a hole in the spectrum of alternatives for deferring
evaluation until a compiled file is loaded. Currently, code which is
read by the reader can arrange for it to be done, as can top level code,
but embedded code cannot.
Discussion:
There is likely to be some controversy about this proposal, since
there is no universally agreed upon formal processing model for
Common Lisp, but only a set of informal rules and various implementations.
Those implementations which have the primitives available should be
able to implement MAKE-LOAD-TIME-EVAL with little change to their
kernels, those which don't may require more extensive modifications.
∂03-Feb-88 0757 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:57:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334297; Tue 2-Feb-88 22:46:51 EST
Date: Tue, 2 Feb 88 22:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE (Version 2)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Hornig@ALDERAAN.SCRC.Symbolics.COM
In-Reply-To: <880114-194617-4828@Xerox>
Message-ID: <19880203034640.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 14 Jan 88 19:45 PST
From: Masinter.pa@Xerox.COM
In order for this proposal to go out in the mailing to X3J13 committee members,
we will need a version of the proposal that reflects, either in the cost/benefit
analysis, or in the discussion, the topics mentioned in the mail so far.
In the hope of helping out, I re-read the mail on the topic. The
suggested changes were:
-- use a less judgemental term than `normal'. Suggestions were `bound'
and `binding-related'. `Bound' doesn't have quite the right connotations,
but I prefer it over `normal'.
-- change the scope of `free' declarations to be something different from
what CLtL p.155 defines to be the scope of `pervasive' declarations. There
was no coherent proposal, instead the discussion was diverted by a variety
of red herrings.
-- extend Common Lisp to allow TYPE declarations to be used `free'.
The proposal already mentions that X3J13 is discussing this. It's a
complex issue, and is concerned with semantics rather than with scoping,
so I believe it should be handled independently.
-- extend Common Lisp to allow IGNORE declarations to be used `free'.
However, no meaningful interpretation of this was proposed.
-- include a table of all existing declarations, showing whether they are
`normal' or `free'.
If you want to separate out the issues of type declarations into a separate
proposal, then this proposal is misnamed, it probably should be
DECLARE-SPECIAL-SCOPE and you need another one that is DECLARE-TYPE-SCOPE.
Free type declarations are not a scoping issue.
Personally, I think we are close enough to attempt a comprehensive set of rules
for DECLARATION-SCOPE and that you should go for it; there's not that much time.
Here is a revision that addresses the only two suggested changes above
where it was actually possible to take any action. I'd like to see this
sent out, since I think this issue is important. I didn't check with Hornig
before rewriting his proposal, so I hope I have not done any damage to it.
Issue: DECLARATION-SCOPE
References: Section 9.1 (pp. 153-157).
Cleanup issue FLET-DECLARATIONS.
Category: CHANGE
Edit history: V1: Hornig@Symbolics.COM -- 5 January 1988
Version 2, Moon, 2-Feb-1988 (edits based on discussion)
Problem description:
The description of the scope of declarations made with DECLARE is both
unclear (although unambiguous) and arguably a mistake. The issue is
whether the scope of some or all of the declarations includes code
appearing in the non-body part of the special form containing the
declaration.
Proposal DECLARATION-SCOPING:LIKE-VARIABLE:
For the purposes of this proposal, we divide all declarations introduced
with DECLARE into two classes. When a declaration of a variable appears
before the body of a special form or lambda-expression that binds that
variable, the declaration is called `bound'. All other declarations
are called `free'. This division replaces the division into pervasive,
nonpervasive, and SPECIAL declarations appearing in CLtL.
The scope of a `bound' declaration is exactly the scope of the
associated lexical variable or function. If the declaration is
associated with a special variable, the scope is the scope the variable
would have had if it had not been special.
`Free' declarations are scoped as if they appeared in a new LOCALLY form
which surrounded the entire special form at the beginning of whose body
the declaration appears. This is the same as what CLtL p.155 defines to
be the scope of `pervasive' declarations.
The following is a complete listing of the types of declarations and
their class (`bound' or `free'):
SPECIAL declarations may be either `bound', affecting both a binding and
references, or `free', affecting only references, depending on whether
the declaration is attached to a variable binding, as described above.
TYPE declarations may only be `bound' (see next section).
FTYPE and FUNCTION declarations may only be `free' (see next section).
INLINE declarations may only be `free' (see next section).
NOTINLINE declarations may only be `free' (see next section).
IGNORE declarations may only be `bound'.
OPTIMIZE declarations may only be `free'.
The `free' or `bound' scoping of implementation-dependent declaration
specifiers is implementation-dependent.
Interactions with other proposals:
There has been some discussion in X3J13 of permitting `free' TYPE
declarations. This is a semantic issue, not a scoping issue, and should
be treated independently.
If Common Lisp is extended to permit declarations in FLET and LABELS
forms, by acceptance of cleanup proposal FLET-DECLARATIONS:ALLOW,
then declarations of functions (FTYPE, FUNCTION, INLINE, and
NOTINLINE) which appear before the body of a FLET or LABELS form which
defines that function are `bound'. Such declarations in other contexts
remain `free'.
Common Lisp is ambiguous about whether a variable may be bound several
times by a single form. It has been proposed that multiple bindings be
permitted for LET*, DO*, PROG* forms and for &AUX variables in lambda
expressions. If multiple bindings are permitted, `bound' declarations
are treated as if there were a separate `bound' declaration for each of
the bindings.
Examples:
;;; Some examples of `free' and `bound' declarations.
(let ((a 1))
(declare (optimize speed)) ;this is a `free' declaration
(let ((b 2))
(declare (type integer b)) ;this is a `bound' declaration
(declare (special a)) ;this is a `free' declaration
()))
;;; This example applies if you believe that FLET may have declarations.
(flet ((foo (x) (1+ x)))
(declare (notinline foo)) ;this is a `bound' declaration
(declare (notinline 1+)) ;this is a `free' declaration
())
;;; The following code is from Pavel.
;;; It produces 7 in existing implementations.
;;; If the proposal is adopted, it will produce 8.
(let ((foo 6)) ;a special binding of FOO
(declare (special foo)) ;`bound' declaration
(let ((foo 7)) ;a lexical binding of FOO
(let ((foo (1+ foo))) ;is the second FOO special or not?
(declare (special foo)) ;`bound' declaration
foo)))
;;; Treatment of LET* under the proposal if multiple bindings of the same name are allowed.
;;; This form produces the value 9.
(let ((foo 6)) ;a special binding of FOO
(declare (special foo)) ;`bound' declaration
(let ((foo 7)) ;a lexical binding of FOO
(let* ((foo (1+ foo)) ;special binding, lexical reference
(foo (1+ foo))) ;special binding, special reference
(declare (special foo)) ;`bound' declaration, applies to both bindings
foo)) ;special reference
Rationale:
`Bound' declarations are made to control a particular binding of a
variable and should be scoped the same way as that binding. This is as
true of `bound' declarations which were pervasive under the old rules
as it is of those that were not.
Current practice:
The `bound'/`free' division based on context replaces CLtL's static
pervasive/nonpervasive/SPECIAL division. Most implementations implement
the rules in CLtL. Symbolics currently implements rules based on
Zetalisp which are different from both this proposal and Common Lisp.
Symbolics plans to change to Common Lisp rules in the future.
Cost to Implementors:
The cost of implementing this change should be moderate. The change
will be localized to a handful of places in the compiler and interpreter
which apply declarations to variables. The other cost would be in
providing tools for users to find programs whose meaning will change.
Cost to Users:
The proposal changes only the treatment of `bound' declarations. This
change will break very few existing production programs.
It is possible to mechanically examine a program to determine whether
its behavior would change under the new rules. This permits an
implementation to provide a transition tool to ease conversion to the
new definition.
Cost of non-adoption:
The ability of a `bound' declaration to affect code outside the scope
of the variable which it appears to declare has led to endless confusion
and discussion at Symbolics, on the Common-Lisp mailing list, and
elsewhere. It will continue to do so unless it is smoothed over somehow.
Benefits:
The costs of non-adoption will be avoided.
Aesthetics:
The distinction between `bound' and `free' declarations introduced by
this proposal is a natural one.
Discussion:
A proposal to forbid `free' declarations except in LOCALLY forms and a
proposal to have `free' declarations affect only the body were discarded
as being too incompatible.
The mapping from the existing pervasive/nonpervasive/SPECIAL division of
declarations and the one proposed here is complex. In general,
nonpervasive declarations are `bound' and pervasive declarations are
`free'. SPECIAL declarations are either `bound' or `free' based on
their context, and are no longer treated as a special case.
Some historical support for having `free' and `bound' declarations:
Date: Tue, 20 Dec 83 15:50 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Declarations
To: Common-Lisp@SU-AI.ARPA
...
There are two disjoint classes of declaration: those that are attached
to a particular variable binding, and those that are not. Note that I
am not discussing proclamations here; they have their own scoping rules
which are different from the rules for declarations.
The scoping rule for the first kind of declaration is that it applies to
precisely the text that is in the lexical scope of the variable binding
with which it is associated. Such declarations are shadowed by a
variable binding for the same name inside their scope. Since the
lexical scoping rules are very well and precisely defined, we already
understand everything about this kind of declaration.
The scoping rule for the second kind of declaration is that it is
pervasive. The declaration is attached to a lambda-expression or to a
form (one of the special forms listed on page 125). The declaration
applies to all text inside that expression or form; there are no special
cases such as init-forms of LET or DO. Such declarations are shadowed
by a conflicting declaration inside their scope.
Possible names for the two kinds of declaration are "lexical" and
"pervasive" or "variable" and "non-variable."
...
∂03-Feb-88 0757 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:56:51 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334275; Tue 2-Feb-88 20:47:21 EST
Date: Tue, 2 Feb 88 20:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal (Version 2)
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8801152126.AA12191@orion.utah.edu>,
<880115-144847-6100@Xerox>,
<8801152357.AA12554@orion.utah.edu>
Message-ID: <19880203014708.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I strongly favor FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE,
for the same reasons that Masinter gave.
Date: Fri, 15 Jan 88 16:57:09 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
I volunteered to write it up, not make it into a life-long crusade....
I know very, very well how you feel. :-)
∂03-Feb-88 0835 CL-Cleanup-mailer Issue: EXPORT-IMPORT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 08:35:17 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334619; Wed 3-Feb-88 09:11:16 EST
Date: Wed, 3 Feb 88 11:34 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXPORT-IMPORT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880203012230.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880203113410.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The dialect of Common Lisp which Paul Robertson (my boss) wrote for the 386,
and which later became the basis for the Cloe Runtime system (our native 386 Lisp)
is an example of a Lisp where the implementor assumed that EXPORT was to do
an implicit import. As Paul explains it to me, he doesn't see any ambiguity.
The documentation says it makes the argument symbols accessible as externals
of the designated package, and the only way to do that is to first import them
if necessary, so that's what he does. He's not even sure why it needs a
clarification -- from his point of view, all other implementations are simply
buggy. I have to say I think he makes perfectly believable case and it's
arguably reasonable to call this a request for an incompatible change, not just
a clarification. But in any case, I think there's no question that there's at
least an ambiguity. (By the way, Paul's preference is for EXPORT-IMPORT:YES,
but I'm pretty sure he can be talked into EXPORT-IMPORT:NO if that's what everyone
seems to think is best.)
The reason for this issue in the first place is that we have an outstanding
bug report from a Cloe customer who says that EXPORT is not doing an implicit
IMPORT on the 3600 (while it is doing the IMPORT on the 386) and I'm trying
to figure out which side to fix. So this is not a contrived issue (as Jonl
suggested it might be).
∂03-Feb-88 0951 CL-Cleanup-mailer Issue: EXPORT-IMPORT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 09:51:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334859; Wed 3-Feb-88 12:51:44 EST
Date: Wed, 3 Feb 88 12:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXPORT-IMPORT
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880203113410.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880203175149.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 3 Feb 88 11:34 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
The dialect of Common Lisp which Paul Robertson (my boss) wrote for the 386,
and which later became the basis for the Cloe Runtime system (our native 386 Lisp)
is an example of a Lisp where the implementor assumed that EXPORT was to do
an implicit import.
That changes the Current Practice picture from what I had thought based
on the proposal and the ensuing discussion, which was that all known
implementations had adopted EXPORT-IMPORT:NO.
However, section 11.4, referenced from the description of EXPORT, is
quite explicit. At the bottom of CLtL p.177 and the top of p.178, the
operation of EXPORT is described in quite explicit terms that are not
consistent with EXPORT-IMPORT:YES. Thus I suggest that the
EXPORT-IMPORT issue should be dropped, as there is no ambiguity in the
language definition. Steele's knuckles should be rapped for writing a
book that contained explicit information which several highly skilled
Lisp experts were unable to find even after repeated readings of the
book. (No offense. It's a good book for what it was intended to be,
it's just that we all turned around and asked it to be more. Blame
all of us old Common Lisp folks for not realizing from the beginning
that a more precise specification would be demanded.)
Aside to Kent: We need to be a little more careful about the phrase "the
Symbolics implementation" in the Current Practice writeups now, since there
is more than one.
∂03-Feb-88 1843 CL-Cleanup-mailer Issue: EXPORT-IMPORT
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 18:43:50 PST
Received: by labrea.Stanford.EDU; Wed, 3 Feb 88 18:44:08 PST
Received: from bhopal.lucid.com by edsel id AA03576g; Wed, 3 Feb 88 17:34:44 PST
Received: by bhopal id AA12488g; Wed, 3 Feb 88 17:38:55 PST
Date: Wed, 3 Feb 88 17:38:55 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802040138.AA12488@bhopal.lucid.com>
To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU
Cc: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 3 Feb 88 11:34 EST <880203113410.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: EXPORT-IMPORT
re: The reason for this issue in the first place is that we have an outstanding
bug report from a Cloe customer who says that EXPORT is not doing an
implicit IMPORT . . . and I'm trying to figure out which side to fix.
So this is not a contrived issue (as Jonl suggested it might be).
No, I didn't suggest that it was somehow contrived. Your original proposal
mentioned that "some users" erroneously though that export was defined to
do an import first, and I too have seen persons make this mistake. Instead,
I question why IMPORT-EXPORT:YES comes up as a cleanup proposal (rather than
as a topic for discussion on, say, the common-lisp mailing list). At best,
more emphasis in the documentation might be needed, if users continue to
be misled here.
-- JonL --
∂03-Feb-88 1844 CL-Cleanup-mailer Issue: EXPORT-IMPORT
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 18:44:10 PST
Received: by labrea.Stanford.EDU; Wed, 3 Feb 88 18:44:26 PST
Received: from bhopal.lucid.com by edsel id AA03683g; Wed, 3 Feb 88 17:43:28 PST
Received: by bhopal id AA12513g; Wed, 3 Feb 88 17:47:47 PST
Date: Wed, 3 Feb 88 17:47:47 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802040147.AA12513@bhopal.lucid.com>
To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU
Cc: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU,
labrea!common-lisp%sail@labrea.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 3 Feb 88 11:34 EST <880203113410.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: EXPORT-IMPORT
The reason why some users may be mislead about EXPORT is that they fail to
heed the directive on the second line of p186: "See section 11.4 for details".
The one paragraph description of EXPORT on p186 is grossly incomplete without
reference to that other section, which cleary states: (p177, last paragraph)
"The function EXPORT takes a symbol that is *accessible* in some specified
package ... If the symbols is not accessible at all in the specified
package, a correctable error is signalled that, upon continuing, asks the
user whether the symbol should be imported." [my emphasis].
Every implementation I'm familiar with seems to implement the above
semantics rigidly; no one quietly imports the symbol without first
signalling an error.
-- JonL --
∂03-Feb-88 1857 CL-Cleanup-mailer Issue: EXPORT-IMPORT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 18:57:17 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 335471; Wed 3-Feb-88 21:56:43 EST
Date: Wed, 3 Feb 88 21:56 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXPORT-IMPORT
To: edsel!jonl@labrea.stanford.edu
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8802040138.AA12488@bhopal.lucid.com>
Message-ID: <880203215637.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I spoke to Paul and we're content to withdraw this issue based on Moon's reference to
an authoritative (albeit slightly misplaced) section.
I guess I try never to bring -anything- up on the Common-Lisp mailing list ever because
it is too large to be of any practical value to me. I'm personally not interested in the
simultaneous opinion of tens of thousands of implementors, users, and none-of-the-aboves
if we can decide an issue amongst ourselves. I assume we all read Common-Lisp so it's
hardly like having sent this out to Common-Lisp would have spared any of us.
I treat Common-Lisp as a potential source for more topics for our discussions, not as
an alternative forum for our discussions.
∂03-Feb-88 1945 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 19:45:24 PST
Received: by labrea.Stanford.EDU; Wed, 3 Feb 88 19:45:35 PST
Received: from bhopal.lucid.com by edsel id AA04962g; Wed, 3 Feb 88 19:35:03 PST
Received: by bhopal id AA12851g; Wed, 3 Feb 88 19:39:14 PST
Date: Wed, 3 Feb 88 19:39:14 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802040339.AA12851@bhopal.lucid.com>
To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU
Cc: labrea!cl-cleanup%SAIL@labrea.Stanford.EDU,
labrea!Hornig%ALDERAAN.SCRC.Symbolics.COM@labrea.Stanford.EDU
In-Reply-To: David A. Moon's message of Tue, 2 Feb 88 22:46 EST <19880203034640.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE (Version 2)
I'm not a little dismayed at the verbosity of this proposal. Does the
following 3-sentence summary encompass most of the statement of problem:
(1) Some declarations only affect how a particular instance of a binding
is interpreted. [these are called 'bound' in the terminology of
the proposal].
(2) Some don't. [i.e, they affect something else other than some
property of a particular instance of a binding.]
(3) Except for SPECIAL, no declaration in category (1) is permitted
to have any other interpretation.
[Thus (3) prevents the following "natural" extension of declare IGNORE:
(locally
...
(let ((x <computation>))
(declare (ignore x))
<body-without-x>)
...)
<==>
(locally (declare (ignore x))
...
(let ((x <computation>))
<body-without-x>)
...)
]
The proposal, then, is presumably to clarify that
(4) The scope of a `bound' declaration is exactly the scope of the
associated [lexical] variable or function.
[Since only SPECIAL is permitted to have both 'free' and 'bound' meanings,
then (4) really only applies to it, for otherwise, the scope of a 'bound'
declaration is simply the one binding it is attached to.]
A primary consequence of this is that
(let ((x <computation>))
(declare (special x))
<body>)
is not equivalent to
(locally (declare (special x))
(let ((x <computation>))
<body>))
nor is it equivalent to
(locally (declare (special x))
(let ((x <computation>))
(declare (special x))
<body>))
because the LOCALLY form would be permitted to affect the references in
<computation> and the scope of the variable 'x' does not include the
form <computation>.
On the other hand, because the following SPECIAL declaration is not
linked to the binding(s) occuring in the surrounding LET, then
(let ((x <computation>))
(declare (special y))
<body>)
is equivalent to
(locally (declare (special y))
(let ((x <computation>))
<body>))
in which case the declaration *does* affect the (free) references to
'y' found in <computation>.
Is this indeed the intended effect? If so, is this the answer to the
questions about how to gag the compiler messages about "free" variables
appearing in &optional (etc) init forms of defuns?
Now, I think (3) above has some nasty consequences; in particular the
inability to give local type declarations over a lexical interval.
MacLisp wasn't scoped like this. I vaguely remember discussion a long
time ago that the reason why Common Lisp variable declarations aren't
scoped like this is because of the inadvertent capturing of lexically-
apparent declarations by macroexpanded code. [Indeed, some implementations
of DEFSUBST still have the bug that they have macro-expansion semantics
rather than function-call semantics.]
It would be a shame if the declarational scheme had to be castrated simply
because no one could figure out a better solution to the captured lexical
environment problem. I really don't see that having one construct --
ordinary macros -- that can lose referential transparency is so bad; we
certainly need a "safe" version thereof, like DEFSUBST should be; but
this hardly seems the time to grossly revise the semantics of macro
expansion, which have other problems with lack of transparency. [Someone
may point out that the phrase "Kohlbecker's Thesis" ought to be invoked
here.]
If the macro-induced lack of "referential transparency" isn't a factor
at all in CL's prohibition against allowing "pervasive" declarations to
affect bindings found in enclosed forms, then I apologies for the above
two-paragraph excursion. But I still would like to see a more succinct
3-or-4-sentence summary of this proposal's problem description.
-- JonL --
∂03-Feb-88 2023 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 20:22:51 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 335527; Wed 3-Feb-88 23:22:25 EST
Date: Wed, 3 Feb 88 23:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE (Version 2)
To: Jon L White <edsel!jonl@labrea.Stanford.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU, Hornig@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8802040339.AA12851@bhopal.lucid.com>
Message-ID: <19880204042224.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 3 Feb 88 19:39:14 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
I'm not a little dismayed at the verbosity of this proposal.
Hornig can correct me, but I believe that was in response to requests
for clarity and specificity.
Does the
following 3-sentence summary encompass most of the statement of problem:
(1) Some declarations only affect how a particular instance of a binding
is interpreted. [these are called 'bound' in the terminology of
the proposal].
(2) Some don't. [i.e, they affect something else other than some
property of a particular instance of a binding.]
Sorry, but I can't figure out what precisely the above two sentences mean.
(3) Except for SPECIAL, no declaration in category (1) is permitted
to have any other interpretation.
There appear to be several types of declarations that can be either free
or bound, depending on whether they appear attached to a binding of the
variable or function that they declare, or appear someplace else. The
major error in the existing declaration scoping, I feel, was the idea
that pervasive or non-pervasive could be a property of a declaration
specifier, independent of context.
[Thus (3) prevents the following "natural" extension of declare IGNORE:
(locally
...
(let ((x <computation>))
(declare (ignore x))
<body-without-x>)
...)
<==>
(locally (declare (ignore x))
...
(let ((x <computation>))
<body-without-x>)
...)
]
I can't figure out what you intend this supposedly natural extension to
mean. The ignore declaration would apply to all references to x inside
its scope, except for references shadowed by an inner binding of the
name x. But this is nonsense! The ignore declaration applies to the
absence of references; the only way it applies to references is the
minor feature that CLtL suggests the compiler ought to warn if you
declare a variable to be ignored and then reference it.
The proposal, then, is presumably to clarify that
(4) The scope of a `bound' declaration is exactly the scope of the
associated [lexical] variable or function.
[Since only SPECIAL is permitted to have both 'free' and 'bound' meanings,
then (4) really only applies to it, for otherwise, the scope of a 'bound'
declaration is simply the one binding it is attached to.]
It's not true that special is the only such declaration.
A primary consequence of this is that
(let ((x <computation>))
(declare (special x))
<body>)
is not equivalent to
(locally (declare (special x))
(let ((x <computation>))
<body>))
nor is it equivalent to
(locally (declare (special x))
(let ((x <computation>))
(declare (special x))
<body>))
because the LOCALLY form would be permitted to affect the references in
<computation> and the scope of the variable 'x' does not include the
form <computation>.
The above is true unless I have misunderstood what you're saying.
On the other hand, because the following SPECIAL declaration is not
linked to the binding(s) occuring in the surrounding LET, then
(let ((x <computation>))
(declare (special y))
<body>)
is equivalent to
(locally (declare (special y))
(let ((x <computation>))
<body>))
in which case the declaration *does* affect the (free) references to
'y' found in <computation>.
That's correct too, I believe. It's also the same as in CLtL.
Is this indeed the intended effect? If so, is this the answer to the
questions about how to gag the compiler messages about "free" variables
appearing in &optional (etc) init forms of defuns?
I can't figure out what that question has to do with any of this. Perhaps
those questions were on some mailing list that I am happily not a member of?
Now, I think (3) above has some nasty consequences; in particular the
inability to give local type declarations over a lexical interval.
MacLisp wasn't scoped like this. I vaguely remember discussion a long
time ago that the reason why Common Lisp variable declarations aren't
scoped like this is because of the inadvertent capturing of lexically-
apparent declarations by macroexpanded code. [Indeed, some implementations
of DEFSUBST still have the bug that they have macro-expansion semantics
rather than function-call semantics.]
It would be a shame if the declarational scheme had to be castrated simply
because no one could figure out a better solution to the captured lexical
environment problem. I really don't see that having one construct --
ordinary macros -- that can lose referential transparency is so bad; we
certainly need a "safe" version thereof, like DEFSUBST should be; but
this hardly seems the time to grossly revise the semantics of macro
expansion, which have other problems with lack of transparency. [Someone
may point out that the phrase "Kohlbecker's Thesis" ought to be invoked
here.]
If the macro-induced lack of "referential transparency" isn't a factor
at all in CL's prohibition against allowing "pervasive" declarations to
affect bindings found in enclosed forms, then I apologies for the above
two-paragraph excursion.
I can't figure out what any of this means. Perhaps you're still going on
about the fact that Hornig refuses to include in his DECLARATION-SCOPE proposal
the unrelated proposal to change what CLtL says about TYPE, namely that
it affects only variable bindings (not references)? I'm on Hornig's side
there; it's not a good idea to bundle unrelated proposals together. If you
want to change the rules for TYPE, and by the way I agree with you that
they should be changed, just write a CL-Cleanup proposal to do so and let
it stand on its own merits. It's completely and totally independent of
Hornig's proposal. It can go into the language with exactly the same
semantics regardless of whether Hornig's proposal is approved or rejected.
The only difference would be whether the description of a TYPE declaration
that is not attached to a binding uses the word "free" or uses the word
"pervasive".
But I still would like to see a more succinct
3-or-4-sentence summary of this proposal's problem description.
It seems clear that my attempt to revise the proposal to make it clearer,
in response to the mail discussion, didn't work. I'm willing to spend
some more time helping with this proposal, but since I don't really understand
what's unclear about it to you, I don't see what to change. Perhaps you
could tell me what questions it doesn't answer.
∂04-Feb-88 1529 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 15:29:09 PST
Received: by labrea.Stanford.EDU; Thu, 4 Feb 88 15:29:25 PST
Received: from bhopal.lucid.com by edsel id AA08824g; Thu, 4 Feb 88 14:13:28 PST
Received: by bhopal id AA00979g; Thu, 4 Feb 88 14:17:52 PST
Date: Thu, 4 Feb 88 14:17:52 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802042217.AA00979@bhopal.lucid.com>
To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU
Cc: labrea!cl-cleanup%SAIL@labrea.Stanford.EDU,
labrea!Hornig%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU
In-Reply-To: David A. Moon's message of Wed, 3 Feb 88 23:22 EST <19880204042224.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE (Version 2)
re: It seems clear that my attempt to revise the proposal to make it clearer,
in response to the mail discussion, didn't work. ... I don't really
understand what's unclear about it to you, I don't see what to change.
Perhaps you could tell me what questions it doesn't answer.
Here's one, taken from our interchange:
{JonL}
[Since only SPECIAL is permitted to have both 'free' and 'bound' meanings
then (4) really only applies to it, for otherwise, the scope of a 'bound
declaration is simply the one binding it is attached to.]
{Moon}
It's not true that special is the only such declaration.
I didn't fully believe that either, but taking the words from your
rewriting of the proposal:
The following is a complete listing of the types of declarations and
their class (`bound' or `free'):
SPECIAL declarations may be either `bound', affecting both a binding and
references, or `free', affecting only references, depending on whether
the declaration is attached to a variable binding, as described above.
TYPE declarations may only be `bound' (see next section).
FTYPE and FUNCTION declarations may only be `free' (see next section).
INLINE declarations may only be `free' (see next section).
NOTINLINE declarations may only be `free' (see next section).
IGNORE declarations may only be `bound'.
OPTIMIZE declarations may only be `free'.
All except SPECIAL are restricted to one kind or the other, and this is
alleged to be a complete list.
Now, I would prefer to see SPECIAL, NOT/INLINE, and TYPE declarations all
have the same scoping rules. For example, if the "cleanup" proposal for
NOT/INLINE declarations on lexical functions were accepted, then a form like:
(locally (declare (notinline car)) [1]
(flet ((car (z) [2]
(list (cdr z) (car z)))) [3]
(declare (inline car)) [4]
. . .
(print (car x)))) [5]
wouldn't be ambiguous, as it apprently now is. If NOTINLINE were scoped
like this proposal for SPECIAL, then it would be clear that the declaration
on line [4] applies only to the "car" defined on line [2], and that the
usage of "car" on line [3] isn't affected by it {see how nice and parallel
that is to the SPECIAL rules}; on the other hand, the usage on line [3] is
affected by the 'free' declaration on line [1]. I hope that this is your
preference too.
One of the problems I had in reading the proposal was figuring out what
you meant by "'bound' declaration". I realize that this isn't a specific
question that you can "answer", but it was a concern. Apparently, in
return, you couldn't figure out my question as to its meaning. I had
asked if it was like:
(1) Some declarations only affect how a particular instance of a binding
is interpreted. [these are called 'bound' in the terminology of
the proposal].
If I may try again, let me point to the declare on line [4] above. It
applies to the *particular* instance of the binding of the name "car"
on line [2], does it not? It says "interpret this function as an inline
version of something named car". It doesn't separately apply to the usage
on line [5], because [5] is a reference to the lexical name established
by [2] and its properties are completely determined by that binding on
line [2]. Furthermore, unlike MacLisp's scoping rules, the declare on
line [4] would have no effect on any inner re-bindings (by FLET) of "car"
such as might occur in the part elided ". . .". That's why I say "a
particular instance of a binding".
If this still isn't clear to you, and if no one else is particularly
concerned about it, then maybe we could take any further comments "off-line".
You have also expressed confusion as to what the non-standard code
(locally (declare (ignore x))
(let ((x 3))
(mumble)))
could possibly mean. I thought I stated it by giving an equivalent in
standard code. That is, unlike existing practice, but *like* MacLisp,
I could imagine it to mean the same as:
(let ((x 3))
(declare (ignore x))
(mumble))
It shouldn't be too hard to believe that such a translation can be done
fully mechanically. Since this kind of declaration inheritance was
the norm in MacLisp, and since you used MacLisp for years, I didn't
realize you'd have trouble remembering it [the "norm", in particular
for SPECIAL and TYPE declarations].
I know only too well that such a interpretation of 'pervasive', or 'free',
declarations conflicts with meaning given for them by CLtL -- that any
inner binding of a name is completely shielded from any outer, lexical
declarations. This is one of the two parts that differ substantially from
MacLisp -- the other being that a declare before the body of a special form
is not generally equivalent to the same declare wrapped LOCALLY around the
form. But since PROCLAMations stick with the name, and are not walled-out
by ordinary bindings, then it's not too hard to imagine some 'free'
declarations operating this way. [One might use the term "shadowed" rather
than "walled-out", but I dislike it since there is another technical meaning
for "shadow"; also, the allegedly shadowing binding isn't by itself
providing an alternate "shadowing" declaration.]
I perceive the current dilemma, which "DECLARATION-SCOPE" proposes
to alleviate in some small way, as stemming from Common Lisp's partial
attempt to cure the problem of captured lexical declarations during macro
expansion. That's all I intended to say in the two-paragraph essay near
the end of my msg. Consequently, I'm totally amazed at your reply to it:
. . . Perhaps you're still going on about the
fact that Hornig refuses to include in his DECLARATION-SCOPE proposal
the unrelated proposal to change what CLtL says about TYPE, . . .
especially since I publicly lauded this proposal when it came out, and
have never expressed dissatisfaction with Hornig's handling of it. I
remember remarking on the similarity of the two issues -- they are *not*
totally unrelated -- but that has nothing at all to do with the conjecture
about "macroexpansions capturing lexical declarations".
-- JonL --
∂04-Feb-88 1620 CL-Cleanup-mailer cover letter for issues mailing
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Feb 88 16:20:02 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 FEB 88 16:20:22 PST
Date: 4 Feb 88 16:20 PST
From: Masinter.pa@Xerox.COM
to: cl-cleanup@Sail.stanford.edu
subject: cover letter for issues mailing
Message-ID: <880204-162022-1310@Xerox>
Hi -- I've just managed to make a pass thru my backlog of mail and hope to get
the mailing ready in the next day or so. (I think this means getting it into the
mail Monday morning, which I hope is not too late.)
I propose to mail out at least the issues listed in my 14-Jan-88 message subject
Issue status: READY FOR LETTER BALLOT and those few that seem to have reached
convergence since then. (I'm not sure what those are yet, I haven't sorted out
all the mail.)
Subject: Issues from the cleanup sub-committee
To: X3J13@Sail.stanford.edu
reply-to: CL-CLEANUP@Sail.Stanford.EDU
The cleanup committee has a number of issues for discussion and/or voting at the
next X3J13 meeting. I will be mailing out those issues which are ready for
voting at the next meeting, one at a time.
I am uncertain as to the exact procedure for voting; I imagine that Bob Mathis
will help clarify. My current understanding is that you should be prepared
either to vote for endorsing a proposal or should prepare a written objection.
Please address your replies directly to cl-cleanup@Sail.stanford.edu. We promise
to summarize and redistribute any replies we get. X3J13@Sail.stanford.edu should
*not* be used for technical discussions, however.
The cleanup issues fall into several categories.
Passed X3J13/Jun87:
Mailed to X3J13 prior to the June 1987 meeting of X3J13 and passed (via voice
vote) at that meeting.
As these were distributed before, they will not be mailed again except by
individual request, although the issues will appear on the ballot.
Conditionally passed X3J13/Jun87, new version passed X3J13/Nov87:
While an earlier version was mailed to X3J13 prior to the Jun87 meeting, the
most recent version was distributed only in hardcopy at the November 1987
meeting.
Passed X3J13/Nov87:
Distributed only via hardcopy at the November 1987 meeting.
New ballot items for Mar88:
Not previously distributed to X3J13, but ready for voting.
In discussion:
Some of these issues may be distributed via electronic mail to X3J13 prior to
the March meeting for discussion at the meeting, although they will not appear
on a ballot at that time.
∂04-Feb-88 1722 CL-Cleanup-mailer Cleanup committee meeting prior to X3J13
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Feb 88 17:22:26 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 FEB 88 17:22:48 PST
Date: 4 Feb 88 17:22 PST
From: Masinter.pa@Xerox.COM
Subject: Cleanup committee meeting prior to X3J13
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880204-172248-1451@Xerox>
I'm a bit disorganized at the moment, as I recall at least one message (from
Scott Fahlman) that I can no longer find about a subcommittee meeting prior to
X3J13.
Since I can't find it, I may be off-base, but:
I propose the cleanup committee meet on Tuesday morning, March 15, 9 AM-12 Noon.
I think this leaves us some time for informal discussions before and after, and
is not as likely to interfere with other subcommittee meetings. (The character
subcommittee is proposed to meet all day Monday, Tuesday and Friday, so a
conflict with it is currently unavoidable.)
∂05-Feb-88 1241 CL-Cleanup-mailer Ready issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Feb 88 12:40:59 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 FEB 88 12:33:45 PST
Date: 5 Feb 88 12:33 PST
From: Masinter.pa@Xerox.COM
Subject: Ready issues
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880205-123345-2825@Xerox>
New for this meeting:
- ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87)
(Interaction of ADJUST-ARRAY and displaced arrays)
- APPEND-DOTTED (Version 5, 14-Jan-88)
(What happens to CDR of last CONS? in other
than last arg?)
- ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87)
(Extend ASSOC-IF, etc. to allow :KEY)
- COMPILER-WARNING-BREAK (Version 4,23-Nov-87 )
(Does *BREAK-ON-WARNING* affect the compiler?)
- DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87)
(Documentation string is not evaluated.)
- DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88)
(DISASSEMBLE doesn't smash the def if not compiled)
- DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87)
( DO-SYMBOLS can the same symbol twice?)
- FLET-DECLARATION (Version 2, 2 Feb 88)
(Allow declarations in FLET, MACROLET)
- PATHNAME-SYMBOL (Version 3, 23-OCT-87)
(Do symbols automaticly coerce to pathnames?)
- PUSH-EVALUATION-ORDER (Version 5,25-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
- REDUCE-ARGUMENT-EXTRACTION (version 2, 30 Dec 87)
(Add :KEY to REDUCE)
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
(What does SHADOW do if symbol is already there?)
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
( *FEATURES* are in the keyword package)
Already passed:
- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed X3J13/Jun87
Version 7 passed X3j13/Nov87
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Version 1 passed X3J13/Nov87
- COMPILER-WARNING-STREAM (Version 6, 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87
- DEFVAR-INIT-TIME (Version 2, 29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
- DEFVAR-INITIALIZATION (Version 4, Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
- FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
- FORMAT-ATSIGN-COLON (Version 4, 5-jun-87)
(@: == :@ in format)
Version 4 passed X3J13/Jun87.
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Version 2 passed X3J13/Nov87
- FORMAT-OP-C (Version 5, 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 passed X3J13/Nov87.
- IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Version 8 passed X3J13/Nov87
- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Version 6 passed X3J13/Nov 87
- PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
----- End Forwarded Messages -----
----- End Forwarded Messages -----
∂05-Feb-88 1336 CL-Cleanup-mailer Re: Ready issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Feb 88 13:36:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 FEB 88 13:33:53 PST
Date: 5 Feb 88 13:30 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Ready issues
In-reply-to: Masinter.pa's message of 5 Feb 88 12:33 PST
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <880205-133353-2970@Xerox>
Ooops ... I meant to mail that to myself, rather than cl-cleanup. I'll have a
real "ready issues" list available, hopefully by the end of the day.
∂05-Feb-88 2053 CL-Cleanup-mailer EXPORT-IMPORT and the other random commands
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 20:53:00 PST
Received: from AI.AI.MIT.EDU by labrea.Stanford.EDU with TCP; Fri, 5 Feb 88 20:52:50 PST
Date: Fri, 5 Feb 88 23:53:29 EST
From: "Robert W. Kerns" <RWK@ai.ai.mit.edu>
Subject: EXPORT-IMPORT and the other random commands
To: CL.BOYER@r20.utexas.edu
Cc: common-lisp@sail.stanford.edu, edsel!jonl@labrea.stanford.edu,
labrea!CL-Cleanup%SAIL@labrea.stanford.edu,
labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
In-Reply-To: Msg of Wed 3 Feb 88 21:48:23-CST from Bob Boyer <CL.BOYER at R20.UTEXAS.EDU>
Message-Id: <322177.880205.RWK@AI.AI.MIT.EDU>
Date: Wed 3 Feb 88 21:48:23-CST
From: Bob Boyer <CL.BOYER at R20.UTEXAS.EDU>
I think that the "Put in seven extremely random user
commands" stuff needs to be documented much more rigorously.
I don't think that any collection of cross-references in
CLTL will suffice to make things clear.
Frankly, I think this would be a waste of time. I don't
think ANY amount of documenting and test suites has any chance
of working. The underlying idea that you define the package
environment by performing a series of side-effects on the package
system is so wrong it is beyond repair. It is so entirely sensitive
to complex and obscure order-of-events issues that even if you
were successful in getting all implementations to do exactly the
same thing, real-life users could not adaquately standardize their
workstyles and interactions to avoid problems, even if they could
understand all the rules!
I think the time would be better spent on specifying and adopting
a DEFPACKAGE macro. This would always be the first form of the first
file loaded. (Or at least, before any IN-PACKAGE's for that package).
I think it is much easier to specify the behaviour when you don't have
to consider all the order-of-operations issues. Of course, it still needs
to be carefully specified, but the problem is more constrained, and you're
not so burdened with issues of compatibilty or programing environment
issues.
There are quite a number of us who think the DEFPACKAGE issue is important,
but so far as I know there aren't any actual proposals being written up.
∂05-Feb-88 2056 CL-Cleanup-mailer {Improved version} EXPORT-IMPORT and the other random commands
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 20:56:15 PST
Received: from AI.AI.MIT.EDU by labrea.Stanford.EDU with TCP; Fri, 5 Feb 88 20:56:08 PST
Date: Fri, 5 Feb 88 23:56:53 EST
From: "Robert W. Kerns" <RWK@ai.ai.mit.edu>
Subject: {Improved version} EXPORT-IMPORT and the other random commands
To: CL.BOYER@r20.utexas.edu
Cc: common-lisp@sail.stanford.edu, edsel!jonl@labrea.stanford.edu,
labrea!CL-Cleanup%SAIL@labrea.stanford.edu,
labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Message-Id: <322178.880205.RWK@AI.AI.MIT.EDU>
Date: Wed 3 Feb 88 21:48:23-CST
From: Bob Boyer <CL.BOYER at R20.UTEXAS.EDU>
I think that the "Put in seven extremely random user
commands" stuff needs to be documented much more rigorously.
I don't think that any collection of cross-references in
CLTL will suffice to make things clear.
You've identified an important issue, *BUT*:
Frankly, I think this approach would be a waste of time. I don't
think ANY amount of documenting and test suites has any chance
of working. The underlying idea that you define the package
environment by performing a series of side-effects on the package
system is so wrong it is beyond repair. It is so entirely sensitive
to complex and obscure order-of-events issues that even if you
were successful in getting all implementations to do exactly the
same thing, real-life users could not adaquately standardize their
workstyles and interactions to avoid problems, even if they could
understand all the rules!
I think the time would be better spent on specifying and adopting
a DEFPACKAGE macro. This would always be the first form of the first
file loaded. (Or at least, before any IN-PACKAGE's for that package).
I think it is much easier to specify the behaviour when you don't have
to consider all the order-of-operations issues. Of course, it still needs
to be carefully specified, but the problem is more constrained, and you're
not so burdened with issues of compatibilty or programing environment
issues.
There are quite a number of us who think the DEFPACKAGE issue is important,
but so far as I know there aren't any actual proposals being written up.
Presumably the issue is one of manpower to address it, not of lack of
interest, so I would be dissapointed to see us discuss ways of "fixing"
this rather bleak area of CL, rather than working on DEFPACKAGE.
∂07-Feb-88 1207 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 88 12:07:19 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338018; Sun 7-Feb-88 15:07:23 EST
Date: Sun, 7 Feb 88 15:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8801152126.AA12191@orion.utah.edu>
Message-ID: <880207150705.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
My preference is for EXTEND-LIST-TYPE because:
* I'm afraid USE-ACTUAL-ARGUMENT-TYPE will get us into trouble somehow.
* I find it bothersome that the same argument declarations which are
used internally in the function would not be be usable externally.
* I think it's unfair to provide only this special-purpose way of
declaring a sequence type when in fact there are numerous other places
in the language where it might be useful to declare a sequence type.
If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly
(if it is not already in CLtL somewhere) that the following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
since there will be no way to type-declare this. Even though this is an
obscure case (that doesn't even work in some implementations), it's the
sort of thing that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.
I'm content to have the proposal presented as USE-ACTUAL-ARGUMENT-TYPE
and I expect that will pass, but I want to be listed as dissenting.
∂07-Feb-88 1224 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 88 12:24:15 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338037; Sun 7-Feb-88 15:22:35 EST
Date: Sun, 7 Feb 88 15:22 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
To: Masinter.pa@Xerox.COM
cc: pierson@mist.ARPA, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880114-200421-4849@Xerox>
References: The message of 30 Dec 87 19:26 EST from Dan L. Pierson <pierson@mist.ARPA>
Message-ID: <880207152219.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 14 Jan 88 20:03 PST
From: Masinter.pa@Xerox.COM
I think we can ship a version 3 that has the [[]] remarks removed. Probably we
want to add to the Discussion section.
What do folks think about a paragraph like:
DISASSEMBLE is an environment feature; some question has been raised as to the
place and force of environment features in the standard. However, this proposal
stands if DISASSEMBLE is part of the standard language.
All fine with me.
∂07-Feb-88 1242 CL-Cleanup-mailer New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 88 12:41:59 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338083; Sun 7-Feb-88 15:41:47 EST
Date: Sun, 7 Feb 88 15:41 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2)
To: sandra%orion@cs.utah.edu
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8801152125.AA12185@orion.utah.edu>
References: <19880203013624.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880207154134.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I also am mostly happy with version 2 of FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD,
though I'd like to see it address Moon's concern about specifying clearly whether
the declared keyword list is exhaustive.
By the way, on a related point, if I specify FOO as:
(FUNCTION FOO (&KEY (:A INTEGER) (:B INTEGER) &ALLOW-OTHER-KEYS))
is it safe to assume that other keys are really ignored. Does this
mean I have done:
(DEFUN FOO (&KEY A B &ALLOW-OTHER-KEYS) ...)
in which case the other keys are literally discarded, or might I have done:
(DEFUN FOO (&REST Z &KEY A B &ALLOW-OTHER-KEYS) ...)
in which case the other keys might not really be getting ignored.
Some clarification on this point might also be useful.
∂07-Feb-88 1300 CL-Cleanup-mailer Re: {Improved version} EXPORT-IMPORT and the other random commands
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 13:00:33 PST
Received: from tully.Berkeley.EDU ([128.32.150.44]) by labrea.Stanford.EDU with TCP; Sun, 7 Feb 88 13:00:31 PST
Received: by tully.Berkeley.EDU (5.57/1.25)
id AA07693; Sun, 7 Feb 88 00:15:20 PST
From: hilfingr%tully.Berkeley.EDU@berkeley.edu (Paul Hilfinger)
Message-Id: <8802070815.AA07693@tully.Berkeley.EDU>
To: "Robert W. Kerns" <RWK@ai.ai.mit.edu>
Cc: CL.BOYER@r20.utexas.edu, common-lisp@sail.stanford.edu,
edsel!jonl@labrea.stanford.edu,
labrea!CL-Cleanup%SAIL@labrea.stanford.edu,
labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Subject: Re: {Improved version} EXPORT-IMPORT and the other random commands
In-Reply-To: Your message of Fri, 05 Feb 88 23:56:53 EST.
<322178.880205.RWK@AI.AI.MIT.EDU>
Date: Sun, 07 Feb 88 00:15:12 PST
I'm also interested in seeing the "package problem" cleared up. I
have two questions.
1) Has anyone written a definitive "why CL packages stink" article
or message, preferably one that someone regards as definitive?
2) You write
> ... The underlying idea that you define the package environment
> by performing a series of side-effects on the package system
> is so wrong it is beyond repair. It is so entirely sensitive
> to complex and obscure order-of-events issues that even if
> you were successful in getting all implementations to do
> exactly the same thing, real-life users could not adaquately
> standardize their workstyles and interactions to avoid
> problems, even if they could understand all the rules!
>
> I think the time would be better spent on specifying and
> adopting a DEFPACKAGE macro. This would always be the first
> form of the first file loaded. (Or at least, before any
> IN-PACKAGE's for that package)....
Are you saying that this DEFPACKAGE macro would NOT have any side-effects
on the package system? How would it have its effect? Or, more
generally, what is the underlying idea with which you want to
replace "side-effects on the package system"? (Somehow, electronic
mail adds an unwonted note of harshness to my syntax; that last
question was meant to be straight, not rhetorical.)
Paul Hilfinger
U. C. Berkeley
Hilfinger@Berkeley.EDU
∂07-Feb-88 1306 CL-Cleanup-mailer {Improved version} EXPORT-IMPORT and the other random commands
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 13:06:43 PST
Received: from AI.AI.MIT.EDU by labrea.Stanford.EDU with TCP; Sun, 7 Feb 88 13:06:31 PST
Date: Sun, 7 Feb 88 07:04:36 EST
From: "Robert W. Kerns" <RWK@ai.ai.mit.edu>
Subject: {Improved version} EXPORT-IMPORT and the other random commands
To: hilfingr%tully.Berkeley.EDU@ucbvax.berkeley.edu
Cc: common-lisp@sail.stanford.edu, CL.BOYER@r20.utexas.edu,
edsel!jonl@labrea.stanford.edu,
labrea!CL-Cleanup%SAIL@labrea.stanford.edu,
labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
In-Reply-To: Msg of Sun 07 Feb 88 00:15:12 PST from hilfingr%tully.Berkeley.EDU at berkeley.edu (Paul Hilfinger)
Message-Id: <322657.880207.RWK@AI.AI.MIT.EDU>
Date: Sun, 07 Feb 88 00:15:12 PST
From: hilfingr%tully.Berkeley.EDU at berkeley.edu (Paul Hilfinger)
I'm also interested in seeing the "package problem" cleared up. I
have two questions.
1) Has anyone written a definitive "why CL packages stink" article
or message, preferably one that someone regards as definitive?
I don't think there's complete agreement on all the
reasons why "CL packages stink". Personally, in fact,
I think they're not bad, in use, but the setup is what
stinks. Others would disagree.
But I think there's pretty good agreement that the
seven extremely perverse functions are perverse.
2) You write
> ... The underlying idea that you define the package environment
> by performing a series of side-effects on the package system
> is so wrong it is beyond repair. It is so entirely sensitive
> to complex and obscure order-of-events issues that even if
> you were successful in getting all implementations to do
> exactly the same thing, real-life users could not adaquately
> standardize their workstyles and interactions to avoid
> problems, even if they could understand all the rules!
>
> I think the time would be better spent on specifying and
> adopting a DEFPACKAGE macro. This would always be the first
> form of the first file loaded. (Or at least, before any
> IN-PACKAGE's for that package)....
Are you saying that this DEFPACKAGE macro would NOT have any side-effects
on the package system? How would it have its effect? Or, more
generally, what is the underlying idea with which you want to
replace "side-effects on the package system"?
No, the important word up there was "series". There's no
problem with a single declarative form, at the very start.
It's when you dribble things out over several files with
a series of "functions" which have to be treated specially
by the compiler, that you start running into problems.
Not to mention the confusion factor. The very fact that this
silly mnemonic (which I can never remember) is needed to
keep the order straight should be a dead givaway that something
is wrong with splitting up declaring the package into a series
of micro-steps. You might think of these as "package microcode".
It shouldn't be supprising that there are dependencies on the
particular way an implementation does its environment.
If you declare imports, exports, inheritences, etc. at the
same time you CREATE the package, you can't have any problems
with symbols accidentally getting created before things are
set up right. (Just for one example).
(Somehow, electronic
mail adds an unwonted note of harshness to my syntax; that last
question was meant to be straight, not rhetorical.)
I know the problem. You'll notice I sent an improved version of
my note, when I noticed it sounded like I was being critical of
Bob Boyer's complaint. (Instead of urging a different approach to
solving it).
Paul Hilfinger
U. C. Berkeley
Hilfinger@Berkeley.EDU
∂08-Feb-88 0901 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
Received: from VALLECITO.SCRC.Symbolics.COM (SCRC-VALLECITO.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 09:01:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 202361; Mon 8-Feb-88 12:01:38 EST
Date: Mon, 8 Feb 88 12:00 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: sandra%orion@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880207150705.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880208170043.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 7 Feb 88 15:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
My preference is for EXTEND-LIST-TYPE because....
Does this mean you have a solution in mind for the well-known problems
with the element-type argument to the ARRAY type specifier? If so, I'd
like to hear it. If not, I think you would be heading towards making the
LIST and SEQUENCE type specifiers either have the same problem or be
inconsistent with ARRAY.
∂08-Feb-88 1031 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:31:29 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338697; Mon 8-Feb-88 13:30:18 EST
Date: Mon, 8 Feb 88 13:30 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
To: pierson@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
franz!smh@BERKELEY.EDU
In-Reply-To: <8801192339.AA20676@mist.UUCP>
Message-ID: <880208133005.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I can't support this proposal.
I believe that the correct fix is for wording to be added that explains
that *TERMINAL-IO* might be a bidirectional stream which directs input
from and to a virtual and not necessarily a physical terminal. As such,
*TERMINAL-IO* should properly be initialized to
(MAKE-TWO-WAY-STREAM SYSTEM-INTERNALS:*UNIX-STANDARD-INPUT*
SYSTEM-INTERNALS:*UNIX-STANDARD-OUTPUT*)
If it were, then *STANDARD-INPUT* and *STANDARD-OUTPUT* would behave
correctly with no relaxation of the requirements on their initial values.
I think it is important that *STANDARD-INPUT*, *STANDARD-OUTPUT*, etc.
be defined to be bound to synonym streams initially. Here are some reasons:
* It may be important to the programmer to recover the value of this
virtual terminal. There is already a restriction on binding
*TERMINAL-IO* in Common Lisp, so the virtual terminal will always
be accessible from *TERMINAL-IO*. If the virtual terminal were in
*STANDARD-INPUT* and *STANDARD-OUTPUT*, the user might bind himself
into a corner where he could no longer recover the value of the
virtual terminal.
* I think the initial I/O pairing should be available as a unit rather
than in two different places.
* If there is no physical console, the value of *TERMINAL-IO* will
have garbage. There is no reason that input/output from/to programs to
*TERMINAL-IO* should fail just because an alternate input or output
stream was provided. You cannot make *TERMINAL-IO* indirect via synonym
stream to *STANDARD-INPUT*,etc. without risking complete disaster.
If it did, the user might do:
(LET ((*STANDARD-INPUT* (MAKE-SYNONYM-STREAM '*TERMINAL-IO*))) ...)
and get a circular synonym stream. In order to make sure that programs
can portably use synonym streams at all, it is extremely important that
the directionality of synonym streams be well-defined (ie, from
*STANDARD-INPUT* to *TERMINAL-IO* and not vice versa) and that there be
a known bottoming out point, *TERMINAL-IO*, which cannot be a synonym
stream to anything the user can get his hands on.
∂08-Feb-88 1033 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:33:42 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338699; Mon 8-Feb-88 13:32:48 EST
Date: Mon, 8 Feb 88 13:32 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
To: pierson@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8712310035.AA19317@mist.UUCP>
Message-ID: <880208133244.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I support REDUCE-ARGUMENT-EXTRACTION:KEY.
The Edit History seems to have lost the info about Version 1. That
should be restored.
There's a stray comma at the end of the References field.
∂08-Feb-88 1037 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:36:53 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338711; Mon 8-Feb-88 13:36:22 EST
Date: Mon, 8 Feb 88 13:36 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM, kempf%hplabs@hplabs.hp.com
In-Reply-To: <19880203022524.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880208133616.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I'm afraid we're going in circles on LOAD-TIME-EVAL. I'm not in favor of
this approach. Moon's Version 4 undoes all of what was important to me
in Version 3. I'll try to get the relevant parties together for a
meeting on this internally to Symbolics prior to the March meeting and
we'll see if we can present a coherent front.
∂08-Feb-88 1040 CL-Cleanup-mailer Issue: FLET-DECLARATIONS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:40:36 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338723; Mon 8-Feb-88 13:40:23 EST
Date: Mon, 8 Feb 88 13:40 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLET-DECLARATIONS (Version 2)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
Hornig@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19880203020430.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880208134020.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I support FLET-DECLARATIONS:ALLOW.
I found the second paragraph of the proposal part ("The scope of such ...")
to be very hard to read.
∂08-Feb-88 1043 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:42:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338725; Mon 8-Feb-88 13:41:39 EST
Date: Mon, 8 Feb 88 13:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: pierson@MULTIMAX.ARPA, CL-Cleanup@SAIL.STANFORD.EDU, franz!smh@BERKELEY.EDU
In-Reply-To: <880208133005.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880208184148.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Kent, I agree with your comments, however you did not address yourself
to the issue that Unix requires *STANDARD-OUTPUT* and *ERROR-OUTPUT* to
go to different output destinations, while Common Lisp requires
*STANDARD-OUTPUT* and *ERROR-OUTPUT* to be initially bound to synonyms
for the same stream.
I don't know precisely what the "correct fix" to Common Lisp is here, but
I don't think it involves either making all the stream variables' bindings
initially undefined, nor leaving all but *TERMINAL-IO* defined to be
synonym streams to *TERMINAL-IO*. Maybe the variables should be defined
in terms of their contracts rather than their implementations.
I think the proposal needs another iteration based on a new idea.
∂08-Feb-88 1051 CL-Cleanup-mailer Issue: FLET-DECLARATIONS (Version 2)
Received: from VALLECITO.SCRC.Symbolics.COM (SCRC-VALLECITO.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:51:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 202409; Mon 8-Feb-88 13:52:24 EST
Date: Mon, 8 Feb 88 13:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLET-DECLARATIONS (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU, Hornig@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880208134020.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880208185144.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 8 Feb 88 13:40 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I found the second paragraph of the proposal part ("The scope of such ...")
to be very hard to read.
Then we should pass the DECLARATION-SCOPE proposal, which supersedes that
paragraph. :-}
∂08-Feb-88 1058 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:58:21 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338755; Mon 8-Feb-88 13:58:07 EST
Date: Mon, 8 Feb 88 13:57 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE (Version 2)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
Hornig@ALDERAAN.SCRC.Symbolics.COM
In-Reply-To: <19880203034640.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880208135758.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I support DECLARATION-SCOPE:LIKE-VARIABLE, but I have some related
issues I'd like to ask about while we're on the topic. I wonder about
the following cases. Do we believe that they all follow clearly from the
indicated rules (and/or other known and agreed upon rules)?
(DEFUN FOO-1 (X)
(DECLARE (INLINE FOO-1))
(+ X 1))
(DEFUN BAR-1 (X) (FOO-1 X))
Can FOO-1 be inlined in BAR-1? I say no because of modularity and
incremental debugging constraints. I think there are implementations
which do this inlining. I would like to see this and other situations
treated explicitly.
(DEFUN BAR-2 (X)
(FLET ((FOO-2 (X)
(DECLARE (INLINE FOO-2))
(+ X 1)))
(FOO-2 X)))
Can FOO-2 be inlined in BAR-2? I say it's not totally unreasonable
and I wouldn't be surprised if some implementations have resorted to
this as a way for users to say that FOO-2 is inline since they cannot
put the information at the top of the FLET body. I found the wording
of this proposal to be a little vague on whether this INLINE
declaration spans the whole FLET, but my final impression was that
it does. Is this right? Can we get this into the spec?
Other examples I'd like to see made explicit:
(DEFUN FOO-3 (X)
(DECLARE (FUNCTION FOO-3 (FIXNUM) FIXNUM))
(+ X 1))
(DEFUN BAR-3 (X)
(THE FIXNUM (+ (FOO-3 X) 1)))
Can I use fixnum arithmetic in FOO-3? (I say yes.)
Can I use fixnum arithmetic in BAR-3? (I say no, to avoid
problems if one function is changed while the other is not.)
(LABELS ((FOO-4 (X)
(DECLARE (FUNCTION FOO-4 (FIXNUM) FIXNUM))
(+ X 1))
(BAR-4 (X)
(THE FIXNUM (+ (FOO-4 X) 1))))
(FLET ((BAZ-4 (X) (THE FIXNUM (+ (FOO-4 X) 1))))
...))
Can I use fixnum arithmetic in FOO-4? in BAR-4? In BAZ-4?
I hope yes to all.
∂08-Feb-88 1112 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 11:12:12 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338778; Mon 8-Feb-88 14:10:25 EST
Date: Mon, 8 Feb 88 14:10 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, pierson@MULTIMAX.ARPA,
CL-Cleanup@SAIL.STANFORD.EDU, franz!smh@BERKELEY.EDU
In-Reply-To: <19880208184148.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880208141018.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 8 Feb 88 13:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Kent, I agree with your comments, however you did not address yourself
to the issue that Unix requires *STANDARD-OUTPUT* and *ERROR-OUTPUT* to
go to different output destinations, while Common Lisp requires
*STANDARD-OUTPUT* and *ERROR-OUTPUT* to be initially bound to synonyms
for the same stream.
Ah, somehow I missed this issue. It should have been in the problem description, not
in the test case/example section.
I don't know precisely what the "correct fix" to Common Lisp is here, but
I don't think it involves either making all the stream variables' bindings
initially undefined, nor leaving all but *TERMINAL-IO* defined to be
synonym streams to *TERMINAL-IO*. Maybe the variables should be defined
in terms of their contracts rather than their implementations.
Sounds like a plausible avenue to pursue.
I think the proposal needs another iteration based on a new idea.
Agreed. I'm certainly willing to continue entertaining discussion on the issue.
If it helps the Unix guys putting together the next round of proposals,
I'm willing to have relax the requirement that *ERROR-OUTPUT* be bound
to a synonym stream to *TERMINAL-IO*. It's mainly the -IO* variables and
*STANDARD-INPUT* and *STANDARD-OUTPUT* that I'm concerned about having
point to *TERMINAL-IO* initially. *ERROR-OUTPUT* and *TRACE-OUTPUT* are
less important to me as long as the issues are clearly documented.
In fact, though, I think that many supposedly portable programs are -extremely-
sloppy about distinguishing *ERROR-OUTPUT* and *TERMINAL-IO* and that lots of
dumb problems like
(FORMAT *ERROR-OUTPUT* "You did something bad: ...")
(YES-OR-NO-P "Continue anyway? ")
will be shown up if *ERROR-OUTPUT* and *TERMINAL-IO* do not initially point to
the same stream. Maybe it's just as well that such bugs do get shown up, but I
think there should be a guide to what kinds of things belong on *ERROR-OUTPUT*
and what belongs on *QUERY-IO* and what on *TERMINAL-IO* and what on
*STANDARD-OUTPUT*. We're still way too vague about all this. Any proposal to
fix things must be more specific, not more vague, since systems cannot
come up with "creative" solutions to the Unix problem in the absence of
cooperation from the users.
∂10-Feb-88 0203 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 02:02:58 PST
Received: by labrea.Stanford.EDU; Wed, 10 Feb 88 02:02:57 PST
Received: from bhopal.lucid.com by edsel id AA05180g; Wed, 10 Feb 88 01:45:42 PST
Received: by bhopal id AA05095g; Wed, 10 Feb 88 01:50:27 PST
Date: Wed, 10 Feb 88 01:50:27 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802100950.AA05095@bhopal.lucid.com>
To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU
Cc: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU,
labrea!Hornig%ALDERAAN.SCRC.Symbolics.COM.labrea!moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Mon, 8 Feb 88 13:57 EST <880208135758.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE
You are asking a broader set of questions that Horning apparently didn't
want to address in his original cleanup proposal. There are a plethora
of issues related to this -- the whole semantics of declarations in Common
Lisp seems to be in disarray now.
I think these broader issues must be raised, and that is one reason why
what started out as a very small clarification has grown into a much
larger controversy. Perhaps it was premature to think we could take the
dragon by the tail and not feel his hot breath too. I would actually
like to see a *coordinated* set of cleanup issues on declarations.
"Coordinated", because it often doesn't make sense to talk about these
issues in isolation; witness the extremely close link of this scoping
proposal with the FLET-DECLARATIONS:ALLOW proposal.
If this proposal -- DECLARATION-SCOPE:LIKE-VARIABLE is to be seriously
considered in isolation, the I would at least like to suggest an alteration
as outlined below. First, a very brief overview of the proposal:
Hornig's purpose stated in the original message of
"Tue, 5 Jan 88 08:21 EST" was:
. . . The issue is
whether the scope of some or all of the declarations includes code
appearing in the non-body part of the special form containing the
declaration.
. . .
`Normal' declarations are made to control a particular binding of a
variable and should be scoped the same way as that binding. This is as
true of `normal' declarations which were pervasive under the old rules
as it is of those that were not.
So the original DECLARATION-SCOPE proposal would seem to be addressing
the specific kinds of problem illustrated by this example:
(setf (symbol-value 'x) 0)
(trace car)
(defun foo (x y)
(let ((x (car y))
(car (+ 4 x)))
(declare (special x) (inline car +))
(list car (car x))))
A reasonable test, after compiling [and hypothetically assuming that a call
to CAR that isn't declared "inline" will go out-of-line] works like:
(foo 4 '((hello))) ==> {fn: CAR, arglist: ( ((hello)) )} ;trace output
(8 hello)
namely, that unlike in some implementations, the special declaration
does not apply to the form "(+ 4 x)", and further, the inline declaration
applies to "(car x)" but not to "(car y)".
But still a lot of issues are left open. [One of them, for example, is
how to say that the inline declaration of "car" above doesn't apply to
the binding of the variable "car" established in the special form in
which the declaration occurs 'normally'. It seems obvious to a reader
with intuition; it's not so obvious from reading all the legalese and
generalizations of a formal prescription.]
I call attention again to Hornig's guiding principle:
`Normal' declarations are made to control a particular binding of a
variable and should be scoped the same way as that binding.
I think it would be a great simplification that declares in a binding
special form (like, LET, PROG, LABELS, etc) should either "control
a particular binding" and thus by definition have the scope of that
binding [and nothing more], or be scoped as follows. For those
declarations that in a binding special form that don't correlate with
any of the bindings being established -- like the inline declaration
for "+" in the example above -- their scope should be the same as if
there had been a "variable" in the binding list for it to "control".
That is, rather than
(let ((z (+ 4 x)))
(declare (special z) (inline +))
(+ z 5))
being equivalent to
(locally (declare (inline +))
(let ((z (+ 4 x)))
(declare (special z))
(+ z 5)))
I think it would be more consistent for it to be equivalent to:
(let ((z (+ 4 x)))
(declare (special z))
(locally (declare (inline +))
(+ z 5)))
I could submit a proposal called DECLARATION-SCOPE:FULLY-LEXICAL to specify
this. But as I said before, I think there are a whole plethora of issues
that ought to be considered together, so some attention needs to be paid
to all the related issues.
This FULLY-LEXICAL approach would help certify one of your feelings; you
posed the example
(DEFUN FOO-1 (X)
(DECLARE (INLINE FOO-1))
(+ X 1))
(DEFUN BAR-1 (X) (FOO-1 X))
and suggeted that the inline declaration should not apply to the "reference"
to FOO-1 in function BAR-1. Easily handled by the "lexical" approach.
However, I would even question the appropriateness a form like
(DEFUN FOO-3 (X)
(DECLARE (FUNCTION FOO-3 (FIXNUM) FIXNUM))
(+ X 1))
The kind of binding being in this special form is a LAMBDA binding --
a "variable" binding, not a "function" binding -- so the ftype declaration
on FOO-3 certainly doesn't apply to X. Hence it ought not to act like a
global proclaim. Indeed, PROCLAIM exists precisely to cover the case of
setting a global function cell; and this isn't the same kind of binding
that occurs in, say, FLET, or LABELS. To achieve the effect you are
supposing, you might have to say:
(locally (declare (function foo-3 (fixnum) fixnum))
(defun foo-3 (x)
(+ x 1)))
or possibly
(defun foo-3 (X)
(flet ((foo-3 (x)
(+ x 1)))
(declare (function foo-3 (fixnum) fixnum))
(foo-3 x)))
-- JonL --
∂10-Feb-88 0858 Common-Lisp-Object-System-mailer Status of SETF functions in Common Lisp
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Feb 88 08:58:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 340430; Wed 10-Feb-88 11:57:41 EST
Date: Wed, 10 Feb 88 11:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Status of SETF functions in Common Lisp
To: Jon L White <edsel!jonl@labrea.Stanford.EDU>
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, sun!franz!smh@labrea.Stanford.EDU,
rwk@AI.AI.MIT.EDU, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8802100814.AA05040@bhopal.lucid.com>
Message-ID: <19880210165749.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 10 Feb 88 00:14:17 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Date: Thu, 4 Feb 88 14:46:35 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
....
re: But, haven't we already extended symbol-function to take lists of the
form (setf fn) as an argument. If not, how do we get hold of setf
generic-functions?
I don't recall how the recent discussions on this mailing list suggested
to do it.
This was in a cleanup proposal which the Cleanup committee already approved,
submitted to X3J13 in November, and was approved by X3J13 at that time. I
wasn't there, so I don't know for sure what happened, but I don't think
there was any voting. Perhaps there was some kind of verbal approval.
Anyway my point is that this is as settled an issue as any issue can be
and there's a place where the answer is written down. I don't have a copy
of it myself or I'd send it to you.
You're jumping the gun here. The issue of (setf fn) as a function name
came up as a need from CLOS, but was never presented for approval.
Then I guess one of Larry's status reports saying that issue had been approved
was mistaken, or I misread it.
Larry
assigned a sub-sub-committee to try to write up some proposal that would
encompass "function specs".
That's exactly what I did -not- want to happen. If setf functions,
which CLOS needs, get bogged down in all kinds of extraneous issues
about function specs, which CLOS does not need and does not want,
CLOS could end up getting the shaft. I think standardizing function
specs for Common Lisp is likely to be a fine thing, but I don't want
CLOS to have to wait for it to be completed.
We (this sub-sub-...) have met by conference phone, and discussed what
to do; initially Bob Kerns is working on a "definition specs" proposal
that will clean up and extend the LispMachine's functions specs somewhat.
But we all feel that this is new development -- not just a simple
"clarification", or "cleanup" or minor extension to Common Lisp, and
more serious thought needs to be given to the question. Most likely
there will much discussion about it in Palo Alto next month.
The only thing that's been settled so far is that we all agree on the
need to do something. The actual scope of what is done, the names
of the constructs, and as Danny asks "how do we get hold of setf
generic-functions?" are hardly a settled issues right now. At any rate,
I think he (Danny) was just asking how "we", the CLOS development,
proposed to get access to these things.
I guess I should wait until there is a report of the sub-sub-committee
to read, before drawing any conclusions or making any more intemperate
statements.
∂10-Feb-88 1007 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 10:07:39 PST
Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Wed 10 Feb 88 13:08:48-EST
Date: Wed, 10 Feb 1988 13:08 EST
Message-ID: <RAM.12373657131.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DECLARATION-SCOPE (Version 2)
In-reply-to: Msg of 8 Feb 1988 13:57-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Date: Monday, 8 February 1988 13:57-EST
From: Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
To: Moon at STONY-BROOK.SCRC.Symbolics.COM
Re: Issue: DECLARATION-SCOPE (Version 2)
[...] I wonder about the following cases.
I don't understand the unclarity that you seem to perceive in the
rules for scoping. We may not agree on what the lexical scope for
DECLARE should be, but I think we all agree that it is lexical. A
DECLARE at the head of a DEFUN (or lambda, or let, or anything else)
shouldn't affect anything outside of the body. The only
pseudo-exception is macros, which are known to violate referential
transparency.
(DEFUN FOO-1 (X)
(DECLARE (INLINE FOO-1))
(+ X 1))
(DEFUN BAR-1 (X) (FOO-1 X))
Can FOO-1 be inlined in BAR-1?
No, because the call to FOO-1 isn't within the scope of the
declaration.
[...] I think there are implementations which do this inlining. I
would like to see this and other situations treated explicitly.
I agree, and in my compiler cleanup proposal I have treated the
concept of compile-time function binding (which inlining is a special
case of) at some length.
(DEFUN BAR-2 (X)
(FLET ((FOO-2 (X)
(DECLARE (INLINE FOO-2))
(+ X 1)))
(FOO-2 X)))
Can FOO-2 be inlined in BAR-2? I say it's not totally unreasonable
and I wouldn't be surprised if some implementations have resorted to
this [...] Is this right? Can we get this into the spec?
Yes, but not for the reason you say. A lexical function can be called
however the compiler bloody well wants to, since there is no way that
the user can ever redefine it. If the compiler happens to take a
spurious declaration as a cue, that's fine, but it could just as well
use the phase of the moon. But once again, it is clear that the
INLINE declaration doesn't affect the function FOO-2 that you are
talking about, it is allowing inline expansion of some other FOO-2
(presumably global) within the body of the lexical FOO-2.
[...]
(DEFUN FOO-3 (X)
(DECLARE (FUNCTION FOO-3 (FIXNUM) FIXNUM))
(+ X 1))
Can I use fixnum arithmetic in FOO-3? (I say yes.)
I don't think so, although this rides on a combination of
interpretations of sticky points: function types in general, and
pervasive function type declarations in particular.
First of all, function type semantics require that the compiler prove
that the argument is a fixnum before it can assume that the result is
a fixnum. This means that even a global function type declaration is
useless when compiling the body, since there is no way the compiler
can convince itself it has seen all possible calls.
Secondly, the interpretation of the pervasive function type
declarations is really unclear, especially in the absence of any calls
within the scope. It seems that what you are saying is that within
this scope (but perhaps not elsewhere), FOO-3 will return a fixnum
when given a fixnum. If the compiler could prove that a declaration
that is true in this scope would be true in any scope (here
plausible), then this type declaration could perhaps be applied to
other calls, but only when the compiler could be sure that the same
FOO-3 was being referred to, which is difficult given the lack of a
general mechanism for allowing compile-time resolution of global
function names. But the fact that there is no call to FOO-3 within
the scope leads one to wonder whether any random declaration might be
vacuously true.
As I have said before, I think that the concept of function type in
Common Lisp (as correctly interpreted) is fairly useless. In my
compiler cleanup proposal, I handle compile-time function typing as a
special case of compile-time function binding.
If you have a proclamation that says all gloabal references to a
function are to a version that has been processed by the compiler,
then the compiler can propagate the types declared for the formal
parameter variables to the actual calls. The compiler is free to use
whatever type-inference method it pleases to determine the result
type.
The other examples you gave seem to refelect a similarly perplexing
interpretation of pervasive function type declartions.
Rob
∂11-Feb-88 1001 Common-Lisp-Object-System-mailer Re: Status of SETF functions in Common Lisp
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Feb 88 10:01:40 PST
Received: from Salvador.ms by ArpaGateway.ms ; 11 FEB 88 10:00:52 PST
From: masinter.PA@Xerox.COM
Date: 11 Feb 88 10:00:26 PST
Subject: Re: Status of SETF functions in Common Lisp
In-reply-to: Moon@STONY-BROOK.SCRC.Symbolics.COM's message of Wed, 10 Feb 88
11:57 EST, <19880210165749.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Jon L White <edsel!jonl@labrea.Stanford.EDU>,
Common-Lisp-Object-System@SAIL.STANFORD.EDU, sun!franz!smh@labrea.Stanford.EDU,
rwk@AI.AI.MIT.EDU, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880211-100052-7099@Xerox>
I've been out with the flu since last Friday afternoon (I thought it was just
jet lag...)
The issue SETF-FUNCTION-VS-SYMBOL was distributed and tentatively approved at
the November 1987 meeting of X3J13.
The larger question of generalizing this beyond SETF functions, and beyond
merely DEFUN and FLET, seemed like it was open for another, larger, more
comprehensive proposal.
I'm still at home today and don't have easy access to all of the files. I'm
hoping I am not too late to get the mailing out for X3J13 of all of the new
issues.
∂11-Feb-88 1637 CL-Cleanup-mailer {Improved version} EXPORT-IMPORT and the other random commands
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 16:36:50 PST
Received: from XX.LCS.MIT.EDU by labrea.Stanford.EDU with TCP; Thu, 11 Feb 88 16:36:41 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 11 Feb 88 19:28-EST
Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 80142; 11 Feb 88 19:27:38-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 93873; Wed 10-Feb-88 16:25:21-EST
Date: Thu, 11 Feb 88 19:26 est
From: mike%acorn@LIVE-OAK.LCS.MIT.EDU
To: RWK@ai.ai.mit.edu
Subject: {Improved version} EXPORT-IMPORT and the other random commands
Cc: hilfingr%tully.Berkeley.EDU@ucbvax.berkeley.edu,
common-lisp@sail.stanford.edu, CL.BOYER@r20.utexas.edu,
edsel!jonl@labrea.stanford.edu,
labrea!CL-Cleanup%SAIL@labrea.stanford.edu,
labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
I'm also interested in seeing the "package problem" cleared up. I
have two questions.
1) Has anyone written a definitive "why CL packages stink" article
or message, preferably one that someone regards as definitive?
I don't think there's complete agreement on all the
reasons why "CL packages stink". Personally, in fact,
I think they're not bad, in use, but the setup is what
stinks. Others would disagree.
I concur that they're ok, and even necessary for a symbolic language.
The problem I feel is that they are good for preventing "symbol"
mixups, but not "modularization". E.G., suppose you have a symbolic
differentiator, and so do I, and we don't want my dx/ds symbol to be
confused with your dx/ds symbol lest they not be able to work
together on an expression being differentiated.
Unfortunately, what packages are mostly used for is for some notion
of "modules" or "subsystems". (I agree that in lisp systems which
cons up expressions and eval or compile them that there is little
difference between these two scenarios, and we have to allow for
them, but most systems just don't do that kind of thing.) This is
why I think the notion of LOCALE's from scheme or T or whatever keeps
cropping up. My belief is that all "environment" (as opposed to
package or "obarray") based approaches to solving name conflict
problems are really designed to solve the problems of "modules" or
"subsystems" for software engineering. This is a different problem
from what packages can really solve.
But I think there's pretty good agreement that the
seven extremely perverse functions are perverse.
The last thing I saw on the subject which was under consideration by
the x3j13 compiler committee was a proposal to treat the "seven"
specially as a compiled file header. This is more than just
implicitly evaling them at compile time. Basically, this would clean up
the issue of what "side effects" these have at compile time vs.
load time of the compiled file. It would also bless specifically the
notion of a file-format for common lisp programs, thereby
making it clearly a lose to put IN-PACKAGE calls in the middle
of files, etc. This has not been firmed up yet.
What I think is needed is really a STYLE GUIDE to common lisp.
Something that says how you OUGHT to program to avoid the majority
of problems with things like the package system, etc. I think most
package problems come from misuse.
For instance, I would recommend that people be encouraged to
avoid USE-PACKAGE other than for package LISP, and instead
enumerate symbols one by one using the other package functions.
My experience is that noone wants to qualify any names so what
they do is carefully use every package that they've ever seen,
not realizing that
(let ((string "abcd"))
....)
in their code is creating a spec-bind because they are using a package
where string is a special.
nuff said.
...mike beckerle
∂11-Feb-88 2044 CL-Cleanup-mailer Status of SETF functions in Common Lisp
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 20:44:21 PST
Received: by labrea.Stanford.EDU; Thu, 11 Feb 88 20:44:28 PST
Received: from bhopal.lucid.com by edsel id AA14316g; Thu, 11 Feb 88 20:32:51 PST
Received: by bhopal id AA10636g; Thu, 11 Feb 88 20:37:43 PST
Date: Thu, 11 Feb 88 20:37:43 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802120437.AA10636@bhopal.lucid.com>
To: labrea!masinter.PA%Xerox.COM@labrea.Stanford.EDU
Cc: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU,
labrea!Common-Lisp-Object-System%SAIL.labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU,
labrea!RG%AI.AI.MIT.EDU.sun!franz!smh@labrea.Stanford.EDU,
labrea!rwk%AI.AI.MIT.EDU@labrea.Stanford.EDU
In-Reply-To: masinter.PA@Xerox.COM's message of 11 Feb 88 10:00:26 PST <880211-100052-7099@Xerox>
Subject: Status of SETF functions in Common Lisp
re: The issue SETF-FUNCTION-VS-SYMBOL was distributed and tentatively approved
at the November 1987 meeting of X3J13.
The issue name was SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
It had two parts:
(1) Specify that the expansion of SETF is into a function rather
than merely into a "macro";
(2) Allow a generalized name for this function.
The discussion under this issue is what led to formation of the
"definition specs" group. I doubt that anything that comes up
under the broader scope could conflict with the minimal assumptions
stated in that proposal. In particular, a nomenclature style like
(SETF FN) must be acceptable, and #'(SETF FN) will designate the
function so named.
I certainly remember the overwhelming approval for this direction of
extension, but I think the reason it didn't just end with this single
proposal is that every place that accepts function names is involved,
not just SETF methods.
-- JonL --
∂12-Feb-88 0813 CL-Cleanup-mailer Package Odor
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 08:13:07 PST
Received: from NRL-AIC.ARPA by labrea.Stanford.EDU with TCP; Fri, 12 Feb 88 08:12:32 PST
Return-Path: <hoey@nrl-aic.arpa>
Received: Fri, 12 Feb 88 11:11:02 EST by nrl-aic.arpa id AA02816
Date: 12 Feb 1988 10:22:34 EST (Fri)
From: Dan Hoey <hoey@nrl-aic.arpa>
Subject: Package Odor
Message-Id: <571677767/hoey@nrl-aic.arpa>
To: mike%acorn@live-oak.lcs.mit.edu
Cc: RWK@ai.ai.mit.edu, hilfingr%tully.Berkeley.EDU@ucbvax.berkeley.edu,
common-lisp@sail.stanford.edu, CL.BOYER@r20.utexas.edu,
edsel!jonl@labrea.stanford.edu,
labrea!CL-Cleanup%SAIL@labrea.stanford.edu,
labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Date: Thu, 11 Feb 88 19:26 est
From: mike%acorn@oak.lcs.mit.edu
...My experience is that no one wants to qualify any names so what
they do is carefully use every package that they've ever seen,
not realizing that
(let ((string "abcd"))
....)
in their code is creating a spec-bind because they are using a package
where string is a special....
Note that this is not *quite* the problem, since STRING is a symbol in
the LISP package, and anyone who is using random packages must surely
use LISP. In that case it is the error of the other package in
proclaiming a symbol of the LISP package SPECIAL (or CONSTANT), and you
couldn't defend against the error by not using that package.
That this is an error should be made explicit--I once broke the
compiler by proclaiming LISP:FUNCTION constant, and the compiler wanted
to bind it in a macroexpansion. Making it SPECIAL might have screwed
things up beyond hope of diagnosis.
The problem of using every package is still there, though. You should
know the names of all the symbols you import (including all the symbols
exported from packages you use), not only so you don't get surprised
about them being special, but so you don't accidentally make them
special when they shouldn't be. What the package system buys you is
letting this not be all the symbols in the world.
Dan
∂12-Feb-88 2337 CL-Cleanup-mailer Issue: SETF-SUB-METHODS
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 23:37:24 PST
Received: by labrea.Stanford.EDU; Fri, 12 Feb 88 23:37:47 PST
Received: from bhopal.lucid.com by edsel id AA19656g; Fri, 12 Feb 88 23:26:38 PST
Received: by bhopal id AA13404g; Fri, 12 Feb 88 23:31:35 PST
Date: Fri, 12 Feb 88 23:31:35 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802130731.AA13404@bhopal.lucid.com>
To: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU
Subject: Issue: SETF-SUB-METHODS
Ken Olum and I [JonL White] have given some thought to the problem that
spurred the issue SETF-METHOD-FOR-SYMBOLS, and feel that the issue as
stated attacks a small manifestation of the problem rather than the root
underlying case. Worse yet, the TEMPORARY-VARIABLE proposal requires a
change which creates a bug in another area of SETF usage [see below].
We propose that the problem lies in understanding of how SETF works when
the SETF expansion for a form like
(<access-fun> <place> ...)
involves the sub-recursive SETF expansion of <place>, or in other words,
when the accessing technique isn't fully specified just by looking at
the get-setf-method of <access-fun>. The class of such <access-fun>'s
is enumerated in CLtL, at the top of p96, except that GETF is missing
from that list [we propose that it be added there in the next manual].
This message will propose a clarification the issues of left-to-right
evaluation in such cases, and will also detail the actions that should
be taken by SETF methods on each of these place-types.
!
ISSUE: SETF-SUB-METHODS
References: CLtL pp. 95-96, 99, 105-106, 166
Issue: PUSH-EVALUATION-ORDER
Issue: SETF-METHOD-FOR-SYMBOLS
Category: Clarification
Edit history: Version 1 JonL & KDO 12-Feb-88
Problem description:
Tim Daly of IBM noticed that several implementations do not observe
left-to-right order of evaluation in the following form:
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
In these implementations, the side-effect of the setq happens before the
evaluation of the "subforms" necessary to fetch the list being updated.
A typical result is that 'r' = (B 6), 's' = (A 1 B 2 C 3) after the
operation. Surely, it should at least be the case that 's' = (A 1 B 6 C 3),
since the expectation is that the B property in this list is being
(destructively) changed.
Similar problems exist with LDB and CHAR-BIT.
It is not necessary to clarify that left-to-right order of evaluation
semantics should be observed; CLtL p99 is quite explicit about that.
Rather, a distinction needs to be made between the computations involved
in "evaluation" of the subforms, and other computations that are implicit
in the notion of "doing an access" or "doing a store".
Proposal: SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Elaborate the documentation of SETF, especially in the case of access
forms whose sub-forms are permitted to be generalized variable references
[and thus which need to call GET-SETF-METHOD during setf macro expansion].
We remember that GET-SETF-METHOD returns the following:
Some temporary variables
A list of value-producing forms
A list of store-variables (normally one).
A storing form.
An accessing form.
Then we want to say that:
Code generated using GET-SETF-METHOD does 2 or 3 of the following
things:
It evaluates the value-producting forms, and binds the temporary
variables to them. This will be called "binding the temporaries."
It evaluates the accessing form to get the old value of the place.
This will be called "doing the access."
It binds the store-variable to a new value and calls the storing form
to install it in the place. This will be called "doing the store."
The forms listed at the top of CLtL p96 permit recursive <place>
specifiers; for each one, we will describe how the sub-recursive
information from GET-SETF-METHOD is used.
LDB:
In a form such as
(SETF (LDB <byte-spec> <place-form>) <value-form>)
the place referred to by the <place-form> must always be both
accessed and updated. Even if the <place-form> refers to a
bignum, the bignum itself will not be modified but rather a new
bignum stored in the <place-form>. Thus this SETF should generate
code to do the following:
1. Evaluate <byte-spec>
2. Bind the temporaries for <place-form>
3. Evaluate <value-form>
4. Do the access to <place-form>
5. Do the store into <place-form> with the given bit-field
replaced with the value from step 3.
If the evaluation of <value-form> in step 3 sets a different
bit-field in the given place then since the access is done later
at step 4 this change will be preserved. See ROTATEF example in
discussion below. Nevertheless the evaluations required for
binding the temporaries are done in step 2, and thus the expected
left-to-right evaluation order is seen.
GETF:
The case of GETF is complicated by the fact that two different
"place" locators are involved: one to use if the specified
indicator is present in the property list, and another if not.
For example, in (SETF (GETF (AREF ... I) 'B) 6), if the I'th slot
of the array is NIL, then that slot must be changed, but if it
contains a list with the property B then only the cons cell with
that property value needs to be changed. This decision cannot be
made at macro-expansion time. It depends entirely on the contents
of the list in question, and so must be delayed until the last
possible moment.
In the first place, GETF should be listed among the other place
forms that admit place forms as one of their arguments. See CLtL
at the bottom of p95 and the top of p96.
More specifically, the expansion of
(SETF (GETF <place-form> <ind-form>) <value-form>)
should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Do the access to <place-form>
[Binding the temporaries and then doing the access is equivalent to
evaluating the <place-form>.]
3. Evaluate <ind-form> [and save the result in a temporary variable].
4. Check whether the value from 2 has the indicator from 3.
If so:
5A. Find cons-cell after indicator from above
6A. Evaluate <value-form>
7A. RPLACA cons-cell from 5A with value from 6A
[In this case, we do not do a store into <place-form>. When
the indicator is already present then the location specifed
by <place-form> doesn't need a new value.]
If not:
5B. Evaluate <value-form>
6B. Do the access to <place-form>, using the temporaries saved from
step 1 [this is not another evaluation -- but it may involve
some non trivial computation, depending on how complex the
access method really is.].
7B. Do the store into <place-form>, again using the temporaries saved
from step 1, setting it to a list with indicator from 3, new value
from 5B, and old list from 6B.
Test Cases:
(setq integer #x69)
(rotatef (ldb (byte 4 4) integer) (ldb (byte 4 0) integer))
Rationale:
As a principle,
(setf (foo-a x) (setf (foo-b x) ...))
should always set both of the "slots" of X, even if these slots are
implemented as bit-fields, getf-properties, and so on.
However,
(setf (foo-a x) (setf (foo-a x) ...))
is an error [that is, what happens is undefined.]
Current Practice:
-- Xerox and Franz already operate on GETF according to this perscription.
-- Symbolics and Lucid differ by always doing a setf on the variable
rather than updating the appropriate cons cell of the property list;
additionally, they fail to connect the new value put into 'r' to the
original property list which was 'r's value initially.
-- HP and VAX Common Lisps update the cons cell, but then set the variable
'r' again, nullifying the effect of the "(setq r nil)" in the <value-form>
computation.
Adoption cost:
Several implementations would require several hours of programmer and
documentation time.
Cost of non-adoption:
Users will think SETF is unnatural in that left-to-right order of
evaluation isn't always observed.
Benefits:
Uniform semantics and portability in the face of recursive "place specifiers"
for SETF. Setf of (LDB ... <place>) and of (GETF <place> ...) will behave
uniformly no matter the nature of the <place>.
Anyone who has copied examples from p105 and p106 will continue to
be able to use them.
Conversion Cost:
This is a clarification of a point not sufficiently elaborated in CLtL.
Symbolics and Lucid are already modifying their interpretation of this
code -- in some way or other.
Esthetics:
See "Cost of non-adoption"
Discussion:
In the case that spurred this discussion,
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
the consequent update is a RPLACA to some list cell -- not a setf of
the variable 'r' -- and thus 'r' should be NIL and 's' should now be
(A 1 B 6 C 3).
There is an interesting parallel between this case for GETF and the
very common mistake made by Lisp programmers with respect to the
function DELETE. How often the complaint is filed that DELETE didn't
do anything when it should have; but in fact the filer simply forgot
that delete can either update some CAR slot of the list originally
given it, or return some tail of the list originally give it, but
not both! E.g.
(setq l '(a a b c d)) ==> (a a b c d)
(delete 'a l) ==> (b c d)
l ==> (a a b c d)
The unwary user thinks that because 'l' is still eq to the original
value that "DELETE didn't do anything". The variability of action
at runtime here parallels the variable choice of location specifier
for (SETF (GETF ...) ...)
A previous proposal to fix this problem was misdirected. It was
phrased as follows:
Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE
Change the result of (get-setf-method 'foo) from
NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO
to
(#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175
The problem with this is that it breaks a relatively simple client of
setf technology:
(setq integer #x69)
(rotatef (ldb (byte 4 4) integer) (ldb (byte 4 0) integer))
no longer does the "right thing". Using the prescription for setf
methods on symbols from CLtL p105, the result of this 'rotatef' is
that integer = #x96; using that given by the TEMPORARY-VARIABLE
proposal leads to either #x99 [or #x66 depending on which order
the implementation chooses to do the actual stores in].
In addition, if 'integer' is replaced by '(car x)' here, then the
behavior is different under the TEMPORARY-VARIABLE proposal because
that only applies to symbols.
Implicitly, two "places" are being specified here to be updated; but
in fact the two places are not independent -- they both involve setq'ing
the variable 'integer'. Furthermore, each store operation implicitly
requires fetching the value from that place in order to combine it
with DPB. It is necessary to delay the accesses until the last moment
before combining with DPB in order to see the side-effects of the
earlier store operations.
∂13-Feb-88 1333 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 13:33:42 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 13:33:24 PST
Date: 13 Feb 88 13:32 PST
From: Masinter.pa@Xerox.COM
to: cl-cleanup@Sail.stanford.edu
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
Message-ID: <880213-133324-10349@Xerox>
This apparently did not get mailed before.
This issue is too simple to present two proposals. I've tried to represent
TEST-FOR-REMAINING-SUBLISTS as the single proposal and eliminate
TEST-FOR-REMAINING-ARGUMENTS.
!
Issue: FORMAT-COLON-UPARROW-SCOPE
References: CLtL p. 406 and also p. 403
Category: CLARIFICATION
Edit history: version 1: Guy Steele, 30 November 1987
version 2: Guy Steele, 18 January 1988
version 3: Masinter, 5 February 1988
Problem description:
Implementations currently differ on the question of what is tested by the FORMAT
command "~:↑". Some implementations test to see whether any arguments remain in
the sublist for the current iteration step; others test to see whether any
sublists remain. The text on page 406 is not clear on this point.
Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{. The
entire iteration process is terminated if and only if the sublist that is
supplying the arguments for the current iteration step is the last sublist (in
the case of ~:{) or the last FORMAT argument (~:@{). Note that ~:↑ is *not*
equivalent to ~:#↑; the latter terminates the entire iteration if and only if no
arguments remain for the current iteration step.
Test Cases/Examples:
(format nil "~:{~@?~:↑...~}" '(("a") ("b")))
Under this proposal, this yields "a...b", rather than "a".
Rationale:
This proposal is desirable because otherwise there is no way to test whether any
sublists remain. The text on page 406 may be construed to hint at this proposal
indirectly. To quote Nick Gall:
If one thinks about the intent of the parenthetical
(because in the standard case it tests for remaining arguments of
the current step only)
one should agree that "a...b" will be returned. In referring to ~↑ as
the "standard case", which tests the arguments remaining in the
current argument sublist, this parenthetical implies that there is
an `other case', which tests `something else.' The only `other case'
discussed is ~:↑, which therefore must test `something else.' I claim
that the parentheical makes no sense if we interpret ~:↑ as testing
the same condition as ~↑. If they both test the same condition, why
have the parenthetical explanation?
If ~:↑ doesn't test the same condition as ~↑, then what does it test?
I claim that the only test that makes sense is for ~:↑ to test the
only thing that affects the "entire iteration process:" the number of
sublists. When there are no more sublists, "the entire iteration
process" is terminated.
Current practice:
Some implementations already have the proposed behavior, include Symbolics
Common Lisp and TI Lisp.
Many other implementations currently have a different interpretation: the test
case returns "a", since ~:↑ in those implementations test for the remaining
arguments rather than remaining sublists. These currently include Kyoto Common
Lisp, Allegro Common Lisp, GCLISP, Xerox Common Lisp, Spice Lisp, and VAXLISP.
Cost to Implementors:
Many implementations will have to make a small change, probably a one-liner.
Cost to Users:
It is unlikely that much user code depends on the behavior of testing for
remaining arguments, but it is possible. The author of this writeup (Steele)
judges it somewhat more likely that user code might depend on the behavior of
testing for remaining sublists..
Cost of non-adoption:
Users would have to be warned not to use ~:↑ in code that is meant to be
portable.
Benefits:
Elimination of yet one more ambiguity.
The proposed semantics allows greater semantic power (there are more things one
can test).
Esthetics:
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr.
Discussion:
Guy Steele very strongly prefers the interpretation
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
David Moon, Kent Pitman, Pavel Curtis, Dan Pierson, Rob Poor, Scott Fahlman and
Nick Gall
favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Kevin Layer and Rich Robbins have spoken in favor f an alternative proposal, to
test for the remaining arguments.
Historical note: Steele first implemented this "feature", in Zetalisp, and so
the code in Symbolics Common Lisp is likely a direct descendant of the original
code. This might cause some to give weight to Steele's opinion. There are two
arguments against such credence. First, there is no reason why the original
code should be regarded as part of the specification of Common Lisp any more
than any other implementation; plainly, Steele botched the specification when he
wrote the book. Second, a professor of literature (I believe) once told Isaac
Asimov concerning a short story of his (I quote from memory): "Tell me, Dr.
Asimov, just because you wrote the story, what makes you think you know what it
means?"
∂13-Feb-88 1410 CL-Cleanup-mailer Issue FUNCTION-TYPE-KEY-NAME, Version 3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 14:10:06 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 14:10:49 PST
Date: 13 Feb 88 14:10 PST
From: Masinter.pa@Xerox.COM
Subject: Issue FUNCTION-TYPE-KEY-NAME, Version 3
To: cl-cleanup@sail.stanford.edu, sandra%orion@cs.utah.edu
Message-ID: <880213-141049-10374@Xerox>
!
Issue: FUNCTION-TYPE-KEY-NAME
References: CLtL p.47-48, 61
Category: CLARIFICATION, CHANGE
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(from comments by Kent Pitman)
Version 3, 13-Feb-88 Masinter
Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT,
KEYWORD-ARGUMENT-NAME-PACKAGE
FUNCTION-ARGUMENT-TYPE-SEMANTICS
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier
uses a syntax similar to the usual lambda list syntax to specify which
types go with which lambda list variables. However, there is a problem
with &KEY lambda variables because CLtL does not specify how the types
specified in the FUNCTION declaration are matched up to either the actual
arguments passed to the function, or the lambda variables in the function
definition (since the ordering of keyword arguments is arbitrary).
Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD):
(1) Specify that the &KEY parameters in a FUNCTION type specifier lambda
list should be supplied as lists of the form (<keyword> <type>). The
<keyword> must be a valid keyword-name symbol as must be supplied in the
actual arguments of a call. (This is usually a symbol in the keyword package,
but, as per KEYWORD-ARGUMENT-NAME-PACKAGE, not necessarily so.)
(2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda
list.
The interpretation of such declarations is that, when &KEY is given in a
FUNCTION type specifier lambda list, it is safe to assume that the &KEYs given
are exhaustive unless &ALLOW-OTHER-KEYS is present.
&ALLOW-OTHER-KEYS is an indication that other keyword arguments may actually be
supplied and, if supplied, may be used.
Test Case:
The type of the function MAKE-LIST could be declared as:
(FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)
Rationale:
(1) This specifies a direct correspondence between the argument type and
its matching keyword. All of the information is in one place, and the user
does not have to remember (or even know) the order in which &KEY arguments
appear in the actual function definition.
(2) This is probably an oversight in the original specification.
Current practice:
Many Common Lisp implementations currently ignore FUNCTION type
declarations. The situation regarding type specifications for keyword
arguments is so ambiguous that few users attempt to use them.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier or keyword arguments
in a FUNCTION type specifier may continue to do so. This proposal should
not involve massive amounts of code to be rewritten.
Conversion Cost:
Because the current situation is so ambiguous, FUNCTION type specifiers and
particularly the specification of keyword argument types are not widely used.
However, since this is an incompatible change, it would be nice if
implementations check for, and warn about, old-style usage.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
The syntax is fairly obvious and is analogous to the (<keyword> <variable>)
lambda list syntax.
Discussion:
The exact semantics of function declarations and the types of arguments is
still under discussion, as are several other issues dealing with declarations.
However, this issue seemed separable.
∂13-Feb-88 1428 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 14:28:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 14:28:43 PST
Date: 13 Feb 88 14:28 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <880213-142843-10387@Xerox>
!
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-ARGUMENT-TYPE-SEMANTICS
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables. However, this is actually of limited
usefulness in the context of a declaration, where one normally wants type
information about the actual arguments which can be passed to the function
rather than the lambda variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem
that the corresponding type given in the FUNCTION declaration must also be
LIST, but since this provides no information about the actual arguments,
some users/implementors have instead adopted the convention of supplying
the type of the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the
type specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided with
&REST is the type of each actual argument, not the type of the corresponding
lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must be
LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp
implementations currently ignore FUNCTION type declarations. The only examples
found so far are in a text book on Common Lisp, which follows the proposed
syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do so.
Probably only a small amount of code would have to be written/changed in
implementations that currently think that the &REST argument should be LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must be
LIST will have to change their code. However, because this issue is so unclear,
the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited
use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the
FUNCTION type specifier mirrors
normal lambda-list syntax, it would be cleaner and less confusing to provide the
type of the lambda variable rather than the type of the actual arguments.
However, considering the types specified in the FUNCTION specifier to be the
types of the actual arguments rather than the types of the parameters as seen on
the receiving end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee. There was some
support for an alternative proposal to require that the &REST argument
declaration, if any, always be LIST or a subtype of LIST, and to extend the LIST
type to allow declarations of the form, e.g., (LIST NUMBER).
Those who favor USE-ACTUAL-ARGUMENT-TYPE (including David Moon and Larry
Masinter) argue that the simplicity of the declarations and the ugliness of the
alternative, as well as the weight of current practie, argue for it.
Kent Pitman has argued against this proposal on the following grounds:
* It is bothersome that the same argument declarations which are
used internally in the function would not be be usable externally.
* It is unfair to provide only this special-purpose way of
declaring a sequence type when in fact there are numerous other places
in the language where it might be useful to declare a sequence type.
If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly
(if it is not already in CLtL somewhere) that the following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
since there will be no way to type-declare this. Even though this is an
obscure case (that doesn't even work in some implementations), it's the
sort of thing that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.
∂13-Feb-88 1615 CL-Cleanup-mailer Issue: FUNCTION-TYPE (version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:15:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 16:15:39 PST
Date: 13 Feb 88 16:14 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 9)
TO: CL-CLEANUP@SAIL.STANFORD.EDU
LINE-FOLD: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <880213-161539-10473@Xerox>
I've left the CONSERVATIVE proposal pretty much intact, and attempted to add back in the STRICT-REDEFINITION proposal as an alternative proposal with a shared cost/benefit analysis.
We really owe X3J13 a version they can vote on, and I think that this is one issue that is big enough and thorny enough that we can ask for votes on more than one alternative.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: COMPATIBLE CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
Proposal FUNCTION-TYPE:CONSERVATIVE
1. Introduce a new type PROCEDURE that can be used both for declaration
and discrimination.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and PROCEDURE
are pairwise disjoint. In particular, a list may not be used
to implement any PROCEDURE subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of PROCEDURE.
Implementations are free to define other subtypes of PROCEDURE.
1c. Introduce a new function, PROCEDUREP, such that
(PROCEDUREP x) == (TYPEP x 'PROCEDURE).
2. Define that a ``function'' may be a procedure, a list whose car is
the symbol LAMBDA, or any symbol (whether fbound or not).
2a. Clarify that the FUNCTION type behaves as if it had been
defined by:
(DEFUN LAMBDA-P (X) (AND (NOT (ATOM X)) (EQ (CAR X) 'LAMBDA)))
(DEFTYPE FUNCTION ()
`(OR SYMBOL (SATISFIES LAMBDA-P) PROCEDURE))
2b. Clarify that (FUNCTIONP x) == (TYPEP x 'FUNCTION).
This change is compatible.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Clarify that FUNCALL and APPLY continue to accept functions
as arguments. However, some implementations may produce better
code for expressions such as (FUNCALL (THE PROCEDURE ...) ...)
or (APPLY (THE PROCEDURE ...) ...).
3. Clarify that the result of a FUNCTION special form must be a procedure.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE PROCEDURE (FUNCTION name)). As such, the potential
optimizations mentioned in 2e are also possible for
(FUNCALL (FUNCTION ...) ...) and (APPLY (FUNCTION ...) ...).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarifythat it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(PROCEDUREP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error,
but they are also permitted to define useful (non-portable)
interpretations.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
Implementations are permitted, but not required, to store
information about a global macro-function or special form
in the function cell. This definition of SYMBOL-FUNCTION
is intended to leave enough freedom for such implementations
to conveniently implement FUNCTION, SPECIAL-FORM-P, and
MACRO-FUNCTION using SYMBOL-FUNCTION as the underlying
subprimitive.
6. COERCE is extended to allow objects to be coerced to type procedure.
6a. (COERCE symbol 'PROCEDURE) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'PROCEDURE) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify *MACROEXPAND-HOOK* is permitted to contain any kind of function.
The function is coerced to a procedure before being called as the
expansion interface hook by MACROEXPAND-1.
!
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
STRICT-REDEFINITION is similar to CONSERVATIVE, except that it redefines
the type FUNCTION instead of adding a new type PROCEDURE, and it restricts
coercion by functions that take functions as arguments. The numbering of
CONSERVATIVE is preserved for comparison.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any PROCEDURE subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
with CAR = LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Change FUNCALL and APPLY such that they accept only a function
as the functional argument. This restriction is inherited by
all functions in Common Lispthat take a functional argument.
It is no longer legal to pass a symbol or lambda expression as
the functional argument to any of these functions; to do so
"is an error".
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(FUNCTIONP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type procedure.
6a. (COERCE symbol 'FUNCTION) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'FUNCTION) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the
expansion interface hook by MACROEXPAND-1.
!
Rationale:
Since the two proposals are similar, they are discussed together. Where
motiviation and justification differ, the proposals are referred to by
name (STRICT-REDEFINITION, CONSERVATIVE.)
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
CONSERVATIVE manages a compatible definition with most existing uses of
the term ``function'' while providing a graceful upgrade path to the term
``procedure'' for use in situations that call for a higher degree of clarity.
STRICT-REDEFINITION avoids introducing a new term at the cost of
incompatible change.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is the same as (FUNCTIONP x).
In some implementations, (TYPEP x 'FUNCTION) is the same as what this
new proposal calls (TYPEP x 'PROCEDURE).
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations are likely to have exactly the
semantics described in either. CONSERVATIVE is more compatible with
current practice than STRICT-REDEFINITION, however.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations. While STRICT-REDEFINITION makes it an error to pass
non-function arguments to APPLY, FUNCALL etc, there is no requirement
to check for that error.
Compiled functions are true functions in almost all current
implementations, but in some implementations interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, such lists would have to be changed to be procedures
(implemented either as structures or to some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The conversion cost associated with CONSERVATIVE is very low because the
model of FUNCTIONP which it takes is largely consistent with existing
practice.
The new features introduced by CONSERVATIVE, particularly the PROCEDURE
data type, can be converted to fairly lazily.
The conversion cost for the STRICT-REDEFINITION proposal is higher. The
changes to FUNCTIONP and the FUNCTION type declaration is relatively easy
to deal with. However, the strict redefinition of FUNCALL, APPLY and
functional arguments will require the addition of an explicit coercion
would have to be added whenever a symbol or lambda expression is used as
a functional argument. Many such cases can be identified at compile time,
but not all.
Some implementations might provide tools to assist in detecting implicit
coercion of symbols to functions. For example, an implementation might add
run-time test in which the implementation still does the coercion but that
issues a warning message whenever the coercion is actually needed.
Alternatively, a "smart" code-walker or editor macro might find all of the
calls to FUNCALL, APPLY, and the 61 Common Lisp functions that take :TEST
or :KEY arguments and, if the argument is not already an explicitly quoted
FUNCTION form, wrap a COERCE around the body.
For either proposal:
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell might have to change. Such code was
already not portable, however, since some implementations signal an error
when this is done.
Benefits:
For CONSERVATIVE:
The term ``function'' would be given a useful meaning that was relatively
compatible with existing usage.
A new term ``procedure'' would be available for descriptional clarity.
The new PROCEDURE datatype would be useful for type discrimination in CLOS.
For STRICT-REDEFINITION:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
STRICT-REDEFINITION provides useful constraints which will be of aid to systems
doing automatic program analysis for the purpose of ``selective linking.''
Such tools may in turn make it possible to reduce the total size of a
delivered application program because only those Common Lisp functions
that are actually called need to be included.
For either proposal:
The type hierarchy would be simplified.
Either proposal brings Common Lisp into closer alignment with Scheme and
the work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with this proposal.
Aesthetics:
Both proposals improve the aesthetics of the language.
Discussion:
These proposals have been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. These two proposals are the distillation of the alternatives.
The CONSERVATIVE proposal offers the advantage of backward compatibility,
and considerably more flexibility in the language.
The STRICT-REDEFINITION proposal offers the advantage of a slightly cleaner
resulting language.
Some concerns were raised about STRICT-REDEFINITION in a previous discussion
about "late binding" of function definitions. Neither proposal disallows
late binding of symbols to functions. For example, in the call
(MAPCAR #'FROB my-list)
the effect of the FUNCTION special form (as generated by the #' read macro)
is to obtain the function definition of FROB at the time the #'FROB is
evaluated. Neither proposal changes this.
Currently, it is allowed to write
(MAPCAR 'FROB my-list)
while this form would no longer be allowed under the STRICT-REDEFINITION
clause. Currently, neither CLtL nor the CONSERVATIVE proposal addresses
the question of the time at which FROB's function definition is obtained;
if, during the processing of my-list, FROB is redefined, it is not clear
whether the processing of subsequent elements would be changed.
∂13-Feb-88 1630 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:30:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 16:28:49 PST
Date: 13 Feb 88 16:28 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
to: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <880213-162849-10481@Xerox>
very minor edits here
!
Issue: REDUCE-ARGUMENT-EXTRACTION
References: REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313)
Category: ADDITION
Edit history: Version 1 by Pierson 5-Dec-87
Version 2 by Pierson 30-Dec-87
Version 3 by Masinter 13-Feb-88
Problem description:
REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword described as
follows:
If a :KEY argument is supplied, its value must be a function of one
argument which will be used to extract the values to reduce. The :KEY
function will be applied exactly once to each element of the sequence
in the order implied by the reduction order but not to the value of
the :INITIAL-VALUE argument, if any.
Test Cases/Examples:
Using REDUCE to obtain the total of the ages of the possibly empty
sequence of astronauts ASTROS, would currently require:
(REDUCE #'+ (MAP 'LIST #'PERSON-AGE ASTROS))
If this proposal is adopted, the same result could be obtained without
creating a new list by:
(REDUCE #'+ ASTROS :KEY #'PERSON-AGE)
Rationale:
This proposal makes many common situations where REDUCE would be useful
much less cumbersome.
Current practice:
We know of no implementation which currently supports this feature.
Cost to Implementors:
This will require most implementations to make a trivial modification
to REDUCE. Implementations which wish to use this as an opportunity to
further optimize compiled calls to REDUCE will have to undertake more
work (which would be much more difficult today).
Cost to Users:
None, this is an upward compatible extension.
Cost of non-Adoption:
REDUCE will continue to be more difficult to use than other sequence
functions on sequences of complex objects.
Benefits:
REDUCE will become easier to use on sequences of complex objects. It
will be easier for compilers to convert some calls to REDUCE into
efficient loops.
Aesthetics:
Slightly damaged in one way. All :KEY arguments are currently defined
to be used for predicates, this proposal will implicitly broaden :KEY
to support general extraction for any purpose.
Slightly improved in another way. Many common situations where REDUCE
could be used would be easier to write and easier to later read.
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
There is some controversy over whether the "definition" of :KEY
arguments on page 246 of CLtL really constitutes a definition or just
an "unwritten rule".
∂13-Feb-88 1640 CL-Cleanup-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:39:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 16:39:54 PST
Date: 13 Feb 88 16:39 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <880213-163954-10487@Xerox>
This is another version that I apparently neglected to mail out.
!
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261)
Issue REMF-DESTRUCTURING-UNSPECIFIED
(discussion of NREVERSE, NSUBSTITUTE)
Issue AREF-1D
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky
28-Apr-87, Version 2 by Pitman (variations on the theme)
26-Oct-87, Version 3 by Masinter (clean up for release)
11-Nov-87, Version 4 by Masinter (respond to comments)
5-Feb-88, Version 5 by Masinter
Description:
Common Lisp provides many useful operations on lists and vectors which don't
apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can REPLACE
the contents of one vector with another, but one can't do this for arrays. One
can verify that EVERY element of a vector has some property, but one can't do
this for arrays, and so on.
The programmer who wishes to use arrays instead of vectors must give up most of
the useful tools CLtL provides for manipulating sequences, even though there is
no intuitive reason why operations like FILL, REPLACE, and EVERY shouldn't work
on arrays.
Common Lisp already provides a facility called "displaced arrays" which can be
used to overlay one array on top of a portion of another, even if the two are of
different ranks, so that the two share storage or use the awkward convention of
creating a displaced array to the operand. However, creating a displaced array
merely to perform FILL, REPLACE or EVERY is awkward.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):
1) Extend the definitions of sequence functions that either return their
argument sequences or return non-sequences so that they also allow arrays of
rank other than 1. These functions should treat array arguments as vectors
displaced to the array storage (in row-major format). The affected functions are
LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY, NOTEVERY, REDUCE,
SEARCH, MISMATCH, FILL, REPLACE, SORT.
For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42, and (ELT A
7) should return the same element as (AREF A 0 1 0). :START and :END keywords
would be interpreted relative to the vector, as would the results returned by
POSITION and SEARCH.
2) Extend the definitions of sequence functions whose result should be the same
shape as but not necessarily EQ to some argument. These functions should deal
with array arguments by returning an array of the same shape as the argument,
and operate on their argument in row-major order. The affected functions are
SUBSTITUTE, NSUBSTITUTE, REVERSE, NREVERSE, SUBSTITUTE-IF, NSUBSTITUTE-IF,
SUBSTITUTE-IF-NOT, NSUBSTITUTE-IF-NOT and MAP.
3) Sequence functions that modify the number of elements in the array remain
unchanged: it is an error to pass arrays of rank other than 1. (The functions
are not extended because the shape would be undefined.) The unaffected functions
are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE,
DELETE-DUPLICATES.
Note that EQUALP does -not- treat arrays as vectors. It is not a sequence
function, and it already has a well-defined behavior for arrays. To test whether
the arrays A and B, of different shapes, have the same elements, one might
write:
(AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).
Rationale:
This is a useful upward compatible extension with relatively low adoption cost.
Cost to implementors:
This would involve a lot of changes to functions, but all of the changes are
likely to be minor. The presence of displaced arrays in the language already
guarantees that the internal storage format needed to back up these proposed
changes is already in place.
Cost to Users:
This change is upward compatible; current user code should run unmodified.
Benefits:
This proposal adds natural support for multi-dimensional arrays. Currently,
users must write nested DO loops every time they want to perform an array
operation equivalent to FILL, REPLACE, REDUCE, etc., or else they buld
displaced vectors by hand and pass them to the sequence functions when
necessary. With this proposal, users of arrays do not have to use home-grown
utilities to duplicate functionality already primitively provided to users of
arrays. The sequence functions become useful in a variety of new situations.
Aesthetics:
This proposal extends sequence functions to cover arrays while neatly avoiding
the temptation to turn Common Lisp into a half-baked APL. Instead of trying to
provide a full set of array handling primitives (which would be needed to take
arbitrary k-dimensional slices out of n-dimensional arrays, or to apply an
operator across a specific dimension of a multidimensional array), it requires
just one rule:
treat arrays as displaced vectors where it is well-defined.
Current Practice:
We know of no current implementation of this proposal.
Discussion:
This issue was discussed by the cleanup committee at length; what follows is
only a brief summary of the discussion.
An alternative considered was to only affect those functions which didn't
explicitly depend on the shape of the array; that is, to modify COUNT, SOME,
EVERY, NOTANY, NOTEVERY, FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP, and
expressly forbid arrays as arguments to other sequence functions, including
LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH, MISMATCH, REVERSE, NREVERSE, SORT,
MAP, as well as SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES,
DELETE, DELETE-DUPLICATES. This would be less controversial, since it includes
only those functions which do not deal with positional information. Some hedging
over REDUCE and FIND, which often have non-positional uses, were considered.
Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE. He's been
building displaced vectors to pass to sequence functions when necessary and
really dislikes it.
We considered but discarded as unworkable an alternative where POSITION and FIND
might deal with "positions" as lists of array subscripts.
At one point, this proposal included an extension to COERCE to allow COERCE to
translate from array types to sequences, but it was thought better to separate
out COERCE. We considered a proposal to only introduce a change to COERCE, and
require users who want to operate on arrays explictly perform, e.g., (COUNT
item (COERCE x 'SEQUENCE)). This alternative would have the lowest adoption cost
but was deemed awkward.
Sequence functions like FILL and COUNT are already generalized to arrays in
non-Lisp contexts; in English we use the generalized forms all the time, e.g.,
"count the number of 1's in this matrix."
There is some concern that this proposal makes the requirement for row-major
ordering of internal storage for arrays even more evident. While such an
internal ordering is implied by the ability to create displaced arrays and the
AREF-1D proposal, this proposal adds yet another constraint.
The general reason for opposing this change is that it adds more mechanism than
it is worth. The general reason for liking it is that it adds generality at
little cost.
∂13-Feb-88 1713 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:13:05 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:13:05 PST
Date: 13 Feb 88 17:12 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
To: cl-cleanup@Sail.stanford.edu, Hornig@SCRC.Symbolics.COM
Line-fold: 80
cc: Masinter.pa@Xerox.COM
Message-ID: <880213-171305-10510@Xerox>
As this issue is somewhat controversial, it is not for inclusion in the mailing.
I tried to at least go back and extract what I thought were David's previous
arguments about this proposal and include them in the discussion section.
Its been almost a year now since this was first brought up... we should get some
closure soon.
!
Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
References: UNWIND-PROTECT (p140, p142, p39)
Issue IGNORE-ERRORS, Draft error proposal.
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 27-Feb-87
Version 2 by Masinter 24-Oct-87
Version 3 by Masinter 27-Oct-87
Version 4 by Masinter 13-Feb-88
Problem Description:
If a non-local return is done while in the cleanup form of an UNWIND-PROTECT,
the behavior is not always well-defined.
There are three basic cases:
Situation 0. Transfer to another point within the cleanup form.
(UNWIND-PROTECT 3 (BLOCK NIL (RETURN 4)) (PRINT 'XXX))
There is no ambiguity about how this form is to be interpreted.
Effectively:
. 3 evaluates to itself, which is queued for return
from the UNWIND-PROTECT.
. The BLOCK expression is entered, 4 is returned to
it and discarded because this is a not-for-value
situation.
. XXX is printed, XXX is returned by the PRINT and
that value is discarded because this is a not-for-value
situation.
. The 3 which was yielded earlier is retrieved and
returned as the value of the UNWIND-PROTECT.
Situation 1. Transfer to a point inside the point to which control
would have transferred.
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
This is a subject of controversy because:
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. Disagreement exists as to whether it is an error if the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found within the scope of the target of the
pending THROW (to FOO).
Situation 2. Transfer to a point outside the point to which return would
already have been. For example:
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
This is a subject of controversy because:
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. Disagreement exists as to whether it is an error if the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found outside the scope of the target of the
pending THROW (to FOO).
What is the appropriate behavior for situation 1 and situation 2 and similar
ones? For example, suppose that when WITH-OPEN-FILE tries to close the file upon
unwinding, it signals an error, and the condition handler also attempts to
throw? The question applies to all non-local transfers, whether performed by
THROW, RETURN-FROM, RETURN, GO.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:CONTINUATION-MODEL):
In all cases, a transfer of control within an UNWIND-PROTECT cleanup form to a
point outside of the UNWIND-PROTECT causes the original control transfer which
initiated the execution of the cleanup forms to be abandonded.
During the execution of the cleanup forms of an UNWIND-PROTECT a non-local exit
to a point outside of the scope of the UNWIND-PROTECT, but still within the
dynamic scope of of the target of the original non-local exit succeeds, and the
original pending exit is discarded. For example, in Situation 1, the pending
seek for tag FOO is discarded by the second THROW to BAR and the value 4 is
transfered to (CATCH 'BAR ...), which returns 4. The (CATCH 'FOO ...) then
reurns the 4 because its first argument has returned normally. XXX is not
printed.
Where an UNWIND-PROTECT cleanup form attempts a non-local exit to a point
outside the original non-local exit, control is passed to the outer exit (and
the pending original non-local exit is discarded.) For example, in Situation 2,
the value 4 is returned from the (CATCH 'BAR ...); XXX is not printed.
In no case will UNWIND-PROTECT cleanup forms ever be attempted more than once.
Rationale:
The primary issues have to do with the safety of the language vs. the uniformity
of the model behind non-local transfer of control.
Current Practice:
Some implementations generate garbage code in situations 1 and 2. Some have
differing behavior compiled and interpreted.
Most that have implementations seem to implement the proposed semantics for
situation 2, but there is some divergence in Situation 1. For example, Spice
Lisp and Xerox implement the proposed semantics, while Symbolics Common Lisp
signals an error.
Adoption Cost:
While require some compiler modifications in some implementations, in most
cases, that work was in order anyway since compilers may currently be doing
nothing particularly useful or defensible with the code in question.
Benefits:
Having this situation uniformly treated seems critical:
Programs that do this accidentally should behave the same on all systems so that
bugs can be detected and fixed very early rather than being found later on a
system which disagrees.
Programs that do this on purpose generally are trying to do something fairly
intricate and really need to be able to depend on it being uniformly treated. A
portable error/signal system and debugger may be among these. For example, one
programmer created his own "top level", to which the system "abort" character
would return, by doing:
(DEFUN MY-TOPLEVEL ()
(TAGBODY LOOP (UNWIND-PROTECT (REALLY-MY-TOPLEVEL)
(GO LOOP))))
Aesthetics:
This proposal is more intuitive to programmers who reason about programs in
terms of continuation passing. It falls out of the normal scoping rules as a
consequence of the fact that the cleaup code is evaluated in the lexical and
dynamic environment in which the UNWIND-PROTECT form appears. The action of
THROW is usefully described by saying that it is just like any other function.
It happens to discard the current continuation, run some cleanup things (like
variable unbindings and UNWIND-PROTECT actions), and transfer control elsewhere
in the program. In doing so, the function uses data structure primitives not
generally available to other programs, but it is not linguistically different
and receives no special exemption with regard to THROWs or other non-local
transfers of control done within its execution. A THROW from within an
UNWIND-PROTECT cleanup is not different than one in any other code; it discards
the ongoing action (stack unwinding) and replaces it by another action (as it
happens, another stack unwinding). The previous unwind is never resumed.
Conversion Cost:
Most user programs don't do this so the cost of converting existing code is
probably minimal. (There is some evidence that there are programs that expect
this behavior, so there is no conversion cost for those programs.)
Discussion:
Two alternatives for situation 2 were seriously considered: that it should
signal an error, and that it the second non-local exit instead continues the
original (more extensive) one; e.g., in Situation 1, the second THROW to BAR
would be discarded in lieu of continuing the THROW to FOO.
Either of these alternatives would help prevent users from (either intentionally
or unintentionally) creating situations where it is impossible to abort a
computation with a THROW or other non-local return (e.g., an interrupt
implemented via THROW.)
For example, given
(LOOP
(CATCH 'FOO
(UNWIND-PROTECT (LOOP)
(THROW 'FOO T))))
With this proposal there is no way of exiting such a form. Signalling an error
would prevent programmers from getting into this unfortunate situation.
However, similar "unstoppable" loops can be created, without resorting to
non-nested non-local transfers within UNWIND-PROTECT clauses; for example:
(LABELS ((HA () (UNWIND-PROTECT (LOOP) (HA)))) (HA))
While it would be for a programmer to accidentally create such an unstoppable
loop, the user has pretty clearly asked to have a loop that cannot be exited and
deserves to have that request carried out.
One implication is that it is likely that programming environments need to
provide some mechanism other than THROW to stop a truly run-away computation.
An interesting example which supports this proposal is one where there are two
BLOCKs
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated interchangably,
signalling an error in this situation would be inappropriate.
To quote Guy Steele:
"We have here a classic case of the irresistible force (QUIT, dammit!)
versus the immovable mountain (UNWIND-PROTECT). I find that the
suggestion that situation 1 produce an error, but one that IGNORE-ERRORS
won't ignore, to be at least one level of epicycle too many.
Which mechanism are to we regard as primitive: the error system or the
catch/throw system? Or are they disjoint? I prefer, for simplicity, a
model in which the error system can be explained. as much as possible, as a
complex thing built on top of catch, throw, and unwind-protect."
David Moon says:
"Of the several alternative proposals for this issue, the only one
that seemed appropriate to me has been removed. After re-reading the
12 messages on the topic that I thought were worth saving, I get the
feeling that the issues have not really been clarified and that the
discussion is largely dealing with strawmen. It seems like the
cleanup committee is heading towards making a serious mistake here.
Consider the form
(loop
(catch 'foo
(unwind-protect (loop)
(throw 'foo t))))
With the proposed semantics, it is impossible to stop this program
except by hitting it with two throws in rapid succession, with exactly
the right amount of delay between them so that the catch and
unwind-protect have not yet been re-established when the second throw
strikes. Consider any program-stopping operation that aborts execution
by throwing to a catch in the top-level read-eval-print loop (control-G
in Maclisp or c-Abort in Genera; most other systems have their own
equivalent of this). With the proposed semantics, when this throw
executes the unwind-protect cleanup handler, as it must, the throw will
be abandoned and execution will resume looping.
To me, the inability to stop a program is a much worse problem than
providing so-called correct semantics for a contrived program that
doesn't correspond to any real application. It was suggested that the
error system might depend on the ability to abort throws like this. If
that were demonstrated, I would change my tune, but until it's
demonstrated I am completely skeptical of the notion that any error
system would do this."
∂13-Feb-88 1720 CL-Cleanup-mailer New issues to be mailed to X3J13
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:20:38 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:21:25 PST
Date: 13 Feb 88 17:21 PST
From: Masinter.pa@Xerox.COM
Subject: New issues to be mailed to X3J13
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880213-172125-10516@Xerox>
These versions have not been distributed before:
- ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87)
(Interaction of ADJUST-ARRAY and displaced arrays)
- APPEND-DOTTED (Version 5, 14-Jan-88)
(What happens to CDR of last CONS? in other
than last arg?)
- ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87)
(Extend ASSOC-IF, etc. to allow :KEY)
- COMPILER-WARNING-BREAK (Version 4,23-Nov-87 )
(Does *BREAK-ON-WARNING* affect the compiler?)
- DECLARE-MACROS (Version 3, 5-FEB-88)
(Disallow macros expanding into declarations.)
- DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87)
(Documentation string is not evaluated.)
- DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88)
(DISASSEMBLE doesn't smash the def if not compiled)
- DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87)
( DO-SYMBOLS can the same symbol twice?)
- DRIBBLE-TECHNIQUE (Version 1)
(dribble can't be used programmatically)
- FLET-DECLARATION (Version 2, 2 Feb 88)
(Allow declarations in FLET, MACROLET)
- FORMAT-COLON-UPARROW-SCOPE (Version 3, 5 Feb 88)
(what iteration does ~:↑ exit from?)
Common-Lisp mailing list discussion Nov 87
- FUNCTION-TYPE-KEY-NAME (Version 3, 5 Feb 88)
(allow &KEY (:KEYNAME type)) in FUNCTION decls )
- FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88)
(allow &rest <type> in function types to refer to element
type)
- FUNCTION-TYPE (Version 9, 13-Feb-88)
(Change definition of FUNCTIONP, function type ...)
- PATHNAME-SYMBOL (Version 5, 5-Feb-88)
(Do symbols automaticly coerce to pathnames?)
- PUSH-EVALUATION-ORDER (Version 5,25-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
- REDUCE-ARGUMENT-EXTRACTION (version 3, 13-Feb-88)
(Add :KEY to REDUCE)
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5, 5-Feb-88)
(let FIND, SUBSTITUTE etc work on multi-dimensional arrays)
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
(What does SHADOW do if symbol is already there?)
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
( *FEATURES* are in the keyword package)
∂13-Feb-88 1722 CL-Cleanup-mailer Old issues for confirmation at March X3J13
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:22:31 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:23:16 PST
Date: 13 Feb 88 17:22 PST
From: Masinter.pa@Xerox.COM
Subject: Old issues for confirmation at March X3J13
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880213-172316-10518@Xerox>
These issues were already passed at previous meetings. However, I expect that
there will be an opportunity for a more formal vote at the March X3J13 meeting.
- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed X3J13/Jun87
Version 7 passed X3j13/Nov87
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Version 1 passed X3J13/Nov87
- COMPILER-WARNING-STREAM (Version 6, 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87
- DEFVAR-INIT-TIME (Version 2, 29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
- DEFVAR-INITIALIZATION (Version 4, Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
- FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
- FORMAT-ATSIGN-COLON (Version 4, 5-jun-87)
(@: == :@ in format)
Version 4 passed X3J13/Jun87.
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Version 2 passed X3J13/Nov87
- FORMAT-OP-C (Version 5, 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 passed X3J13/Nov87.
- IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Version 8 passed X3J13/Nov87
- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Version 6 passed X3J13/Nov 87
- PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
∂13-Feb-88 1726 CL-Cleanup-mailer Pending issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:26:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:26:21 PST
Date: 13 Feb 88 17:25 PST
From: Masinter.pa@Xerox.COM
Subject: Pending issues
to: cl-cleanup@Sail.stanford.edu
Message-ID: <880213-172621-10520@Xerox>
Be prepared to discuss these issues at the cleanup subcommittee meeting Tuesday.
Since our time is limited, you should come prepared. I expect discussion to be
limited at the subcommittee meeting on Tuesday, but that we'll have some
opportunity to find out at least who has opinions on any of these issues.
- ADJUST-ARRAY-FILL-POINTER
(Interaction of Adjust-ARRAY and fill pointers.)
Need volunteer to write up.
- CONSTANT-SIDE-EFFECTS (not yet submitted)
(It is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Will take on if no compiler proposal
- DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
- DECLARATION-SCOPE (Version 2, 2-Feb-88)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
*FOR DISCUSSION MARCH 1988*
- DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS)
(Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e.,
not a subclass.)
Useful after CLOS
- DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
Interacts with compiler proposal?
- DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- EQUAL-STRUCTURE (not yet submitted)
(Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.)
What do EQUAL EQUALP and friends do
on structures?
(ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu,
Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU)
- FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just
an open file-stream. Let it take a keyword argument :ELEMENT-TYPE,
defaulting to STRING-CHAR for non-stream arguments and to the
element-type of the stream for a stream argument."
Need volunteer to write up.
- FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Awaiting error proposal.
- FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
need volunteer.
- FUNCTION-ARGUMENT-TYPE-SEMANTICS (not yet submitted)
I'm hoping to get this one out when I get back, but I know its hopeless.
Maybe I can mail it out *not* in time for a letter ballot but
in time for discussion.
- FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace etc)
Mail from Moon 6-Jun.
cf SETF-FUNCTION-VS-MACRO.
(SMH!franz@ucbarpa.berkeley.edu, JonL, RWK)
- GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
- LAST-N (version 1, 4-DEC-87)
(Extend LAST to take an optional N)
Needs rewrite as per Moon
- LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
Merge with SPECIAL-FORM-SHADOW
Needs volunteer
- LOAD-TIME-EVAL (Versin 4, 2 Feb 88)
(evaluation when compiled file is loaded)
- MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
re-extracted from ENVIRONMENT-ARGUMENTS
CLOS committee to submit?
- PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
make :DIRECTORY a list?
Need volunteer to rewrite.
- PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components, etc
in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
- PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal
interaction must or even ought to work."
- PROCLAIM-LEXICAL (Version 5, 14-Nov-87)
(add LEXICAL, GLOBAL, CONSTANT proclaimation)
some serious problems
- PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
- REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 )
(Specification of side-effect behavior in CL)
DEFINED, VAGUE and IN-BETWEEN
Not ready for release
- REMF-MULTIPLE (Version 1, 26 Jan 88)
(What does REMF do if it sees more than one INDICATOR?)
Withdraw?
- REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
Doesn't really solve our problems?
- REST-LIST-ALLOCATION (not yet submitted)
(APPLY #'LIST X) == (COPY-LIST X)?
need volunteer
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
- SETF-SUB-METHODS (version 1, 12-Feb-88)
- SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
Tabled
- SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
- SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
- STANDARD-INPUT-INITIAL-BINDING (Version 1, 19 Jan 88)
Move text of Test case/Example to Problem description.
Somewhere between completely undefining and current situation is
wanted.
- STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc
were CLOS classes?
Need volunteer
- STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Need volunteer to write up
- SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end
of the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array
out-of-bounds.)"
Need volunteer to write up
- TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
- TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
? Ready for release?
- UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87)
(What happens with non-local exits out of UNWIND-PROTECT
cleanup clauses?)
Not ready for release
- VECTOR-PUSH-EXTEND-DEFAULT (no proposal yet)
CLtL says that vectors are extended by a "reasonable" amount. What's that?
∂13-Feb-88 1732 CL-Cleanup-mailer Withdrawn issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:32:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:33:21 PST
Date: 13 Feb 88 17:32 PST
From: Masinter.pa@Xerox.COM
Subject: Withdrawn issues
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880213-173321-10526@Xerox>
I am removing these issues from the list of ones that I will report status on.
This does not preclude someone from resubmitting them, but these have been
dropped. I hope this doesn't cause anyone too much pain.
- ADJUST-ARRAY-NOT-ADJUSTABLE (Version 1, 22-Apr-87)
(ADJUST-ARRAY on non-adjustable arrays returns copy)
extend COPY-ARRAY instead?
Tabled until resubmitted
- DEFINITION-FUNCTIONS (no formal proposal)
(Extensions for documentation-type for delete-definition
for type FUNCTION, VARIABLE, TYPE. )
Rough draft mailed 9-Oct-87.
JonL may mail something.
- EVAL-DEFEATS-LINKER (Version 1, 12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE
Wait on FUNCTION-TYPE, LOAD-TIME-EVAL
Propose #., #, changes independently.
- EXPORT-COORDINATION (no formal proposal)
Add new macros for defining, export at same time
Too many interactions with package system
- EXPORT-IMPORT
EXPORT doesn't do an IMPORT. The book says so, just not
in the right place.
- IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions
- IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Awaiting error proposal
- KEYWORD-KEYWORDS (version 1)
(Change &REST to :REST)
- OPEN-KEYWORDS (Version 1, 17-Jul-87)
Discussion 9-Nov-87
Questionable; needs stronger justification.
Tabled until resubmitted.
- REQUIRED-KEYWORD-ARGUMENTS
(&REQUIRED-KEY etc?)
- SEQUENCE-EXTREME-SEARCH (not yet submitted)
Want MINIMIZE and MAXIMIZE sequence functions
∂13-Feb-88 1808 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 18:08:15 PST
Received: from Salvador.ms by ArpaGateway.ms ; 13 FEB 88 18:07:49 PST
Date: Sat, 13 Feb 88 18:07:23 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
In-reply-to: <880213-171305-10510@Xerox>
To: cl-cleanup@Sail.stanford.edu, Hornig@SCRC.Symbolics.COM
Message-ID: <880213-180749-10547@Xerox>
With reference to Moon's objections to the given proposal, namely that he wants
a way within his environment to interrupt any loop, no matter how perversely
defined, I remain unconvinced that this is really a language issue. Since the
language does not specify any relationship between user actions (such as pushing
some magic key on the keyboard) and a linguistic effect (such as performing some
throw or other non-local transfer), I cannot accept this argument at the
linguistic level. If you really want this facility in your environment, then
add another operation to the abstract machine of the implementation, a THROW
that can't be overridden by any ``nested'' THROW. Your debugger or whatever can
then be implemented in terms of that (when appropriate) and the language
definition remains clean.
I remain strongly in favor of this proposal; it seems to me to have a
wonderfully simple semantics, easily understood and eassily incorporated into
the programmer's mental model.
Pavel
∂15-Feb-88 0204 CL-Cleanup-mailer Common Lisp cleanup issue status to X3J13
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 02:04:37 PST
Received: by labrea.Stanford.EDU; Mon, 15 Feb 88 02:04:58 PST
Received: from bhopal.lucid.com by edsel id AA27162g; Mon, 15 Feb 88 01:49:09 PST
Received: by bhopal id AA15579g; Mon, 15 Feb 88 01:54:15 PST
Date: Mon, 15 Feb 88 01:54:15 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802150954.AA15579@bhopal.lucid.com>
To: labrea!CL-CLEANUP@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 14 Feb 88 14:54 PST <880214-145515-1510@Xerox>
Subject: Common Lisp cleanup issue status to X3J13
Hmmmm, you did drop DEFINITION-FUNCTIONS off our list of "needs volunteers".
I still would like to take a crack at it if nobody else does. By the bye,
that's a very a misleanding name for what's wanted -- the issue was that of
adding some deletor type functions [e.g. DELETE-DEFSTRUCT, DELETE-PACKAGE,
DELETE-TYPE etc.] for any function which adds to an implicit global data
base. It might be extended more generally a la Interlisp's HASDEF facility
but . . .
This issue, along with a couple dozen others, are on my "back burner" list
of things I'd like to see "cleaned up" [for Lucid's benefit, and for the
benefit of the community at large ] but haven't seen discussed so far on
the list. I'll bring a hardcopy of this list of semi-proposals to the
X3J13 meeting, just in case there isn't enough to do!
-- JonL --
∂15-Feb-88 0928 CL-Cleanup-mailer make-lexical-environment
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 09:28:02 PST
Received: by labrea.Stanford.EDU; Mon, 15 Feb 88 09:28:18 PST
Received: from kent-state.lucid.com by edsel id AA28423g; Mon, 15 Feb 88 09:15:40 PST
Received: by kent-state id AA08272g; Mon, 15 Feb 88 09:20:16 PST
Date: Mon, 15 Feb 88 09:20:16 PST
From: Eric Benson <edsel!eb@labrea.Stanford.EDU>
Message-Id: <8802151720.AA08272@kent-state.lucid.com>
To: cperdue@sun.com
Cc: CommonLoops.PA@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Cris Perdue's message of Sun, 14 Feb 88 16:10:03 PST <8802150010.AA09197@clam.sun.com>
Subject: make-lexical-environment
Redistributed: CommonLoops.PA
Date: Sun, 14 Feb 88 16:10:03 PST
From: cperdue@sun.com (Cris Perdue)
Is the following code adequate for make-lexical-environment (compared
with the code in walk.lisp), and if not, is it inadequate for a good
reason related to the definition of Common Lisp, or just because
implementation quirks of some Lisps? This code is certainly a bit
simpler.
(defmacro current-env (&environment e)
`',e)
(defun make-lexical-environment (form env)
(evalhook
`(,(first form)
,(second form) ; Local macro defns
() ; No declarations, though according to the
; PCL comments, they are illegal here.
(current-env)) ; body of the macrolet
nil nil env))
Thanks for any info on this.
-Cris
In some Common Lisp implementations, the environments used in EVALHOOK
and those used in MACROEXPAND are not compatible. This code would
take an existing EVALHOOK environment and return a MACROEXPAND
environment. The result could not be passed to EVALHOOK again.
Furthermore, some implementations allocate environment objects on the
stack, so returning that object from CURRENT-ENV would result in
garbage. You are probably correct in your assessment that these are
"implementation quirks of some Lisps" and not intrinsic to the Common
Lisp standard. The operative phrase in CLtL is "The hook feature is
provided as an aid to debugging." EVALHOOK (unlike MACROEXPAND) is
part of the programming environment rather than part of the
programming language. This issue should be addressed by the cleanup
committee.
∂15-Feb-88 0954 CL-Cleanup-mailer Re: make-lexical-environment
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Feb 88 09:54:11 PST
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
id AA06452; Mon, 15 Feb 88 09:54:37 PST
Received: from clam.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA15221; Mon, 15 Feb 88 09:46:52 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA10068; Mon, 15 Feb 88 09:55:43 PST
Date: Mon, 15 Feb 88 09:55:43 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8802151755.AA10068@clam.sun.com>
To: edsel!eb@labrea.Stanford.EDU
Subject: Re: make-lexical-environment
Cc: CommonLoops.PA@xerox.com, cl-cleanup@sail.stanford.edu
Just a further note. CLtL, p. 322, does say that the values passed as
the last argument to eval hook functions (or apply hook functions) "are
suitable for the functions evalhook, applyhook, and macroexpand". This
in turn means that these arguments are suitable as the second argument
to a macro expander function. (See the discussion of macroexpand.)
I guess I don't see anything that implies that all environment
objects acceptable to macro expander functions have to be acceptable
to evalhook, though the idea is attractive.
-Cris
∂15-Feb-88 1634 CL-Cleanup-mailer Re: Issue: DO-SYMBOLS-DUPLICATES (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Feb 88 16:34:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 FEB 88 16:30:38 PST
Date: 15 Feb 88 16:29 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: DO-SYMBOLS-DUPLICATES (Version 3)
In-reply-to: Masinter.pa's message of 14 Feb 88 11:37 PST
To: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880215-163038-2296@Xerox>
The rationale contains a type: DO-PACKAGE for DO-SYMBOLS.
-- Andy. --
∂15-Feb-88 1713 CL-Cleanup-mailer Re: Issue: FORMAT-COMMA-INTERVAL (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Feb 88 17:13:42 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 FEB 88 17:14:22 PST
Date: 15 Feb 88 17:14 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: FORMAT-COMMA-INTERVAL (Version 2)
In-reply-to: Masinter.pa's message of 14 Feb 88 12:04 PST
To: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880215-171422-2360@Xerox>
First of all, there is a typo in one of the test cases. (format nil "~19,0,'
,4:B" 3333) should be (format nil "~19,'0,' ,4:B" 3333), i.e., the pad character
should be quoted.
This example is somewhat problematic. Just what is the interaction of "insert
comma characters" and "pad the output with padchar?" If padding is to be added
after the commas are inserted, then the result should be "000001101 0000 0101"
instead of "0000 1101 0000 0101". To produce the latter result, either commas
must be inserted after padding, or somehow both done simultaneously. In this
case does the padding get commas or not? The above example says yes, but this
seems like the wrong answer for the "default" case of (format nil "~20:D"
1234567890) => " 1,234,567,890" (not " , 1,234,567,890"!) Does this need a
separate clarification, ir is the example simply wrong?
-- Andy. --
∂16-Feb-88 0939 CL-Cleanup-mailer FUNCTION-TYPE:STRICT-REDEFINITION proposal
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Feb 88 09:39:23 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA23751; Tue, 16 Feb 88 10:39:08 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA25191; Tue, 16 Feb 88 10:39:04 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8802161739.AA25191@orion.utah.edu>
Date: Tue, 16 Feb 88 10:39:02 MST
Subject: FUNCTION-TYPE:STRICT-REDEFINITION proposal
To: cl-cleanup@sail.stanford.edu
Sections 1a and 6 of this proposal refer to the PROCEDURE type. I
assume this is really supposed to be the FUNCTION type?
Also, I have a question about 1b, where it states that COMPILED-FUNCTION
is a subtype of FUNCTION. Does this imply that it must be a *proper*
subtype? For example, in the Lisp I've been working on sporadically for
my Atari, the interpreted version of (FUNCTION (LAMBDA ...)) returns a
compiled function object (it's a closure which will apply the lambda
expression to the function arguments). Likewise I can conceive of
implementations which compile everything and don't have an "interpreter"
at all. I think this needs to be clarified.
-Sandra
-------
∂16-Feb-88 1139 CL-Cleanup-mailer Re: Issue: FORMAT-COMMA-INTERVAL (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Feb 88 11:39:05 PST
Received: from Salvador.ms by ArpaGateway.ms ; 16 FEB 88 11:33:51 PST
Date: Tue, 16 Feb 88 11:33:48 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FORMAT-COMMA-INTERVAL (Version 2)
In-reply-to: <880215-171422-2360@Xerox>
To: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880216-113351-3592@Xerox>
Grumble. Yeah, I guess Andy's right and the example is bogus. The only way I
can see to get what I wanted is to specify that the padding gets commas inserted
into it if and only if the padchar is a digit in the output base. This is
highly gross, however, so I guess I won't push it. I guess we should just
remove the offending example. Sigh. That example was one of the better uses
for the facility, too...
Pavel
∂17-Feb-88 1159 CL-Cleanup-mailer two minor comments: DISASSEMBLE-SIDE-EFFECT & DRIBBLE-TECHNIQUE
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 17 Feb 88 11:59:26 PST
Date: 17 Feb 88 14:58:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: two minor comments: DISASSEMBLE-SIDE-EFFECT & DRIBBLE-TECHNIQUE
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Before I send more mail, let me state that I have not been following
the cleanup subcommittee mail, so I may be repeating previous arguments.
I'm not on the cl-cleanup mailing list, either, btw.
The comment about what VAX LISP does for DISASSEMBLE-SIDE-EFFECT is
incorrect; we don't modify the function cell of the symbol if the
function is interpreted. I think we changed the behavior when the
mail about this issue first came up, which was several years ago.
DRIBBLE-TECHNIQUE: For a while the way we implemented DRIBBLE made it
impossible to have nested DRIBBLEs. We fixed this problem many years
ago, but at the time a suggested error message was:
No double dribbling allowed.
---Walter
------
∂19-Feb-88 1434 CL-Cleanup-mailer Re: FUNCTION-TYPE:STRICT-REDEFINITION proposal
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Feb 88 14:34:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 FEB 88 14:17:33 PST
Date: 19 Feb 88 14:17 PST
From: Masinter.pa@Xerox.COM
Subject: Re: FUNCTION-TYPE:STRICT-REDEFINITION proposal
In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 16
Feb 88 10:39:02 MST
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880219-141733-9723@Xerox>
"Sections 1a and 6 of this proposal refer to the PROCEDURE type. I
assume this is really supposed to be the FUNCTION type?"
Yes, looks like a typo on my part.
"Also, I have a question about 1b, where it states that COMPILED-FUNCTION
is a subtype of FUNCTION. Does this imply that it must be a *proper*
subtype? For example, in the Lisp I've been working on sporadically for
my Atari, the interpreted version of (FUNCTION (LAMBDA ...)) returns a
compiled function object (it's a closure which will apply the lambda
expression to the function arguments). Likewise I can conceive of
implementations which compile everything and don't have an "interpreter"
at all. I think this needs to be clarified."
I intended not to require that it not be a "proper" subtype in the sense that
there may be no data items that are FUNCTIONP but not COMPILED-FUNCTIONP.
This can be clarified.
∂22-Feb-88 1510 CL-Cleanup-mailer Volunteering
Received: from aai2 (aai2.ISTC.sri.com) by SAIL.Stanford.EDU with TCP; 22 Feb 88 15:10:19 PST
Received: by aai2 (3.2/5.00)
id AA09507 for cl-cleanup@sail.stanford.edu; Mon, 22 Feb 88 15:10:57 PST
Date: Mon, 22 Feb 88 15:10:57 PST
From: Jeff Rininger <jeffr@spam.istc.sri.com>
Message-Id: <8802222310.AA09507@aai2>
To: cl-cleanup@sail.stanford.edu
Subject: Volunteering
Folks:
Could you tell me what is involved with the preparation of "issue writeups" for the issues still under consideration by the cleanup committee ? If the task
is mainly summarizing past correspondence on a particular issue, and putting
the information in the format I have seen distributed in the past, I would
like to volunteer to help.
I'm not what I would consider a "lisp weenie," although I have used the language
for several years, and currently use it for applied AI work here at SRI. If
you feel preparing issue writeups is within my capabilities, and my description
of the task is basically correct, feel free to send me the cogent
correspondence on an "open" issue (your choice) and I'll get started.
- Jeff Rininger
SRI International
∂23-Feb-88 1115 CL-Cleanup-mailer function-type-rest-list-element
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 Feb 88 11:14:22 PST
Date: 23 Feb 88 14:07:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: function-type-rest-list-element
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
We oppose the proposal FUNCTION-TYPE-REST-LIST-ELEMENT:
USE-ACTUAL-ARGUMENT-LIST.
We feel that although specifying the element type in a function
type specifier is slightly more convenient, it is outweighed by
its inconsistency and lack of expressiveness.
If specifying the element type of lists is an important issue,
and we think it is, then we should extend the LIST type to be
a list type:
(LIST [<element-type> [<length>]])
just like for VECTOR. In fact, it would also be wise to
extend SEQUENCE in the same way.
VAX LISP has always made use of FUNCTION type specifiers, although
it has ignored the &REST and &KEY type information.
There's no reason why someone might not write a function type
specifier with &REST being a supertype of LIST. It just can't
conflict with LIST.
The statement in the discussion favoring USE-ACTUAL-ARGUMENT-TYPE
referring to ``the weight of current practice'' itself doesn't have
any weight when previous statements say that function type specifiers
are in limited use and that most implementations ignore them--there
is no ``current practice''.
We agree with Kent Pitman's first two comments (at the end of the
Discussion section), but don't understand his last one.
---Walter
------
∂23-Feb-88 1115 CL-Cleanup-mailer compiler-warning-break
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 Feb 88 11:15:33 PST
Date: 23 Feb 88 14:06:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: compiler-warning-break
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
The proposal COMPILER-WARNING-BREAK:YES leaves a lot of issues unresolved.
As it stands we must oppose the proposal.
The principal problem is that it isn't clear what warnings are.
Currently VAX LISP distinguishes between two different kinds of
``error conditions'': ones signalled during compilation
with ERROR, CERROR, WARN, and the like, and ones detected by the
compiler from examination of the source code being compiled.
The former arise in cases like
(EVAL-WHEN (COMPILE) (PRINT (+ 3 'A)))
or when READ encounters an error while reading a form from the file.
However, when this happens during a COMPILE-FILE, we try to continue
with the compilation, so as to maximize the usefulness and information
generated by the compiler. During COMPILE, the normal error signalling
and handling is in effect, so *BREAK-ON-WARNINGS* would indeed control
``breaking'' upon WARN.
The latter arise when the compiler is compiling a form like
(SEARCH X)
or
(LET 3 (F))
Then we also distinguish these cases by how serious they are. In
particular there are ``errors'' and ``warnings''. However, detecting
these anomalies is expected of the compiler, and thus they are not
treated as ``errors'' or ``warnings'' in the sense of the lisp
functions ERROR or WARN. It doesn't make sense to ``break'' and
go into the debugger if the compiler happens to see a variable that
was bound but was unused (with no IGNORE declaration).
So it isn't clear from the proposal which of these cases are being
addressed. If it's really more to control what happens when one
does a COMPILE, then the proposal should be changed to say that
COMPILE-FILE is not specified as proposed, and what conditions should
be reported as being ``warnings'' should be specified.
---Walter
------
∂23-Feb-88 1414 CL-Cleanup-mailer function-type-rest-list-element
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Feb 88 14:14:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 349602; Tue 23-Feb-88 17:13:00 EST
Date: Tue, 23 Feb 88 17:12 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: function-type-rest-list-element
To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 23 Feb 88 13:07 EST from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Message-ID: <19880223221249.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 23 Feb 88 14:07:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
We oppose the proposal FUNCTION-TYPE-REST-LIST-ELEMENT:
USE-ACTUAL-ARGUMENT-LIST.
We feel that although specifying the element type in a function
type specifier is slightly more convenient, it is outweighed by
its inconsistency and lack of expressiveness.
If specifying the element type of lists is an important issue,
and we think it is, then we should extend the LIST type to be
a list type:
(LIST [<element-type> [<length>]])
just like for VECTOR. In fact, it would also be wise to
extend SEQUENCE in the same way.
But the analogy to VECTOR is false! (VECTOR element-type) does not
mean a vector all of whose current elements are of type element-type.
Nor does it mean a vector constrained such that that all elements
that can be stored into it are of type element-type. The ambiguous
language on CLtL p.47 might lead you to think that's what it means,
but CLtL p.45 makes it clear. For declaration, (VECTOR element-type)
[via (ARRAY element-type (*))] means a one-dimensional array
of the most specialized type that is capable of holding objects of
type element-type. Therefore, unless element-type is STRING-CHAR
or BIT, or a subtype of one of them, this guarantees exactly nothing
about the types of the elements of the vector.
Maybe the element-type argument to these type-specifiers should mean
something else, but that's what it means in Common Lisp as currently
defined.
VAX LISP has always made use of FUNCTION type specifiers, although
it has ignored the &REST and &KEY type information.
There's no reason why someone might not write a function type
specifier with &REST being a supertype of LIST. It just can't
conflict with LIST.
Yes, but I don't see what that could be useful for.
Here's an interesting thought experiment that might shed some light on
what the FUNCTION declaration, and the &REST type specifier nested
within in, might be for. Suppose you had an implementation that thought
materializing &REST arguments as lists was too inefficient, especially
if you didn't bother to do the (fairly simple) flow analysis needed to
figure out that the list has dynamic extent and doesn't have to be
consed in the heap. So in your implementation, you made a new
lambda-list keyword &REST2, which is just like &REST except that the
value to which the parameter variable is bound is a stack-allocated
object of some implementation-dependent type, and the only legal
operations on it are LENGTH2, NTH2, DOLIST2, and APPLY2 (all just like
the standard functions with similar names except that they take one
of these funny objects as an argument where the standard functions
take a list).
The caller of a function doesn't need to know or care whether the
function accepts its arguments with &REST or with &REST2. If the
FUNCTION declaration is for the benefit of callers, then the FUNCTION
declaration should be independent of whether the callee is written with
&REST or with &REST2.
From this I conclude that the &REST type specifier nested within a
FUNCTION declaration shouldn't say anything about lists.
∂24-Feb-88 0715 CL-Cleanup-mailer RE: function-type-rest-list-element
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 88 07:15:01 PST
Date: 24 Feb 88 10:06:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: RE: function-type-rest-list-element
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
But the analogy to VECTOR is false! (VECTOR element-type) does not
mean a vector all of whose current elements are of type element-type.
Nor does it mean a vector constrained such that that all elements
that can be stored into it are of type element-type. The ambiguous
language on CLtL p.47 might lead you to think that's what it means,
but CLtL p.45 makes it clear. For declaration, (VECTOR element-type)
[via (ARRAY element-type (*))] means a one-dimensional array
of the most specialized type that is capable of holding objects of
type element-type. Therefore, unless element-type is STRING-CHAR
or BIT, or a subtype of one of them, this guarantees exactly nothing
about the types of the elements of the vector.
Maybe the element-type argument to these type-specifiers should mean
something else, but that's what it means in Common Lisp as currently
defined.
The discussion of ARRAY type specifiers on p.45 is talking about the
permissible and expected representations of arrays, not of the possible
types of the elements of such arrays. So what's on p.45 doesn't make
anything clear here.
What would you expect to be the type of the result of the following code:
(let ((a ...))
(declare (type (vector foo) a))
(aref a 3))
I believe that in every implementation, the result should be of type FOO,
for any type FOO. What is discussed on p.45 says that A might not be of
type (VECTOR FOO). But this is unrelated to the question of whether
the elements of the array have any particular type.
Setting an element of A to be something that's not of type FOO is
an error. The representation might allow it, because the new value
might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it
correct. It's just a matter of whether the array happened to
remember the precise type it was created with.
I haven't read any clean-up mail, so if you've talked about this
issue and resolved it somehow, please tell me.
There's no reason why someone might not write a function type
specifier with &REST being a supertype of LIST. It just can't
conflict with LIST.
Yes, but I don't see what that could be useful for.
I was just referring to the statement in the first paragraph of the
Discussion: "the &REST argument declaration, if any, always be LIST
or a subtype of LIST..."
Here's an interesting thought experiment that might shed some light on
what the FUNCTION declaration, and the &REST type specifier nested
within in, might be for. Suppose you had an implementation that thought
materializing &REST arguments as lists was too inefficient, especially
if you didn't bother to do the (fairly simple) flow analysis needed to
figure out that the list has dynamic extent and doesn't have to be
consed in the heap. So in your implementation, you made a new
lambda-list keyword &REST2, which is just like &REST except that the
value to which the parameter variable is bound is a stack-allocated
object of some implementation-dependent type, and the only legal
operations on it are LENGTH2, NTH2, DOLIST2, and APPLY2 (all just like
the standard functions with similar names except that they take one
of these funny objects as an argument where the standard functions
take a list).
The caller of a function doesn't need to know or care whether the
function accepts its arguments with &REST or with &REST2. If the
FUNCTION declaration is for the benefit of callers, then the FUNCTION
declaration should be independent of whether the callee is written with
&REST or with &REST2.
From this I conclude that the &REST type specifier nested within a
FUNCTION declaration shouldn't say anything about lists.
One can't expect people to write function type specifiers in Common
Lisp with knowledge about the particular implementation's lambda-list-
keywords. So I agree with you there. But it's the only thing one
could write.
Indeed, there might not be any relationship between the lambda-list
in a function type specifier and the real lambda-list.
(proclaim '(ftype (function (&key (:key1 integer :key2 string)) ...) f))
(defun f (&optional k1 v1 k2 v2) ...)
should be OK if F is always called (F :KEY2 x) and the like.
Presumably the reason for having lambda-list-keywords in function type
specifiers is to indicate the range of number of arguments permissible.
The problem here is in trying to use lambda-list syntax for describing
function calls. Already there's a slight contortion by having the
actual keywords be included in the function type for &KEY arguments.
So it isn't quite as simple as just taking the real lambda-list,
deleting all the init forms and &AUXen, and replacing parameter names
with their types. But I think this way of looking at how function
type specifiers are derived is easier than starting with just a
positional approach (i.e., the second arg, if supplied, has to be of
type X, etc.) and then modifying it to also convey number-of-args and
keyword information. Thus one would prefer having the type specifier
for the &REST argument be the real type specifier for the &REST argument.
---Walter
------
∂24-Feb-88 1013 CL-Cleanup-mailer FUNCTION-TYPE:STRICT-REDEFINITION proposal
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 10:13:28 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 09:35:10 PST
Received: from bhopal.lucid.com by edsel id AA21578g; Wed, 24 Feb 88 10:03:43 PST
Received: by bhopal id AA26979g; Wed, 24 Feb 88 10:09:26 PST
Date: Wed, 24 Feb 88 10:09:26 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802241809.AA26979@bhopal.lucid.com>
To: Masinter.pa@xerox.com
Cc: sandra%orion@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 19 Feb 88 14:17 PST <880219-141733-9723@Xerox>
Subject: FUNCTION-TYPE:STRICT-REDEFINITION proposal
re: I intended not to require that it not be a "proper" subtype in the
sense that there may be no data items that are FUNCTIONP but not
COMPILED-FUNCTIONP.
Lucid Common Lisp distinguishes "compiled" closures which exist for the
purpose of supporting entry into the interpreter from functions which are
truly compiled. It only takes a bit in a header word. If an implementation
really doesn't support an interpreter, then having every function be
COMPILED-FUNCTIONP doesn't sound like much of a loss.
But most implementations in fact do support an interpreter -- which
typically runs code at anywhere from 30 to 600 times slower than when
compiled. Thus it seems reasonable to require COMPILED-FUNCTIONP in
those implementations to be false on, say,
(eval '#'(lambda (x) (list x)))
no matter what underlying technique is used to support interpreter closures.
-- JonL --
∂24-Feb-88 1459 CL-Cleanup-mailer function-type-rest-list-element
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 14:57:43 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 14:19:23 PST
Received: from bhopal.lucid.com by edsel id AA22851g; Wed, 24 Feb 88 13:38:35 PST
Received: by bhopal id AA01988g; Wed, 24 Feb 88 13:44:20 PST
Date: Wed, 24 Feb 88 13:44:20 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802242144.AA01988@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: vanroggen%aitg.decnet@hudson.dec.com, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 23 Feb 88 17:12 EST <19880223221249.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: function-type-rest-list-element
re: Here's an interesting thought experiment that might shed some light on
what the FUNCTION declaration, and the &REST type specifier nested
within in, might be for. Suppose you had an implementation ... [with]
lambda-list keyword &REST2, which is just like &REST except that the
value to which the parameter variable is bound is a stack-allocated
object of some implementation-dependent type, and the only legal
operations on it are LENGTH2, NTH2, DOLIST2, and APPLY2 (all just like
the standard functions with similar names except that they take one
of these funny objects as an argument where the standard functions
take a list).
The caller of a function doesn't need to know or care whether the
function accepts its arguments with &REST or with &REST2.
This "gedanken experiment" isn't hypothetical at all. VAX/NIL, one of
the predecessors of Common Lisp, actually had &RESTV and &RESTL in
addition to &REST. &RESTV guaranteed a stack-allocated VECTOR and,
&RESTL guaranteed a heap-allocated list. &REST was left ambiguous just
so that the user couldn't know which of the two kinds of structures
was being worked upon, and thus couldn't depend upon any accidental
properties.
But at "flag day", few other CL participants saw any value to cluttering
up &rest *lists*.
-- JonL --
∂25-Feb-88 1047 CL-Cleanup-mailer function-type-rest-list-element
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 10:46:56 PST
Received: by labrea.Stanford.EDU; Thu, 25 Feb 88 10:08:28 PST
Received: from bhopal.lucid.com by edsel id AA26191g; Thu, 25 Feb 88 09:13:40 PST
Received: by bhopal id AA05861g; Thu, 25 Feb 88 09:19:28 PST
Date: Thu, 25 Feb 88 09:19:28 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802251719.AA05861@bhopal.lucid.com>
To: vanroggen%aitg.decnet@hudson.dec.com
Cc: Moon@stony-brook.scrc.symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Walter van Roggen's message of Wed 24 Feb 88 10:06:00 EDT
Subject: function-type-rest-list-element
re: The discussion of ARRAY type specifiers on p.45 is talking about the
permissible and expected representations of arrays, not of the possible
types of the elements of such arrays. So what's on p.45 doesn't make
anything clear here.
Well, it's true that CLtL pp45-47 are anything but "clear". But what
Dave is saying (I think) is that a number of wizards have groveled over
those pages and all agree that there is only one interpretation of them
consistent with the rest of CLtL. And that interpretaton is at variance
with your comments:
Setting an element of A to be something that's not of type FOO is
an error. The representation might allow it, because the new value
might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it
correct. It's just a matter of whether the array happened to
remember the precise type it was created with.
Perhaps the clearest indicator that CLtL really isn't saying this is
found on p291, under the description of ARRAY-ELEMENT-TYPE. Note how
this section really is "clear" that an array made by
(make-array 5 :element-type '(mod 5))
may legitimately have an element stored into it that is of type (mod 8)
but not necessarily of type (mod 5).
There was a rather lengthy interchange on this whole topic (about two
months ago?) on the Common-Lisp@SU-AI list. One proposal was to require
implementations to conform with your comments quoted above, but it
certainly didn't seem to have unanimous approval. Someone pointed out
that all current implementations do a form of element-type "upgrading"
on at least some :element-type specifiers. Try it in VAXLISP, for example,
with (SIGNED-BYTE 5) instead of (MOD 5) and see what you get.
If you don't have archives of that mail interchange, I'll can arrange to
send you a copy personally.
-- JonL --
∂27-Feb-88 1818 CL-Cleanup-mailer function-type-rest-list-element
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 18:18:33 PST
Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Sat 27 Feb 88 21:17:29-EST
Date: Sat, 27 Feb 1988 21:17 EST
Message-ID: <RAM.12378202550.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Jon L White <edsel!jonl@LABREA.STANFORD.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU, Moon@SCRC-STONY-BROOK.ARPA,
vanroggen%aitg.decnet@HUDSON.DEC.COM
Subject: function-type-rest-list-element
In-reply-to: Msg of 25 Feb 1988 12:19-EST from Jon L White <edsel!jonl at labrea.Stanford.EDU>
Well, I don't agree with VanRoggen's stand on the &rest type issue,
but I think he is pretty close to the mark about array types. This
isn't inconsistent, since the desirability or feasilibility of a typed
list specifier is pretty unrelated to the &rest issue.
Date: Thursday, 25 February 1988 12:19-EST
From: Jon L White <edsel!jonl at labrea.Stanford.EDU>
To: vanroggen%aitg.decnet at hudson.dec.com
[...]
Setting an element of A to be something that's not of type FOO is
an error. The representation might allow it, because the new value
might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it
correct. It's just a matter of whether the array happened to
remember the precise type it was created with.
Perhaps the clearest indicator that CLtL really isn't saying this is
found on p291, under the description of ARRAY-ELEMENT-TYPE. Note how
this section really is "clear" that an array made by
(make-array 5 :element-type '(mod 5))
may legitimately have an element stored into it that is of type (mod 8)
but not necessarily of type (mod 5).
No, this example doesn't make it clear. If you make an array
:element-type (mod 5), then it is an error to ever store anything in
that array that isn't (mod 5). What the example make clear is that
implementation has discretion to upgrade the element type. A
corollary is that it has discretion to not upgrade the element type.
Since a Common Lisp implementation is free to implement whatever
specialized array types it pleases, Common Lisp programs must assume
that every type potentially has an exact specialization.
The only rationale under which one could store something not (mod 5)
into that array would be that they could make the array, then call
ARRAY-ELEMENT-TYPE to find out that element types it can actually
hold, and then store randomness into it. I don't believe that this is
a reasonable thing to do.
This basically amounts to bogotifying the language in order to make
ARRAY-ELEMENT-TYPE work. This is a bad idea, since I think that the
semantics of ARRAY-ELEMENT-TYPE are just as seriously flawed as the
semantics of TYPE-OF. (which is another flame)
It is much easier to give types a clean semantics in Common Lisp if
ARRAY-ELEMENT-TYPE and TYPE-OF are ignored. For example, without
these functions, there would be no way for users to even know that
"array element type upgrading" exists. (Assuming the array TYPEP
"feature" mentioned in the manual is fixed.)
Rob
∂28-Feb-88 0807 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Feb 88 08:07:33 PST
Received: from Salvador.ms by ArpaGateway.ms ; 28 FEB 88 08:08:05 PST
From: masinter.pa@Xerox.COM
Date: 28 Feb 88 8:07:18 PST
Subject: Issue: COERCE-INCOMPLETE
To: cl-cleanup@sail.stanford.edu
Message-ID: <880228-080805-2138@Xerox>
I'm not really back until next week, but this came in for consideration...
----------
Return-Path: <@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET>
Received: from RELAY.CS.NET by Xerox.COM ; 25 FEB 88 23:39:52 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa07232; 26 Feb 88 2:16 EST
Received: from utokyo-relay by RELAY.CS.NET id aa26262; 26 Feb 88 2:06 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA19019; Fri, 26 Feb 88 15:54:40 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.3Junet-1.0)
id AA12493; Fri, 26 Feb 88 15:55:57+0900
Date: Fri, 26 Feb 88 15:55:57+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8802260655.AA12493@tansei.cc.u-tokyo.junet>
To: ida%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET, masinter.pa
Subject: Coercion
Dear Larry Masinter,
I wrote my opinion on coercion which is attached consulting your suggestion on the format.
Please find and use if you think it is valuable to have.
Masayuki Ida
--------------------------------------------------------------------
Issue: Coerce
Reference: coerce (CLtL p50)
Category: change
Edit history: version 1 by M.Ida, 26-Feb-1988
Problem Description:
--------------------
Problem 1:
Coerce is not symmetric or not generic among data types.
In CLtL, Coerce is defined in page 50 and 51 that,
1) a sequence type may be converted to any other sequence type.
2)Some strings, symbols, and integers may be converted to characters.
2-1) If object is a string of length 1,
then the sole element of the string is returned.
2-2) If object is a symbol whose print name is of length 1,
then the sole element of the print name is returned.
2-3) If object is an integer n,
then (int-char n) is returned.
3) any non-complex number can be converted to a XXX-float.
4) any number can be converted to a complex number.
The next table shows that how coerce is not symmetric among character,
string, symbol and integer.
TABLE 1. Possible Conversions among character, string,symbol, integer
type of conversion provided functions coercion under the CLtL
character -> string string X
character <- string coerce (if the string has only one char.) O
character -> symbol (intern (string @i[ch])) X
character <- symbol coerce (if pname length is 1) O
character -> integer char-code, char-int X
character <- integer code-char (zero font-, zero bits- attrib.) O
int-char (any font- and any bits-)
string -> symbol intern, make-symbol X
string <- symbol string, symbol-name X
string -> integer (char-code (coerce @i[string] 'character)) X
string <- integer (string (code-char @i[integer])) X
symbol -> integer (char-code (coerce @i[symbol] 'character)) X
symbol <- integer (intern (string (code-char @i[integer]))) X
Problem 2:
The function of coerce for character is defined to act as char-int/int-char
not as char-code/code-char.
Proposal: Coerce :replace
-------------------------
COERCE should be more generalized for string, symbol, integer, and character
data types. The observations show there are
no problem if extensions are fully written out in the details.
Here is an extension to the current coerce definition using the CLOS.
(defmethod coerce ((x character) (y (eql string))) (string x))
(defmethod coerce ((x character) (y (eql symbol))) (intern (string x)))
(defmethod coerce ((x character) (y (eql integer))) (char-code x))
(defmethod coerce ((x string) (y (eql symbol))) (intern x))
(defmethod coerce ((x symbol) (y (eql string))) (string x))
(defmethod coerce ((x string) (y (eql integer)))
(char-code (coerce x 'character)))
(defmethod coerce ((x integer) (y (eql string))) (string (code-char x)))
(defmethod coerce ((x symbol) (y (eql integer)))
(char-code (coerce x 'character)))
(defmethod coerce ((x integer) (y (eql symbol)))
(intern (sting (code-char x))))
(defmethod coerce ((x integer) (y (eql character)))
(code-char x)) ; redefinition. CLtL defines as int-char
The keys are
a) ignore char-bits and char-font upon the conversion of characters,
assuming font-attribute will be flushed from the language spec.
b) ignore the package name upon the conversion of symbols.
(package name has no role upon the conversion.)
c) the created symbol will be interned to the current package.
Rationale:
----------
By extending the definition as this document suggests, the functionality
of coerce is symmetric among characters, strings, symbols and integers.
Current Practice:
Cost to implementors:
Cost to users:
Benefits:
Aesthetics:
Discussion:
Among the functions in Table 1, we can pick up the role of @t[STRING] function.
@T[STRING] has odd definition. It was also
the starting point of discussions described in the following.
The problems or the awkwards are mainly on the design of the symmetry of
the function names.
We would start the discussion with the following two observations.@*
i) @t[(string @i(x))] is OK. But, @t[(coerce @i(x) 'string)] is illegal.@*
While, @t[(character @i(x))] is OK. And @t[(coerce @i(x) 'character)] is OK too..@*
ii) To convert from a symbol to a string, use @t[SYMBOL-NAME] or @t[STRING].
While, to convert from a string to a symbol,
use @t[MAKE-SYMBOL] to an uninterned symbol, or
use @t[INTERN] to an interned symbol.@*
@*
@*
@b[ Discussions on Coercion in Common-Lisp E-mails 1986]
The awkward were discussed already in Common-lisp E-mails.
The author checked the 10M bytes E-mails on disk.
The discussions around @t[coerce] were almost in 1986, and not much in 1985 or before.
The sequence of our concern started by a mail of fateman@@dali.berkeley.edu,
dated Fri, 16 May 1986 15:40 PDT as follows.@*
1) fateman@@dali.berkeley.edu fri 16 may 1986 15:40 PDT:@*
This mail describes the same issue as for STRING function.
2) jeff@@aiva.edinburgh.ac.uk sun 18 may 17:17 GMT@*
@t[ ... 'string' applied to a sequence of characters gives an error, typically
saying the sequence can't be coerced to a string, but 'coerce' will in fact coerce it...]
3) gls@@think.com, Mon 19 may 1986 12:20 EDT@*
@begin[t]Research shows that the Common Lisp archives up to a couple of months
ago contains 18 messages that mention @t[COERCE]. None explicitly addresses
this issue, but the general tone of the messages is one of conservatism.
I now remember that this issue was tied up with the design of the
sequence functions. There was real resistance to letting symbols be
treated as general sequences, and so the general decision was made that
string-specific functions would accept symbols, but general sequence
functions would not. ...@end[t] To check his talk, @b[3.3] shows all the
early discussions on @t[coerce] the author can find.
4) fahlman@@c.cs.cmu.edu Mon, 19 May 1986 20:44 EDT@*
@t[... I would not object to generalizing coerce to handle some of the
additional cases that people imagine it ought to handle.]
@begin[verbatim]
5) cfry@@oz.ai.mit.edu, Tue, 20 May 1986 03:21 EDT@*
... Coercion is a powerful, easy to remember concept. I think it should be
extended as much as possible. ... :
(coerce #\a 'string) => "a"
(coerce 123 'string) => "123"
(coerce #\a 'integer) => (char-code #\a) ; explicitly not provided CLtL p52.
It appears that the only reason is that no one could decide on using
char-code or char-int for the conversion so they chose not to do it
at all. This reasoning is odd. Pick the most frequently used way,
document it, and permit it. Same argument for coercion of numeric types.
Further out extensions might be:
(coerce #'foo 'compiled-function) => returns a compiled function object
...
(coerce string-1 'pathname)
(coerce bit-vector-1 'integer) ...
Undoubtedly there are other coercions which would make sense. ...
Users would save a lot of manual searching if coerce was extended.
@end[verbatim]
6) Eliot@@umass-cs.csnet, Tue 20 May 1986 15:31 EST@*
@t[Coercing symbols to stings is fine, as long as NIL is treated as
the empty SEQUENCE, rather than as a symbol.]
@begin[verbatim]
7) REM@@IMSSS, 19 May 09:34 PST referring to the mail of gls saying
that "@t[COERCE] was limited to ... sequence and numerical coercions".
This is one of the bad points of many LISPs, including CL, functions that
are miss-named or otherwise don't do what you'd expect from their name.
... I hope the international standards committee will fix this kind of
problem so programmers reading somebody else's code can have the meaning
apparent in most cases form general programming tradition rather than
having to constantly check the manual to see if the function does what
it seems to say it would do.
8) DCP@@scrc-quabbin.arpa, Wed, 21 May 1986 16:45 EDT,@*
Does (coerce @i(symbol) 'string) return
(symbol-name @i(symbol)), or (format nil "~S" @i(symbol)),
or (format nil "~A::~A"
(package-name (symbol-package @i(symbol))) (symbol-name @i(symbol)))
or what ? If this weren't enough, added in with my personal views of
style and functionality, for me to want to help veto this coercion, the
special casing of NIL certainly would. Programs should reflect their
meaning. A string is a sequence, a symbol is not. Why shouldn't
@# (coerce :ascii-EOT 'integer)
work? The answer is that the requested behavior is not a coercion
between compatible types, it is a functional translation between human
understandable names for the ascii control characters and the integers
that are their corresponding values.
@end[verbatim]
We found that there is a possibility to extend the semantics of @t[coerce]
to cope with more generic types. It should be noted that the two key designers of Common Lisp
mentioned their opinions, and they do not always be against to the extension.
The discussion was stopped at this point and we cannot find their continuation yet.
We find from this story that @*
1) If we don't care about the package, we may extend the coerce
to the function from a symbol to a string, @*
2) If we are free to care about the font- and bits- attribute,
we may extend the coerce to include the function from a character to other types.@*
@*
@*
@b[ Early discussions on coercion]
The following sequence was picked up from the archives. They are almost all the meaningful
talk the author can find. They were in 1983, one year before @i(CLtL) was published.
@begin(verbatim)
1) Guy Steele, dated 27 May 83 01:23:14 EDT, (in the summary of the discussion
with DLW and moon upon the laser edition update)
a)No.38: it is noted that DLW said "coercing of characters to integers
should probably be allowed too." and this point was marked as {controversial}.
b) Moon's comment. "if (string x) <=> (coerce x 'string) exactly, say so.
Both of these should coerce a character into a 1-element string; neither says
so now. The old argument against this, that people might expect string of a
number to give not numbers." and Guy Steele agreed.
N.197: {gloss} string is required to signal an error if its argument is not a
string and not a symbol. This is wrong; it should convert a character to a
one-character string. Also it says that string will not convert a sequence of
characters into a string, but coerce will. This might be all right, except
under coerce it says that when coercing to a string the implementation is
allowed to return a more general type. ... Also the coerce writeup
doesn't say anything for or against coercing from a character to a 1-long string.
{controversial} {will clarify}
2) Fahlman, dated Sat, 28 May 1983 22:34 EDT;
At least, I would like you to consider dropping these. ...
Page 38: Coercing of characters to integers is not a very useful operation in
portable code if the language spec does not specify the correspondence (and
Common Lisp does not). Do you still want to propose that we add this coercion?
I'm not particularly opposed, I just worry that users will find it too easy to
inadvertently do non-portable things if given this coercion.
3) Moon, date: sat, 28 May 1983, 22:40-EDT
I don't think coercion of characters to integers should be allowed, because
how do you know whether you want the char-code or what. Dan was probably
just stuck in our old mindset from not having character objects on the Lisp
machine. Coercion of characters to strings, however, I believe is useful.
4) Daniel L.Weinreb, Date: Tuesday, 31 May 1983, 15:40-EDT
... It's OK with me if COERCE doesn't coerce characters to integers. However,
I strongly suggest putting in a clarification note to that effect... Or maybe
a Rationale note saying that it doesn't because it wouldn't be clear what to do
about the char-code versus whole character, and telling you to use the particularly
function instead. This note is for the benefit of users more than of implementors.
5) Scott E. Fahlman, Date: Wed, 1 Jun 1983 01:47 EDT < referring 4)>
It's OK with me if COERCE doesn't coerce characters to integers.
However, I strongly suggest putting in a clarification note to that ...
<< I assume Guy will do this. >>
@end(verbatim)
As far as we can see from this talk, that the process of making a coercion between
characters and integers be restricted such that char-to-integer conversion is not provided,
while integer-to-char is. The coercions from characters to integers are
purposely not provided; @t[char-code] or @t[char-int] may be used explicitly to
perform such conversions (See @b[Appendix] for the definitions of @t[char-code]
and @t[char-int]).
The difference between @t(char-int) and @t(char-code) is on the treatment of
@i(font) and @i(bits) attributes.
If these two attributes have no significant meaning and are ignored by everyone,
we can make the story much simpler. (And @b[4.] describes at least font- is
not alive).
∂29-Feb-88 1357 CL-Cleanup-mailer function-type-rest-list-element
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Feb 88 13:57:40 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 353104; Mon 29-Feb-88 16:54:04 EST
Date: Mon, 29 Feb 88 16:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: function-type-rest-list-element
To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>, Jon L White <edsel!jonl@labrea.Stanford.EDU>,
Ram@C.CS.CMU.EDU
cc: cl-cleanup <cl-cleanup@SAIL.STANFORD.EDU>
In-Reply-To: The message of 24 Feb 88 09:06 EST from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>,
<8802242144.AA01988@bhopal.lucid.com>,
<8802251719.AA05861@bhopal.lucid.com>,
<RAM.12378202550.BABYL@>
Message-ID: <19880229215350.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 24 Feb 88 10:06:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
But the analogy to VECTOR is false! (VECTOR element-type) does not
mean a vector all of whose current elements are of type element-type.
Nor does it mean a vector constrained such that that all elements
that can be stored into it are of type element-type. The ambiguous
language on CLtL p.47 might lead you to think that's what it means,
but CLtL p.45 makes it clear. For declaration, (VECTOR element-type)
[via (ARRAY element-type (*))] means a one-dimensional array
of the most specialized type that is capable of holding objects of
type element-type. Therefore, unless element-type is STRING-CHAR
or BIT, or a subtype of one of them, this guarantees exactly nothing
about the types of the elements of the vector.
Maybe the element-type argument to these type-specifiers should mean
something else, but that's what it means in Common Lisp as currently
defined.
The discussion of ARRAY type specifiers on p.45 is talking about the
permissible and expected representations of arrays, not of the possible
types of the elements of such arrays. So what's on p.45 doesn't make
anything clear here.
What would you expect to be the type of the result of the following code:
(let ((a ...))
(declare (type (vector foo) a))
(aref a 3))
I don't see anything in CLtL that addresses this question.
I believe that in every implementation, the result should be of type FOO,
for any type FOO. What is discussed on p.45 says that A might not be of
type (VECTOR FOO). But this is unrelated to the question of whether
the elements of the array have any particular type.
Setting an element of A to be something that's not of type FOO is
an error. The representation might allow it, because the new value
might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it
correct. It's just a matter of whether the array happened to
remember the precise type it was created with.
I agree that this is a reasonable approach. I don't think CLtL says
this, but I don't think it says anything that contradicts it, either. I
think this is not too relevant to my point that the (VECTOR FOO)
type-specifier does not mean a vector all of whose elements are of type
FOO. As you point out, it means that a portable program "should" (in
CLtL "is an error" sense) assume that it can only store elements of type
FOO into that vector. But I think your proposed meaning for (LIST FOO)
was rather stronger. Perhaps I should make my point a different way:
I don't think that Common Lisp's current type system for compound types
is well enough specified for this kind of extension to work obviously
and naturally without exposing problems.
I haven't read any clean-up mail, so if you've talked about this
issue and resolved it somehow, please tell me.
It's been discussed periodically but I don't think it's ever come close
to resolution. It's perhaps too large an issue for the Cleanup committee.
The problem here is in trying to use lambda-list syntax for describing
function calls. Already there's a slight contortion by having the
actual keywords be included in the function type for &KEY arguments.
So it isn't quite as simple as just taking the real lambda-list,
deleting all the init forms and &AUXen, and replacing parameter names
with their types. But I think this way of looking at how function
type specifiers are derived is easier than starting with just a
positional approach (i.e., the second arg, if supplied, has to be of
type X, etc.) and then modifying it to also convey number-of-args and
keyword information. Thus one would prefer having the type specifier
for the &REST argument be the real type specifier for the &REST argument.
I agree with you, up to the last sentence, which I can't understand.
There isn't such a thing as an "&REST argument" in Common Lisp, unless
you mean the last argument to APPLY. If where you said "argument" you
meant "parameter", then I understand what you're saying but don't agree
with it. One could equally well conclude from the preceding paragraph
that the type specifier for the &REST arguments (note the plural)
should be the type specifier for each actual argument. Since there isn't
a one to one correspondence of arguments to parameters in this one case,
the analogy of function type specifiers to lambda-lists doesn't really
give us any guidance.
I'm being too long-winded here, since I don't even know what these
FUNCTION type specifiers are useful for, anyway. My main reason for
jumping in was to point out a possible misconception about how strong
the VECTOR type specifier is in current Common Lisp.
Date: Thu, 25 Feb 88 09:19:28 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
re: The discussion of ARRAY type specifiers on p.45 is talking about the
permissible and expected representations of arrays, not of the possible
types of the elements of such arrays. So what's on p.45 doesn't make
anything clear here.
Well, it's true that CLtL pp45-47 are anything but "clear". But what
Dave is saying (I think) is that a number of wizards have groveled over
those pages and all agree that there is only one interpretation of them
consistent with the rest of CLtL. And that interpretaton is at variance
with your comments:
Setting an element of A to be something that's not of type FOO is
an error. The representation might allow it, because the new value
might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it
correct. It's just a matter of whether the array happened to
remember the precise type it was created with.
Perhaps the clearest indicator that CLtL really isn't saying this is
found on p291, under the description of ARRAY-ELEMENT-TYPE. Note how
this section really is "clear" that an array made by
(make-array 5 :element-type '(mod 5))
may legitimately have an element stored into it that is of type (mod 8)
but not necessarily of type (mod 5).
Well, this is simply another way of stating the root problem here. CLtL
isn't sure whether its data types are portable, fairly abstract types or
are ways to find out about implementation details.
Date: Sat, 27 Feb 1988 21:17 EST
From: Ram@C.CS.CMU.EDU
Well, I don't agree with VanRoggen's stand on the &rest type issue,
but I think he is pretty close to the mark about array types. This
isn't inconsistent, since the desirability or feasilibility of a typed
list specifier is pretty unrelated to the &rest issue.
Not really, since VanRoggen's proposal was to employ a typed list
specifier in the resolution of the &rest issue.
By the way, I'm not arguing in favor of the way array types currently
are defined, I'm just pointing out the facts. If we're now going to
redesign array types, I think that's a good idea, or at least an
interesting one, but I'll probably limit my contribution to pointing out
that it isn't easy, i.e. the obvious trivial fixes don't completely
work.
The only rationale under which one could store something not (mod 5)
into that array would be that they could make the array, then call
ARRAY-ELEMENT-TYPE to find out that element types it can actually
hold, and then store randomness into it. I don't believe that this is
a reasonable thing to do.
But someone else might believe that it is. See my comment above that
CLtL isn't sure what the goal of the type system is.
This basically amounts to bogotifying the language in order to make
ARRAY-ELEMENT-TYPE work. This is a bad idea, since I think that the
semantics of ARRAY-ELEMENT-TYPE are just as seriously flawed as the
semantics of TYPE-OF. (which is another flame)
It is much easier to give types a clean semantics in Common Lisp if
ARRAY-ELEMENT-TYPE and TYPE-OF are ignored. For example, without
these functions, there would be no way for users to even know that
"array element type upgrading" exists. (Assuming the array TYPEP
"feature" mentioned in the manual is fixed.)
Yes, the semantics would be cleaner if there weren't compound objects,
or if there weren't implementation dependencies. No argument about that.
I think removing those primitives from the language may be just sweeping
the problem under a rug, not solving it, though. Admittedly that would
be in the tradition of Common Lisp.
∂29-Feb-88 1553 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 29 Feb 88 15:52:45 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA04746; Mon, 29 Feb 88 18:54:32 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA19855; Mon, 29 Feb 88 18:55:17 EST
Message-Id: <8802292355.AA19855@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)
Date: Mon, 29 Feb 88 18:55:14 EST
From: Dan L. Pierson <pierson@mist>
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Status: For Internal Discussion
This is a complete rewrite. I hope the added complexity is worth it,
I don't see anyway to both hide the hair and do better than CLtL.
Problem description:
CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*. This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.
For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*. A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.
Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
A Common Lisp implementation is required to provide two sets of open
streams, Primitive Streams, and User Streams. Most user programs
should only use the User Streams; each User Stream has a specific
purpose as defined in CLtL. [[ If this proposal is accepted I can be
persuaded to retype the page and a half of definitions here.]] The
Primitive Streams are the initial defined interfaces between Lisp and
the non-Lisp world. The primary purpose of the Primitive Streams is
to make it possible to portably recover from a stream-binding error on
any User Stream, for this reason it is an error to rebind or set any
Primitive Stream. Implementations are encouraged, but not required to
signal a correctable error if a Primitive Stream is rebound.
Primitive Streams:
*INITIAL-INPUT*
This stream is bound to the primary default input of the Lisp
system (e.g. standard input on Unix, SYS$INPUT on VMS). While
this will probably be an interactive terminal or window during
program development, it may well be a data file for a
non-interactive application.
*INITIAL-OUTPUT*
This stream is bound to the primary default output of the Lisp
system (e.g. standard output on Unix, SYS$OUTPUT on VMS). While
this will probably be an interactive terminal or window during
program development, it may well be a data file for a
non-interactive application.
*INITIAL-QUERY-INPUT*
Whenever possible, this stream is bound to an interactive
input source. This may be the same as *initial-input* in a
development environment, or it may be a separate window, or
terminal. If the Lisp system is running under an operating
system such as Aegis which provides a separate error input
source, this stream should probably be bound to that source.
In a non-interactive environment for which no interactive input
is available, reading this stream will always result in EOF.
*INITIAL-ERROR-OUTPUT*
If *initial-query-input* is bound to an interactive input source,
this stream should be bound to the cooresponding interactive output
destination such that *query-io* will work in the expected way if
bound to a two-way stream between these two streams. If the Lisp
system is running under an operating system such as Aegis, Unix,
or VMS which provides a separate error output destination, this
stream should be bound to that destination. In a non-interactive
environment without a separate error destination, this stream should
be bound to the same destination as *initial-output*.
User Streams:
*TERMINAL-IO*
The initial binding of *terminal-io* is a two-way stream between
*initial-input* and *initial-output* unless these streams can be
determined to be non-interactive and *initial-query-input* and
*initial-error-output* can both be determined to be real interactive
streams (e.g. reading *initial-query-input* does not always result
in EOF), in which case *terminal-io* is bound to a two-way stream
between them. In a windowing environment, *terminal-io* may refer
to a different window than *query-io* (and therefore than any of
the *initial-foo* streams) as long as all of these streams refer
to windows.
*STANDARD-INPUT*
The initial binding of *standard-input* is *initial-input*.
*STANDARD-OUTPUT*
The initial binding of *standard-output* is *initial-output*.
*ERROR-OUTPUT*
The initial binding of *error-output* is *initial-error-output*.
*TRACE-OUTPUT*
The initial binding of *trace-output* is *initial-error-output*
in a non-windowed environment. In a windowed environment,
*trace-output* may start out bound in some other way (e.g. to
a non-existant trace output window which will be automagically
created when output is first done to *trace-output*).
*QUERY-IO*
Initially bound to a two way stream between *initial-query-input*
and *initial-error-output*.
*DEBUG-IO*
The initial binding of *debug-io* is *initial-error-output* in a
non-windowed environment. In a windowed environment, *debug-io*
may start out bound in some other way.
Test Cases/Examples:
(PROGN
(PRINT "Output" *STANDARD-OUTPUT*)
(PRINT "Error" *STANDARD-ERROR*))
In current Common Lisp will write:
------
Output
Error
------
With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.
Rationale:
This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output including safe rebinding of the standard streams.
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.
Cost to Implementors:
All implementations will have to change to some degree but the changes
will probably be simple and localized. Most implementations already
include some or all of the initial streams as internal stream types so
this is largely a documentation and initialization task.
Cost to Users:
User code which depends on the strict binding hierarchy in CLtL may
have to change.
Cost of non-Adoption:
It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations.
Aesthetics:
The four new streams appear to add complexity but they also separate
the previous intermixed concepts of initial bindings and standard
purpose streams.
Discussion:
The repeated mention of windowing environments above seems to be
getting dangerously close to the environmental issues this standard is
supposed to avoid, but Pierson feels that if we have to do more than
leave these areas undefined, we also have to give advanced
environments official permission to do their thing.
∂29-Feb-88 2001 CL-Cleanup-mailer function-type-rest-list-element
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 19:59:55 PST
Received: by labrea.Stanford.EDU; Mon, 29 Feb 88 19:21:33 PST
Received: from bhopal.lucid.com by edsel id AA04105g; Mon, 29 Feb 88 19:48:13 PST
Received: by bhopal id AA04652g; Mon, 29 Feb 88 19:54:18 PST
Date: Mon, 29 Feb 88 19:54:18 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803010354.AA04652@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu, vanroggen%aitg.decnet@hudson.dec.com,
Ram@c.cs.cmu.edu
In-Reply-To: David A. Moon's message of Mon, 29 Feb 88 16:53 EST <19880229215350.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: function-type-rest-list-element
re: . . . CLtL isn't sure whether its data types are portable, fairly
abstract types or are ways to find out about implementation details.
Good point. In that series of messages a couple of months ago (?) on this
issue, there were basically two camps of opinions:
(1) array types should be completely portable -- hence the exact
equivalence class of the :element-type specifier must be "remembered"
(2) "Upgrading" is reasonable, albeit a source of non-portability akin to
the fixnum/bignum split; to do otherwise isn't worth it.
Both Rob and Walter are espousing position (1), and may not have fully
noticed that it isn't mandated by CLtL. I myself forget the horrible
intricacies of array types from time to time. Worse yet, I waffle between
preferring (1) and (2) depending on the latest "arguments" for one or
the other. To me, this indicates that an easy solution isn't at hand.
While there seemed to be no clear consensus on saying that types "must be"
portable, almost everyone agreed that the schizophrenia induced by CLtL p45
is a bad idea, and could easily be dropped. This is the part that says
"Types can therefore be used for two different purposes: declaration and
discrimination. ...", and implies as a consquence that the result of:
(make-array <n> :element-type '<type-spec>)
will probably not be of typep (array <type-spec>).
Not only is this very counterintuitive, but it really doesn't satisfy
any need that I'm aware of. At first blush, it might seem to be a
corollary of "upgrading"; but it isn't at all.
-- JonL --
∂01-Mar-88 1009 CL-Cleanup-mailer function-type-rest-list-element
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Mar 88 10:07:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 353704; Tue 1-Mar-88 13:07:13 EST
Date: Tue, 1 Mar 88 13:07 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: function-type-rest-list-element
To: Jon L White <edsel!jonl@labrea.Stanford.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU, vanroggen%aitg.decnet@hudson.dec.com, Ram@c.cs.cmu.edu
In-Reply-To: <8803010354.AA04652@bhopal.lucid.com>
Message-ID: <19880301180711.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 29 Feb 88 19:54:18 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
While there seemed to be no clear consensus on saying that types "must be"
portable, almost everyone agreed that the schizophrenia induced by CLtL p45
is a bad idea, and could easily be dropped. This is the part that says
"Types can therefore be used for two different purposes: declaration and
discrimination. ...", and implies as a consquence that the result of:
(make-array <n> :element-type '<type-spec>)
will probably not be of typep (array <type-spec>).
Not only is this very counterintuitive, but it really doesn't satisfy
any need that I'm aware of. At first blush, it might seem to be a
corollary of "upgrading"; but it isn't at all.
I don't know why the declaration vs discrimination thing was done. The
only thing I can guess at is that the idea was that if (typep a '(array
foo)), then it's -guaranteed- that (typep (aref a n) 'foo) is true,
because a is implemented with a representation that only holds objects
of type foo. Before speculating further I should of course leaf through
CLtL to see if it already contains somewhere an explanation of why the
declaration vs discrimination distinction was drawn.
Offhand getting rid of this distinction into two kinds of types seems
like a good idea. However, I'm a bit leery of changing things in the
language when I don't understand why they are there. At first thought,
removing the distinction seems like an upward-compatible change in the
sense that all it does is make some types that currently have no
members, in a particular implementation, have some members. However
there might be subtle incompatibilities with existing programs, since
the subtype rules would be changed, and in a way that depends on what
array representations a particular implementation has. I don't claim to
understand the implications right now.
∂01-Mar-88 1102 CL-Cleanup-mailer sequence-functions-exclude-arrays (pardon msg duplication, if any)
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 88 11:01:53 PST
Date: 1 Mar 88 13:45:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: sequence-functions-exclude-arrays (pardon msg duplication, if any)
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
We currently oppose the proposal SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:
GENERALIZE as it stands.
There are a number of issues that should be addressed.
The proposal merely offers new syntax for functionality already
provided by displaced vectors. The argument that users (or at least
one user) "dislikes" using displaced vectors has little meaning.
The syntax for displaced vectors could be improved with some trivial
macros, while efficiency concerns should be handled by the compiler.
The availability of ROW-MAJOR-AREF would seem to make this proposal
even less necessary than before. It wouldn't change the behavior of
FILL, COUNT, etc. but does make such array operations even easier to
implement efficiently.
There is no description of the meaning of :START and :END keyword arguments
for affected functions in the current proposal.
Do ARRAYs become a subtype of SEQUENCE? We assume not, but this should
be specified. However, the sequence functions won't just be
``sequence'' functions any more. It's confusing to remember which
functions work on arrays and which don't.
Despite the proposal's claim to the contrary, it strikes us that
this is precisely an attempt to make Common Lisp into a kind of
half-baked APL. We feel adoption of this proposal will almost
certainly result in pressure to extend still more sequence functions.
This may or may not be desirable in the long run; but this proposal is
only a partial measure.
---Walter van Roggen &
Jeff Piazza
------
∂01-Mar-88 1124 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Mar 88 11:24:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 353802; 1 Mar 88 14:23:46 EST
Date: Tue, 1 Mar 88 14:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)
To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>, Pierson@MULTIMAX.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8802292355.AA19855@mist.UUCP>
Message-ID: <19880301192344.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
There are actually three parts to this proposal, and perhaps it
should be written in a way that makes the distinction even clearer.
First, the specification of *STANDARD-INPUT* etc. is changed to
specify them in terms of what they do, rather than in terms of
how they are implemented. I wholeheartedly support this. I think
the proposal needs to go a little farther in this direction. For
instance, it seems to apply that the initial binding of *TERMINAL-IO*
will be a value returned by the MAKE-TWO-WAY-STREAM function. That's
implementation. Instead it should say only that the initial binding
of *TERMINAL-IO* behaves in such a way that input comes from, and
output goes to, an interactive place, if there is one. If no interactive
places exist, I think you say (the wording is a bit confusing) that
*TERMINAL-IO* is bound to (MAKE-TWO-WAY-STREAM *STANDARD-INPUT*
*STANDARD-OUTPUT*), even though it's not a terminal. I'm not sure, but
I think it might be better for *TERMINAL-IO* to be unbound, or a stream
that signals an error if used, in this case, since anything that explicitly
uses *TERMINAL-IO* is trying to do something that simply can't be done.
I suspect that the alignment of the *TERMINAL-IO* interactive place with
the *STANDARD-INPUT* and *QUERY-IO* interactive places should be left up
to the implementation, rather than trying to say (as you do) it goes
here if that's interactive, else it goes there. There is probably a
great deal of variation among implementations on this point, and I don't
see that a portable program needs to know whether *TERMINAL-IO* is the
same as *STANDARD-INPUT*, the same as *QUERY-IO*, or the same as neither
of them; a portable program should use whichever stream is the one it
really means, not use some different one on the assumption that it's
really the same.
Second, you propose to add the variable *INITIAL-QUERY-INPUT*, which
doesn't quite correspond to *QUERY-IO*. This gives access to a primitive
stream that hadn't been identified as primitive before, but that exists
in some implementations. Although I don't understand how an application
program would use an input-only query stream, I see no harm in making
this change. No one is forced to use it if they don't want to. I'd
drop the word "initial" from the variable name.
Third, you propose to add three new variables that retain the initial
values of three of the existing stream variables, in case the existing
variables are rebound. I don't see any value in this, except that it
helps you describe the meanings of the other streams. A program that
wished to portably recover from a stream-binding error on any User
Stream could start by saving the values of the existing variables.
We don't need to add new variables for this.
This sounds a bit critical, but I think this is basically a very good
proposal. I hope you find my suggested improvements constructive.
∂01-Mar-88 1301 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:01:05 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA11586; Tue, 1 Mar 88 16:02:47 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA21522; Tue, 1 Mar 88 16:02:38 EST
Message-Id: <8803012102.AA21522@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: LET-TOP-LEVEL (version 1)
Date: Tue, 01 Mar 88 16:02:35 EST
From: Dan L. Pierson <pierson@mist>
Issue: LET-TOP-LEVEL
References: Top-Level Forms (p. 66), DEFUN (p. 67),
DEFVAR, DEFPARAMETER, DEFCONSTANT (pp. 68-69)
Category: ADDITION
Edit history: Version 1 by Pierson 3/1/88
Status: For Internal Discussion
Problem description:
The main defining forms in CLtL do not support defining (as opposed to
creating) closures in lexical environments.
Proposal (LET-TOP-LEVEL:ALLOW-DEF):
Require implementations to support DEFUN, DEFVAR, DEFPARAMETER, and
DEFCONSTANT enclosed in a LET at top level as well as a PROGN at top
level. Do not require support for DEFMACRO (environment irrelevant)
or EVAL-WHEN. Explicitly note that a "top level" let can be included
in a top level PROGN.
Test Cases/Examples:
The following creates a simple resource allocation package for THINGs.
It needs to be COMPILE-FILEd to test it.
(LET ((THINGS '()))
(DEFUN GET-THING ()
(IF THINGS
(PROG1 (CAR THINGS)
(SETF THINGS (CDR THINGS)))
(MAKE-THING)))
(DEFUN FREE-THING (THING)
(SETF THINGS (CONS THING THINGS))))
Rationale:
Common Lisp tries to support lexical closures but this support is
really confined to anonymous lambdas within other function
definitions. This proposal attempts to move lexical closures closer
to first-class status in Common Lisp.
Current practice:
The above example works in both Ibuki Lisp and Lucid, however only
Ibuki Lisp describes (SYMBOL-FUNCTION 'GET-THING) as a closure. Both
Symbolics and TI are reported to leave GET-THING and FREE-THING as
named-lambdas instead of compiling them.
Cost to Implementors:
While there is obviously some work required, it shouldn't be too hard
since all Common Lisp compilers are required to understand functions
in lexical closures in other contexts.
Cost to Users:
None, this is an upward compatible change.
Cost of non-Adoption:
Common Lisp will continue to leave a major style of lexical closure
use unsupported. This is probably most important to people converting
from Scheme to Common Lisp.
Benefits:
Lexical closures will become more useful. The increased information
hiding available may make some programs more maintainable by reducing
the number of global variables which really should be private to a
small group of functions. It will be easier to migrate some Scheme
programming styles to Common Lisp.
Aesthetics:
The aesthetics of the language will be improved by supporting a more
uniform view and use of lexical closures.
Discussion:
It has been pointed out that much of this proposal can be accomplished
by layering macros on top of SETF of SYMBOL-FUNCTION. The problem
with the macro approach is that it doesn't support whatever additional
environmental things the implementation may decide to do with DEFUN
(e.g. make an entry in the cross reference database).
One disadvantage of this proposal is that it doesn't interact well
with Lisp-style incremental development, for example a new top-level
defun of GET-THING wouldn't work. Pierson believes that this is an
inherent consequence of heavy use of lexical closures and that the
best workaround is to use an inspector which can support incremental
development within the current lexical scope, however this is all
outside the purvue of this committee.
Maybe this should be a compiler proposal instead of a cleanup proposal.
∂01-Mar-88 1310 CL-Cleanup-mailer function-type-rest-list-element (really array types)
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:09:54 PST
Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Tue 1 Mar 88 16:08:28-EST
Date: Tue, 1 Mar 1988 16:08 EST
Message-ID: <RAM.12378932724.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Jon L White <edsel!jonl@LABREA.STANFORD.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU, Moon@SCRC-STONY-BROOK.ARPA,
vanroggen%aitg.decnet@HUDSON.DEC.COM
Subject: function-type-rest-list-element (really array types)
In-reply-to: Msg of 29 Feb 1988 22:54-EST from Jon L White <edsel!jonl at labrea.Stanford.EDU>
Date: Monday, 29 February 1988 22:54-EST
From: Jon L White <edsel!jonl at labrea.Stanford.EDU>
To: Moon at stony-brook.scrc.symbolics.com
Re: function-type-rest-list-element
re: . . . CLtL isn't sure whether its data types are portable, fairly
abstract types or are ways to find out about implementation details.
Good point. In that series of messages a couple of months ago (?) on this
issue, there were basically two camps of opinions:
(1) array types should be completely portable -- hence the exact
equivalence class of the :element-type specifier must be "remembered"
(2) "Upgrading" is reasonable, albeit a source of non-portability akin to
the fixnum/bignum split; to do otherwise isn't worth it.
Both Rob and Walter are espousing position (1), and may not have fully
noticed that it isn't mandated by CLtL.
Actually I'm not proposing 1, at least as I understand what you are
saying. My idea is that TYPEP automatically "upgrade" its type
argument to the corresponding "implementation type", i.e. a type
actually supported by the implementation. This basically amounts to
requiring the programmer (as opposed to the array) the remember the
array element type, but in the absence of a hard semantics for
ARRAY-ELEMENT-TYPE/TYPE-OF, this is the same as requiring that arrays
"remember their element-type".
I think that analogies with the FIXNUM/INTEGER are flawed: FIXNUM has
is a precisely defined concept within the language:
`(integer ,most-negative-fixnum ,most-positive-fixnum)
Given this definition, a Common Lisp program can have a portable
understanding of what it means to be a FIXNUM. For example, it is
clear that
(typep most-negative-fixnum 'fixnum)
is true in any Common Lisp implementation.
With arrays, TYPEP is simply broken. Unless you use one of the
special element types, BIT, STRING-CHAR or T, TYPEP doesn't mean
anything on arrays.
It seems to me that the FIXNUM issue is kind of like a resource
restriction:
"This program will only run when a fixnum is at least 16 bits."
is similar to
"This program will only run when you can have 1e6 element bit-vectors."
In constrast, there is no way to characterize the set of
implementations in which TYPEP will work on arrays. In fact, there
probably are no such implementations.
[...] almost everyone agreed that the schizophrenia induced by
CLtL p45 is a bad idea, and could easily be dropped. This is the
part that says "Types can therefore be used for two different
purposes: declaration and discrimination. ...", and implies as a
consquence that the result of:
(make-array <n> :element-type '<type-spec>)
will probably not be of typep (array <type-spec>).
Not only is this very counterintuitive, but it really doesn't satisfy
any need that I'm aware of.
Yes, I agree with this.
Rob
∂01-Mar-88 1318 CL-Cleanup-mailer UPGRADE-ARRAY-ELEMENT-TYPE: a sloution for the array TYPEP problem?
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:16:30 PST
Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 12:38:16 PST
Received: from bhopal.lucid.com by edsel id AA06523g; Tue, 1 Mar 88 13:03:03 PST
Received: by bhopal id AA05817g; Tue, 1 Mar 88 13:09:10 PST
Date: Tue, 1 Mar 88 13:09:10 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803012109.AA05817@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu, vanroggen%aitg.decnet@hudson.dec.com,
Ram@c.cs.cmu.edu
In-Reply-To: David A. Moon's message of Tue, 1 Mar 88 13:07 EST <19880301180711.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: UPGRADE-ARRAY-ELEMENT-TYPE: a sloution for the array TYPEP problem?
re: I don't know why the declaration vs discrimination thing was done.
. . .
Offhand getting rid of this distinction into two kinds of types seems
like a good idea. However, I'm a bit leery of changing things in the
language when I don't understand why they are there. . . .
I share your queasiness here. My first impluse is to ask for a function
(which would be "implementation revealing") named UPGRADE-ARRAY-ELEMENT-TYPE
whose purpose would be to tell you what the canonical representation for a
type name is (when used as an :element-type specifier). E.g., suppose:
(setq a (make-array size :element-type 'foo)
(setq real-element-type (upgrade-array-element-type 'foo))
then the following two specifiers would be type-equivalent:
`(array foo) `(array ,real-element-type)
even if "'foo" and "real-element-type" be not type-equivalent. Furthermore,
(typep (aref a n) real-element-type)
is always true, even though in the face of non-trivial upgrading,
(typep (aref a n) 'foo)
could be false.
I would consider UPGRADE-ARRAY-ELEMENT-TYPE in the same genre of features
as MOST-POSITIVE-FIXNUM. Programmers would inevitably choose to use
"real-element-type" rather than "'foo", and ocasionally find that their
code wasn't so trivially portable to a system that had a fundamentally
different kind of upgrading.
But if "upgrading" is to remain in CL, I don't see how we can avoid
opening it up a bit for inspection.
My second impluse is to toss out upgrading altogether, and require every
array to remember the type (or, a canonical name therefor) by which it
was created. The reason this is second, rather than first, on my list is
that to make types absolutely portable this way is a very pyrrhic success.
Sure, your program will port to the Y machine -- it will just run two orders
of magnitude slower [because you started out on, say, a Multics machine
with (MOD 512) arrays optimized, and ported to an implementation for an
engineering workstation that prefers (UNSIGNED-BYTE 8) arrays ...].
Finally, as I've said before, I don't think it's an acceptable solution
for Lisp to take the same route as C (and others) to achieve portability.
The kinds of array types in such languages are limited to a small (albeit
very useful) set that seems inspired by one particular hardware architecture.
-- JonL --
P.S. Of course UPGRADE-ARRAY-ELEMENT-TYPE can currently be implemented
in a "consy" way doing something like:
(array-element-type (make-array 0 :element-type 'foo))
But the presence of a "first class" function UPGRADE-ARRAY-ELEMENT-TYPE
would be more for the purpose of encouraging cognizance of these
problems than for avoiding the consing. Implicitly, such a function
lies underneath any implementation of MAKE-ARRAY already.
∂01-Mar-88 1325 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:25:17 PST
Received: from Salvador.ms by ArpaGateway.ms ; 01 MAR 88 13:24:51 PST
Date: Tue, 1 Mar 88 13:24:19 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
In-reply-to: <8803012102.AA21522@mist.UUCP>
To: cl-cleanup@sail.stanford.edu
Message-ID: <880301-132451-3075@Xerox>
First, I would claim that this is a ``clarification'' as opposed to an
``addition''. I see no language in CLtL to support the belief that DEFUN can
only be used in certain scopes. This reminds me of the debate over whether or
not the compiler is required to be reentrant; of course it is, for the same
reason that MAP is, for example: it's just another function with a particular
contract.
In any case, I don't oppose the proposal because I think it's important for
implementors to support this style. I have some other comments, though.
Why does the proposal not cover all of the defining forms? In particular, why
not DEFMACRO? It makes just as much sense for the expansion function to be a
closure. Of course, the compiler will not be able to expand uses of that macro
later in the same file, since it can't provide the proper lexical environment to
the expansion function, but that just means that this style would have to be
used in a separate file that is loaded before compilation of uses of the macro.
The same goes for the defining forms DEFSTRUCT, DEFTYPE, etc.
I not particularly happy with the explicit use of the term ``top-level'', but
until Rob's compiler proposal gets a fair hearing, I don't see any way around
it.
For the current practice section, Xerox Lisp also implements the proposed
behavior.
∂01-Mar-88 1445 CL-Cleanup-mailer function-type-rest-list-element (really array types)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 14:45:22 PST
Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 14:07:04 PST
Received: from bhopal.lucid.com by edsel id AA06877g; Tue, 1 Mar 88 13:59:18 PST
Received: by bhopal id AA06724g; Tue, 1 Mar 88 14:05:25 PST
Date: Tue, 1 Mar 88 14:05:25 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803012205.AA06724@bhopal.lucid.com>
To: Ram@c.cs.cmu.edu
Cc: cl-cleanup@sail.stanford.edu, Moon@scrc-stony-brook.arpa,
vanroggen%aitg.decnet@hudson.dec.com
In-Reply-To: Ram@C.CS.CMU.EDU's message of Tue, 1 Mar 1988 16:08 EST <RAM.12378932724.BABYL@>
Subject: function-type-rest-list-element (really array types)
re: My idea is that TYPEP automatically "upgrade" its type
argument to the corresponding "implementation type", i.e. a type
actually supported by the implementation. . . .
There are two problems with respect to typep. Consider arrays made by
(MAKE-ARRAY <n> :element-type '<foo>)
then:
1. (TYPEP <array> '(ARRAY <foo>)) frequently fails for such arrays
2. (TYPEP (AREF <array> <n>) '<foo>) frequently fails for such arrays
These are two separate problems, and as I read your comments about having
TYPEP do the "upgrading", I think they apply only to case (1), right?
This may be another way of trying to say that
`(ARRAY FOO)
is type equivalent to
`(ARRAY ,(upgrade array-element-type 'foo))
re: I think that analogies with the FIXNUM/INTEGER are flawed: FIXNUM has
is a precisely defined concept within the language:
`(integer ,most-negative-fixnum ,most-positive-fixnum)
See my comments in the previous note about a "pyrrhic success".
-- JonL --
∂01-Mar-88 1515 CL-Cleanup-mailer Compiler cleanup issues, again
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Mar 88 15:15:14 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA24776; Tue, 1 Mar 88 16:15:40 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA06356; Tue, 1 Mar 88 16:15:30 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8803012315.AA06356@orion.utah.edu>
Date: Tue, 1 Mar 88 16:15:28 MST
Subject: Compiler cleanup issues, again
To: smh%franz.uucp@ucbarpa.berkeley.edu, ram@c.cs.cmu.edu,
mike%acorn@LIVE-OAK.LCS.MIT.EDU
Cc: cl-cleanup@sail.stanford.edu
(flame on)
If there is not going to be a compiler subcommittee meeting at this
month's X3J13 meeting, I think the subcommittee should be officially
disbanded. As far as I can tell, we have accomplished nothing at all
since November, and nothing has happened lately to convince me that
things are going to change.
As I have been saying for quite a while now, I think the current trend
of tabling small, well-defined proposals while waiting for the Grand
Theory of Compilation to be revealed is a mistake -- what ever happened
to the divide-and-conquer approach? I don't think any of us have the
time to really take charge of the situation, put together a moby
proposal that addresses all of the issues, and push it through the full
committee. (We've already seen that there is such a diversity among
implementations that I find it hard to believe that implementors will be
able to agree on *any* Grand Theory.) On the other hand, there does
seem to be somewhat more agreement on some of the smaller issues
considered individually.
(flame off)
The cleanup subcommittee seems to be doing a good job of pushing issues
through and I think they would be a better chance of getting
compiler-related issues resolved than we would, given our track record
so far. Perhaps we should try to arrange for an official transfer of
responsibilities at the upcoming meeting?
-Sandra
-------
∂01-Mar-88 1548 CL-Cleanup-mailer Compiler cleanup issues, again
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 15:48:14 PST
Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Tue 1 Mar 88 18:47:54-EST
Date: Tue, 1 Mar 1988 18:47 EST
Message-ID: <RAM.12378961749.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: cl-cleanup@SAIL.STANFORD.EDU, mike%acorn@LIVE-OAK.LCS.MIT.EDU,
smh%franz.uucp@UCBARPA.BERKELEY.EDU
Subject: Compiler cleanup issues, again
In-reply-to: Msg of 1 Mar 1988 18:15-EST from sandra%orion at cs.utah.edu (Sandra J Loosemore)
Well, currently I haven't been to any X3J13 meeting because CMU won't
pay for peons to go flying around the country. Now that Scott Fahlman
has ceased to be active in X3J13, he has been pusing to have me made
the CMU delegate, so I might make it at some future meeting. But I
think that the value of in-person meeting time is overrated.
What sort of small, well-defined proposals (that have been tabled) do
you have in mind?
Rob
∂01-Mar-88 1718 CL-Cleanup-mailer Re: Compiler cleanup issues, again
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Mar 88 17:18:14 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29680; Tue, 1 Mar 88 18:18:51 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA06603; Tue, 1 Mar 88 18:18:47 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8803020118.AA06603@orion.utah.edu>
Date: Tue, 1 Mar 88 18:18:44 MST
Subject: Re: Compiler cleanup issues, again
To: Ram@c.cs.cmu.edu
Cc: cl-cleanup@sail.stanford.edu, mike%acorn@live-oak.lcs.mit.edu,
smh%franz.uucp@ucbarpa.berkeley.edu
In-Reply-To: Ram@C.CS.CMU.EDU, Tue, 1 Mar 1988 18:47 EST
> But I think that the value of in-person meeting time is overrated.
Actually, I agree. But there hasn't been anything happening via e-mail
or over the telephone, either.
> What sort of small, well-defined proposals (that have been tabled) do
> you have in mind?
I submitted two to the cleanup committee before the November meeting.
One was an attempt to specify how top-level forms in a file (such as
DEFMACRO or DEFSETF) affect how COMPILE-FILE compiles subsequent forms
in the file. At that time, the cleanup committee didn't want to
consider compiler-related issues at all, although there did seem to be
an overwhelming agreement with the actual content of the proposal.
The other proposal tried to specify how REQUIRE works in a little more
detail so that it would actually be meaningful to use in specifying
inter-file compilation dependencies. On this one, there was a general
feeling that PROVIDE and REQUIRE were a poor substitute for a DEFSYSTEM
utility. At the November meeting I volunteered to send a draft
DEFSYSTEM proposal around to the compiler subcommittee for review (and
in fact I have had both documentation and code sitting around for
months), but in spite of repeated promises from Steve, our mailing list
has never materialized and I don't have e-mail addresses for everybody
(where's David Bartley?).
> Rob
-Sandra
-------
∂01-Mar-88 1749 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 17:49:34 PST
Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 17:11:13 PST
Received: from bhopal.lucid.com by edsel id AA08004g; Tue, 1 Mar 88 17:00:45 PST
Received: by bhopal id AA07266g; Tue, 1 Mar 88 17:06:53 PST
Date: Tue, 1 Mar 88 17:06:53 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803020106.AA07266@bhopal.lucid.com>
To: pierson@mist
Cc: cl-cleanup@sail.Stanford.EDU
In-Reply-To: Dan L. Pierson's message of Tue, 01 Mar 88 16:02:35 EST <8803012102.AA21522@mist.UUCP>
Subject: Issue: LET-TOP-LEVEL (version 1)
re: Problem description:
The main defining forms in CLtL do not support defining (as opposed to
creating) closures in lexical environments.
. . .
Rationale:
Common Lisp tries to support lexical closures but this support is
really confined to anonymous lambdas within other function
definitions. This proposal attempts to move lexical closures closer
to first-class status in Common Lisp.
I don't believe this problem description. In particular, previous discussions
on these mailing lists suggested that DEFUN is merely a macro that turns into
something like:
(setf (symbol-function 'foo) #'(lambda (x y ...) ...))
so that anything said about "anonymous lambdas" should also be equally
applicable to "defun"'s.
re: Current practice:
The above example works in both Ibuki Lisp and Lucid, however only
Ibuki Lisp describes (SYMBOL-FUNCTION 'GET-THING) as a closure.
In Lucid Common Lisp, *all* functions are "closures". It doesn't serve
any purpose to distinguish one which has some captured lexical environment
"inside it" from another that doesn't. [However, I recently adduced reasons
why it would be profitable to distinguish those that are merely "trampolines"
back into the interpreter from the real "compiled functions".]
re: Current practice:
. . . Both
Symbolics and TI are reported to leave GET-THING and FREE-THING as
named-lambdas instead of compiling them.
At least some persons from Symbolics have agreed that this is a flaw in
the particular compiler's techniques -- not a flaw in language design.
-- JonL --
∂01-Mar-88 1830 CL-Cleanup-mailer compiler "clean-up" issues
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 18:30:00 PST
Date: 1 Mar 1988 21:26-EST
Sender: MATHIS@A.ISI.EDU
Subject: compiler "clean-up" issues
From: MATHIS@A.ISI.EDU
To: sandra%orion@CS.UTAH.EDU
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU
Cc: smh%franz.uucp@UCBARPA.BERKELEY.EDU
Cc: bartley%ti-csl@RELAY.CS.NET
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 1-Mar-88 21:26:26.MATHIS>
>At the November meeting I volunteered to send a draft
>DEFSYSTEM proposal around to the compiler subcommittee for review (and
>in fact I have had both documentation and code sitting around for
>months),
please bring some printed copies to Palo Alto
> but in spite of repeated promises from Steve, our mailing list
>has never materialized
we'll get Jan Zubkoff to take care of it after Palo Alto
> and I don't have e-mail addresses for everybody
>(where's David Bartley?).
Bartley%TI-CSL@CSNET-RELAY
∂02-Mar-88 0545 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 2 Mar 88 05:45:25 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA14503; Wed, 2 Mar 88 08:47:10 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA22737; Wed, 2 Mar 88 08:46:48 EST
Message-Id: <8803021346.AA22737@mist.UUCP>
To: Pavel.pa%Xerox.COM@multimax
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
In-Reply-To: Your message of Tue, 01 Mar 88 13:24:19 -0800.
Date: Wed, 02 Mar 88 08:46:45 EST
From: Dan L. Pierson <pierson@mist>
Date: Tue, 1 Mar 88 13:24:19 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
To: cl-cleanup@sail.stanford.edu
Please excuse my regrinding of your message where the lines didn't fit
after being indented.
First, I would claim that this is a ``clarification'' as opposed
to an ``addition''. I see no language in CLtL to support the
belief that DEFUN can only be used in certain scopes. This
reminds me of the debate over whether or not the compiler is
required to be reentrant; of course it is, for the same reason
that MAP is, for example: it's just another function with a
particular contract.
The CLtL reference is page 66, 5.3 Top-Level Forms:
"It is not illegal to use these forms at other than top level, but
whether it is meaningful to do so depends on context. Compilers,
for example, may not recognize these forms at other than top-level
contexts."
In any case, I don't oppose the proposal because I think it's important for
implementors to support this style. I have some other comments, though.
Why does the proposal not cover all of the defining forms? In
particular, why not DEFMACRO? It makes just as much sense for the
expansion function to be a closure. Of course, the compiler will not
be able to expand uses of that macro later in the same file, since it
can't provide the proper lexical environment to the expansion
function, but that just means that this style would have to be used in
a separate file that is loaded before compilation of uses of the
macro. The same goes for the defining forms DEFSTRUCT, DEFTYPE, etc.
I may have gotten confused here, my thinking was that since MACROLET
ignores lexical bindings that DEFMACRO should too. I don't feel
strongly about this though.
I not particularly happy with the explicit use of the term
``top-level'', but until Rob's compiler proposal gets a fair
hearing, I don't see any way around it.
It's the current CLtL language, I'd be happy to see it changed.
∂02-Mar-88 0553 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 2 Mar 88 05:53:18 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA14574; Wed, 2 Mar 88 08:55:06 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA22763; Wed, 2 Mar 88 08:54:44 EST
Message-Id: <8803021354.AA22763@mist.UUCP>
To: Jon L White <edsel!jonl%labrea.Stanford.EDU@multimax>
Cc: cl-cleanup%sail.Stanford.EDU@multimax
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
In-Reply-To: Your message of Tue, 01 Mar 88 17:06:53 -0800.
<8803020106.AA07266@bhopal.lucid.com>
Date: Wed, 02 Mar 88 08:54:41 EST
From: Dan L. Pierson <pierson@mist>
Date: Tue, 1 Mar 88 17:06:53 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
To: pierson@mist
Cc: cl-cleanup@sail.Stanford.EDU
Subject: Issue: LET-TOP-LEVEL (version 1)
As usual, please excuse regrinding.
re: Problem description:
The main defining forms in CLtL do not support defining (as opposed to
creating) closures in lexical environments.
. . .
Rationale:
Common Lisp tries to support lexical closures but this support is
really confined to anonymous lambdas within other function
definitions. This proposal attempts to move lexical closures closer
to first-class status in Common Lisp.
I don't believe this problem description. In particular, previous
discussions on these mailing lists suggested that DEFUN is merely
a macro that turns into something like:
(setf (symbol-function 'foo) #'(lambda (x y ...) ...))
so that anything said about "anonymous lambdas" should also be equally
applicable to "defun"'s.
The relevant sentence is on page 67: "Other implementation-dependent
bookkeeping actions may be taken as well by DEFUN."
re: Current practice:
The above example works in both Ibuki Lisp and Lucid, however only
Ibuki Lisp describes (SYMBOL-FUNCTION 'GET-THING) as a closure.
In Lucid Common Lisp, *all* functions are "closures". It doesn't
serve any purpose to distinguish one which has some captured
lexical environment "inside it" from another that doesn't.
[However, I recently adduced reasons why it would be profitable to
distinguish those that are merely "trampolines" back into the
interpreter from the real "compiled functions".]
I sit corrected, however there appears to be no way in Lucid Common
Lisp to inspect or debug a function which has some captured lexical
environment to see what the captured environment is so I couldn't find
this out.
re: Current practice:
. . . Both
Symbolics and TI are reported to leave GET-THING and FREE-THING as
named-lambdas instead of compiling them.
At least some persons from Symbolics have agreed that this is a flaw in
the particular compiler's techniques -- not a flaw in language design.
I agree philosophically, but see page 66, second paragraph on
Top-Level Forms.
-- JonL --
∂02-Mar-88 0821 CL-Cleanup-mailer Fair's Fair
To: cl-cleanup@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Steve Haflich asked me several weeks ago (more than a month ago) to
set up cl-compiler and cl-compiler-request, and I did. Here are the
current members:
smh%franz.uucp@berkeley.edu
sandra%orioncs.utah.edu
ram@c.cs.cmu.edu
mike%acorn@LIVE-OAK.LCS.MIT.EDU
Bartley%TI-CSL@RELAY.CS.NET
rg@ai.ai.mit.edu
vanroggen@hudson.dec.com
pierson@multimax.arpa
I thought I saw some message announcing its existence from Steve.
We should keep in mind that many of us are very busy and cannot
devote a tremendous amount of time to X3J13, and we shouldn't find
fault when we ourselves can be held up for criticism.
-rpg-
∂02-Mar-88 1415 CL-Cleanup-mailer Compiler cleanup issues, again
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 88 14:15:36 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA11300; Wed, 2 Mar 88 14:16:58 PST
Received: by franz (5.5/3.14)
id AA03377; Wed, 2 Mar 88 12:25:27 PST
Received: by feast (5.5/3.14)
id AA03448; Wed, 2 Mar 88 15:12:55 EST
Date: Wed, 2 Mar 88 15:12:55 EST
From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Message-Id: <8803022012.AA03448@feast>
To: sandra@cs.utah.edu
Cc: ram@c.cs.cmu.edu, mike%acorn@live-oak.lcs.mit.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 1 Mar 88 16:15:28 MST <8803012315.AA06356@orion.utah.edu>
Subject: Compiler cleanup issues, again
Hmmm. The murk begins to lift. We *have* had a mailing list since
January, courtesy of Gabriel, but it's just become clear that it isn't
reaching everyone. I kicked off an inquiry to Gabriel; perhaps he can
determine what's wrong. The list is cl-compiler@sail.stanford.edu
Anyway, this explains the missing responses to my earlier solicitation
about schedules for the Mar 14 week. I did receive replies from
Greenblatt and Pierson, but nothing from the rest.
I feel strongly that we should meet during the week. Twice would be
more productive than once. I'll be in the Bay area from Monday
afternoon through Saturday and can be available essentially any time
during that span.
I just reread your COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS. It
laudably clarifies the issues. Nonetheless, if I try to construct
particularly perverse examples, I think there are still additional
issues upon which this clarification should comment, if only to
identify for the portable code writer further things upon which he
*cannot* depend. I'll follow with a separate message to keep the
administrivia and technical issues separate.
∂02-Mar-88 1614 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 2 Mar 88 16:12:15 PST
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa11508; 2 Mar 88 21:51 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Wed, 2 Mar 88 21:19:16 gmt
Message-Id: <27876.8803022119@aiva.ed.ac.uk>
To: jonl <@labrea.stanford.edu:jonl@edsel.uucp>,
pierson <@multimax.arpa:pierson@mist.uucp>
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
Cc: cl-cleanup@sail.stanford.edu
] Date: Tue, 1 Mar 88 17:06:53 PST
] From: Jon L White <jonl%edsel@edu.stanford.labrea>
] Rationale:
] Common Lisp tries to support lexical closures but this support is
] really confined to anonymous lambdas within other function
] definitions. This proposal attempts to move lexical closures closer
] to first-class status in Common Lisp.
]
] I don't believe this problem description. In particular, previous
] discussions on these mailing lists suggested that DEFUN is merely a
] macro that turns into something like:
]
] (setf (symbol-function 'foo) #'(lambda (x y ...) ...))
I basically agree with this point -- that the rationale / problem
description is wrong, and for the reason given -- but there is still
something there, namely that DEFUN isn't always sufficiently equivalent
to such a macro.
Some implementations do not expand DEFUN into anything so reasonable, or
else define DEFUN as a special form that is not equivalent to the macro
expansion. They may thus end up with DEFUN semantics that are different
from the semantics of functions produced by the appropriate SETF of
SYMBOL-FUNCTION.
I would say these implementations are incorrect, because of the
description of DEFUN on page 67 of CLtL, where a LAMBDA expression for
the function is explicitly given and where it is specified that that
function is "defined in the lexical environment in which the DEFUN form
was executed", and because the macro definition of a macro implemented
as a special form is supposed to be equivalent to the special form
definition (CLtL, p. 57), but there are reasons why they may be able to
get away with it: (1) the specification of DEFUN is weakened by the
discussion of top-level forms on page 66, and (2) the macro equivalence
constraint is too weak -- implementations seem to regard it as allowing
the special form to make "improvements" that the macro does not. (See
the KCL example below.) In addition there is a more general problem
about macros that often occurs with defun -- nothing seems to rule out
expansions to expresions like (SYSTEM::DO-A-DEFUN '(DEFUN ...)).
(See the other example.)
Some cleanup issue should deal with the first problem: that top-level
forms may not be meaningful in some (unspecified) embedded contexts. It
should also address the meaning with respect to lexical context of
top-level defining forms other than DEFUN. Nonetheless, the top-level
forms in question are all macros, and so macro questions arise as well.
The discussion of top-level forms on page 66 of CLtL suggests that
compilers may not recognize these forms "properly" in embedded contexts.
Nothing [else] in CLtL allows compilers to fail to recognize macros.
The general macro issue involved might be the subject of a separate
cleanup issue.
Specifically, consider the implementation note on page 58. The
restriction on what may appear in macro expansions is insufficient to
"ensure that the expansion can be processed ... in an implementation-
independent manner". But what would be sufficient? A necessary
condition is that all implementation-specific special forms be
accompanied by equivalent (modulo efficiency and what else?) macro
definitions so that any expression can be "fully expanded" so as to
contain no implementation-specific special forms. CLtL does require
equivalent macros for special form implementations of operations
defined as macros in Common Lisp, but does not say anything about
other special forms an implementation may use. Such a requirement
should be added. However, for sufficiency something must rule out
functions of the DO-A-DEFUN sort (special forms in disguise). Perhaps
this is being addressed as a compiler issue?
--- DEFUN Examples ---
1. PopLog Common Lisp. Here the macro expansion is rather unhelpful
and, indeed, not equivalent to a SETF of SYMBOL-FUNCTION with the
appropriate LAMBDA expression. A DEFUN is always with respect to the
null lexical environment. Note that PopLog always compiles. Thus the
statement on page 66 that "compilers may not recognize these forms
properly in other than top-level contexts" may be cited to justify its
behavior. A SETF of SYMBOL function does work correctly.
== (macroexpand-1 '(defun f (x) x))
(SYSTEM::DEFUN '(F (X) X))
T
2. KCL. Although KCL does have a macro of the kind you suggest, the
expansion is not what DEFUN actually does. [Nonetheless, DEFUN inside
LET does work as desired (closure over the environment).]
KCl (Kyoto Common Lisp) June 3, 1987
>(macroexpand-1 '(defun f (x) x))
(PROGN (SETF (SYMBOL-FUNCTION 'F) #'(LAMBDA (X) (BLOCK F X))) 'F)
T
>(eval *)
F
>#'f
(LAMBDA-CLOSURE () () () (X) (BLOCK F X))
>(defun f (x) x)
F
>#'f
(LAMBDA-BLOCK F (X) X)
DEFUN in Gould CL has similar effects, but the macroexpansion is so long
that I won't show it here. Then there are other systems (e.g., VAX Lisp
v2.1) where the differences between the effects of the macro expansion
and the DEFUN are insignificant (but still present).
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂02-Mar-88 1757 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 88 17:57:09 PST
Received: by labrea.Stanford.EDU; Wed, 2 Mar 88 17:17:36 PST
Received: from bhopal.lucid.com by edsel id AA13022g; Wed, 2 Mar 88 15:35:33 PST
Received: by bhopal id AA10857g; Wed, 2 Mar 88 15:41:45 PST
Date: Wed, 2 Mar 88 15:41:45 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803022341.AA10857@bhopal.lucid.com>
To: pierson@mist
Cc: cl-cleanup@sail.Stanford.EDU
In-Reply-To: Dan L. Pierson's message of Wed, 02 Mar 88 08:54:41 EST <8803021354.AA22763@mist.UUCP>
Subject: Issue: LET-TOP-LEVEL (version 1)
re: [re-grinding]
Good. I do it too. The only reason I mention it here is to ask anyone
else who cares about it to raise their objections now, or forever ...
re: ... so that anything said about "anonymous lambdas" should also be
equally applicable to "defun"'s.
The relevant sentence is on page 67: "Other implementation-dependent
bookkeeping actions may be taken as well by DEFUN."
I don't believe that the sentence about "Other implementation-dependent ..."
negates the understanding of DEFUN as basically a rewrite to
(setf (symbol-function 'foo) #'(lambda (x y ...) ...))
If anything needs "clarifying" around this topic, perhaps it should be
just that. In particular, the sorts of things I imagine would legitimately
fall into "Other implementation-dependent ..." are items like hooks for
cross-referencing programs, file-indexing programs, extensions the
normal error-signalling upon redefinition (to facilitate "patch" files etc).
But nothing that would change the underlying equation of DEFUN's with
named lambda functions.
[Now, the corresponding issue re DEFMACRO isn't so nice. I hope some
excuse can be found to do the simple thing with it too, rather than
requiring some singular behaviour with regard to capturing lexical
environments. But this is another issue, another can of worms.]
-- JonL --
P.S. Apparently the return address in your messages isn't good enough
to be used through Labrea.Stanford.edu; do you have another?
∂02-Mar-88 2206 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 2 Mar 88 22:06:29 PST
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa11922; 2 Mar 88 22:39 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Wed, 2 Mar 88 22:38:43 gmt
Message-Id: <28475.8803022238@aiva.ed.ac.uk>
To: cl-cleanup@sail.stanford.edu, pierson <@multimax.arpa:pierson@mist.uucp>
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
] Date: Wed, 02 Mar 88 08:46:45 EST
] From: "Dan L. Pierson" <pierson@mist>
I apologize if my messages on this topic arrive at a time when they
are no longer relevant, something certainly possible given the trans-
Atlantic time delay. Anyway...
] I may have gotten confused here, my thinking was that since MACROLET
] ignores lexical bindings that DEFMACRO should too. I don't feel
] strongly about this though.
Just for a complete set of references: DEFMACRO is specified to
define the expansion function in the global (i.e. null lexical)
environment on page 145.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂03-Mar-88 0825 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 3 Mar 88 08:25:05 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA24445; Thu, 3 Mar 88 11:26:43 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA24921; Thu, 3 Mar 88 11:26:23 EST
Message-Id: <8803031626.AA24921@mist.UUCP>
To: Jon L White <edsel!jonl%labrea.Stanford.EDU@Multimax>
Cc: cl-cleanup%sail.Stanford.EDU@Multimax
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
In-Reply-To: Your message of Wed, 02 Mar 88 15:41:45 -0800.
<8803022341.AA10857@bhopal.lucid.com>
Date: Thu, 03 Mar 88 11:26:21 EST
From: Dan L. Pierson <pierson@mist>
re: ... so that anything said about "anonymous lambdas" should also
be equally applicable to "defun"'s.
The relevant sentence is on page 67: "Other implementation-dependent
bookkeeping actions may be taken as well by DEFUN."
I don't believe that the sentence about "Other
implementation-dependent ..." negates the understanding of DEFUN
as basically a rewrite to
(setf (symbol-function 'foo) #'(lambda (x y ...) ...))
If anything needs "clarifying" around this topic, perhaps it
should be just that. In particular, the sorts of things I imagine
would legitimately fall into "Other implementation-dependent ..."
are items like hooks for cross-referencing programs, file-indexing
programs, extensions the normal error-signalling upon redefinition
(to facilitate "patch" files etc).
I have no argument about "the essence of DEFUN", my point was that the
potential existence of this sort of bookkeeping activity prevents me
simply defining my own macro which expands to SETF of SYMBOL-FUNCTION
and using it instead of DEFUN. A couple of people seriously proposed
that alternative in the common-lisp discussion on this topic last
July.
∂03-Mar-88 1134 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Mar 88 11:34:39 PST
Received: from Salvador.ms by ArpaGateway.ms ; 03 MAR 88 10:45:04 PST
Date: Thu, 3 Mar 88 10:44:43 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
In-reply-to: <28475.8803022238@aiva.ed.ac.uk>
To: cl-cleanup@sail.stanford.edu
Message-ID: <880303-104504-6403@Xerox>
Jeff says:
``Just for a complete set of references: DEFMACRO is specified to define the
expansion function in the global (i.e. null lexical) environment on page 145.''
Right, but I thought that this was generally recognized to be an error, a
misunderstanding. There is no reason to restrict DEFMACRO in this way.
Dan says:
``I may have gotten confused here, my thinking was that since MACROLET ignores
lexical bindings that DEFMACRO should too. I don't feel strongly about this
though.''
MACROLET could also use lexical bindings, but it would lead to difficulties for
the compiler. That is, any use of the macro would have to be expanded each time
the form is evaluated. Thus, the uses would have to be interpreted, not
compiled. I don't recommend this to anyone, but it could be done, I suppose.
The real difference between DEFMACRO and MACROLET is that the expansion
functions produced by the former have indefinite extent, while those produced
by the latter have only dynamic extent, if that. It thus makes sense that they
might have different environment behavior.
Pavel
∂03-Mar-88 1204 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Mar 88 12:03:50 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 355463; Thu 3-Mar-88 15:03:25 EST
Date: Thu, 3 Mar 88 15:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
To: Pavel.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880303-104504-6403@Xerox>
Message-ID: <19880303200314.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 3 Mar 88 10:44:43 PST
From: Pavel.pa@Xerox.COM
The real difference between DEFMACRO and MACROLET is that the expansion
functions produced by the former have indefinite extent, while those produced
by the latter have only dynamic extent, if that.
That can't be quite right, since
(defun foo (x) (macrolet ((baz (x y)
(print `(baz ,x ,y expanded))
`(list ,x ,y)))
(lambda (z) (baz x z))))
(setq bar (foo 1))
(funcall bar 3) => (1 3)
and in an implementation that has an interpreter that doesn't preprocess
[not ours], the expander function for baz would not be called until
after foo had returned. Thus the expander function must have indefinite
extent.
The real difference between DEFMACRO and MACROLET, I think, is that in
DEFMACRO there is a clear separation between the lexical environment of
definition and the lexical environment of use, but in MACROLET the
use environment is always nested inside the definition environment.
However, that's not too relevant.
In a compiler or an interpreter that preprocesses, the definition
environment has not even been created at the time the expander has to be
called. This is quite clear for MACROLET. For DEFMACRO, it depends
on what the granularity for preprocessing is, but with the usual model
of file compilation, I think DEFMACRO has the same issue. Think about
this nonsensical program:
(let ((x (big-computation-that-returns-22/7)))
(defmacro foo (y) `(list ,x ,y))
(defun bar (z) (foo (1+ z))))
(bar 2) => (22/7 3) if it evaluates to anything, but how could the
compiler know that?
∂03-Mar-88 1227 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Mar 88 12:26:53 PST
Received: from Salvador.ms by ArpaGateway.ms ; 03 MAR 88 12:16:31 PST
Date: Thu, 3 Mar 88 12:15:58 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
In-reply-to: <19880303200314.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880303-121631-6583@Xerox>
Dave says:
``Think about this nonsensical program:
(let ((x (big-computation-that-returns-22/7)))
(defmacro foo (y) `(list ,x ,y))
(defun bar (z) (foo (1+ z))))
(bar 2) => (22/7 3) if it evaluates to anything, but how could the compiler know
that?''
This is just the issue that I addressed in my first message on this topic. When
you define a macro with a non-null closed-over environment, it is clear that the
compiler cannot know how to evaluate the expansion function. It is therefore
reasonable to assume that the compiler cannot expand uses of that macro during
the same compilation that encounters the DEFMACRO form. If you want a macro
like this, you must put the DEFMACRO in a separate file, compile and load that
file, and then compile any uses of the macro. This may be very reasonable for
some applications. In particular, it can be used in the same Scheme-style way
that uses a lexical variable to carry module-global state. For example, it
might be reasonable for DEFSTRUCT to be defined in this way, with the DEFMACRO
for DEFSTRUCT and the DEFUN's for the other structure-handling subprimitives all
within the same non-global lexical environment:
(let ((destruct-database ...))
(defmacro defstruct ...)
(defun tell-me-about-this-structure-type ...)
...other code that doesn't use DEFSTRUCT...)
This style doesn't disgust me and I see no reason not to support it.
Pavel
∂03-Mar-88 1453 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 14:53:52 PST
Received: by labrea.Stanford.EDU; Thu, 3 Mar 88 14:15:37 PST
Received: from bhopal.lucid.com by edsel id AA16357g; Thu, 3 Mar 88 13:41:55 PST
Received: by bhopal id AA13368g; Thu, 3 Mar 88 13:48:03 PST
Date: Thu, 3 Mar 88 13:48:03 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803032148.AA13368@bhopal.lucid.com>
To: jeff%aiva.edinburgh.ac.uk@nss.cs.ucl.ac.uk
Cc: cl-cleanup@sail.Stanford.EDU, pierson@multimax
In-Reply-To: Jeff Dalton's message of Wed, 2 Mar 88 21:19:16 gmt <27876.8803022119@aiva.ed.ac.uk>
Subject: Issue: LET-TOP-LEVEL (version 1)
KCL's variation on DEFUN may not in fact be significant; it appears as
though the special-form version is producing an "optimized" form of
closure, which "knows" that it didn't capture any lexical environment.
[But I don't really know about this -- someone more familiar with KCL
should comment further.]
The "top-level" issues, while impacting DEFUN usage, shouldn't be an issue
in DEFUN semantics (or at least, I don't think so). As you suggest, the
notion of "top-level" needs to be treated in its own right; I hope the
inability to find a complete solution for it won't prevent taking partial,
useful steps in the right direction.
Perhaps the most disturbing underlying problem is the failure of some
implementation to provide meaningful expansions for CLtL's special forms.
I certainly wouldn't expect such macroexpansions to be limited to the
documented CLtL functions, but having the meaning of them be hidden
underneath an "internal" function is defeating of the reason for having
the macro in the first place. I'm referring to an expansion like the
example you gave ("special forms in disguise"):
(DEFUN FOO ...) ==> (SYSTEM::DO-A-DEFUN '(DEFUN FOO ...))
It seems to me that many of the special forms could be documented in such
a way that *if* one were to use the obvious macro expansions on them, then
at worst he would miss out on some little niceity of the programming
environment; he should not be subject to major semantic difficulties.
E.g., to the degree that
(SYSTEM::DO-A-DEFUN '(DEFUN ...))
does something substanially different from
(SETF (SYMBOL-FUNCTION FOO) #'(LAMBDA ...))
it should only be in the realm of optional, informational features.
This kind of constraint would allow implementational flexibility while
permitting something useful to be said about "Standards".
-- JonL --
∂03-Mar-88 1456 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 14:55:55 PST
Received: by labrea.Stanford.EDU; Thu, 3 Mar 88 14:17:36 PST
Received: from kent-state.lucid.com by edsel id AA16479g; Thu, 3 Mar 88 14:14:12 PST
Received: by kent-state id AA26244g; Thu, 3 Mar 88 14:19:49 PST
Date: Thu, 3 Mar 88 14:19:49 PST
From: Eric Benson <edsel!eb@labrea.Stanford.EDU>
Message-Id: <8803032219.AA26244@kent-state.lucid.com>
To: Pavel.pa@xerox.com
Cc: Moon@stony-brook.scrc.symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Thu, 3 Mar 88 12:15:58 PST <880303-121631-6583@Xerox>
Subject: Issue: LET-TOP-LEVEL (version 1)
I concur with Pavel. I have written code that does exactly this sort
of thing. (Say what you want about this style). This creates a
constant vector of character names, used by NAME-CHAR and CHAR-NAME.
The two functions share a single structure, which is not stored in a
global variable. Notice I ended up using SETF of MACRO-FUNCTION
because of problems with DEFMACRO.
(let ((char-name-table (make-array (1+ (char-code #\Space))
:initial-element nil)))
(flet ((add-char-name (code name)
"Enter a new name for this character code"
(let* ((old-entry (svref char-name-table code))
(new-entry (cond ((null old-entry) name)
((consp old-entry) (cons name old-entry))
(t (list name old-entry)))))
(setf (svref char-name-table code) new-entry))))
(flet ((add-char-names (code namelist)
"Add names for the character codes in sequence from this one"
(dolist (name namelist)
(add-char-name code name)
(incf code))))
;;The standard ASCII names
(add-char-names 0 '("NUL" "SOH" "STX" "ETX" "EOT" "ENQ" "ACK" "BEL"
"BS" "HT" "NL" "VT" "NP" "CR" "SO" "SI"
"DLE" "DC1" "DC2" "DC3" "DC4" "NAK" "SYN" "ETB"
"CAN" "EM" "SUB" "ESC" "FS" "GS" "RS" "US"
"SP"))
;;Other names for the same characters
;;The last name added is the one returned by CHAR-NAME
(add-char-names 7 '("Bell" "Backspace" "Tab" "Linefeed"))
(add-char-name 0 "Null")
(add-char-name 12 "Page")
(add-char-name 13 "Return")
(add-char-name 32 "Space")
(add-char-name 10 "Newline")))
;;Bug in Common Lisp definition makes this not work:
;;(defmacro char-name-table-ref (code) ...)
(setf (macro-function 'char-name-table-ref)
#'(lambda (form env)
(declare (ignore env))
(let ((code (second form)))
`(svref ',char-name-table ,code)))))
∂03-Mar-88 2155 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 21:54:56 PST
Received: by labrea.Stanford.EDU; Thu, 3 Mar 88 21:16:22 PST
Received: from bhopal.lucid.com by edsel id AA17397g; Thu, 3 Mar 88 17:45:37 PST
Received: by bhopal id AA14256g; Thu, 3 Mar 88 17:51:53 PST
Date: Thu, 3 Mar 88 17:51:53 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803040151.AA14256@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com, Pavel.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 3 Mar 88 15:03 EST <19880303200314.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: LET-TOP-LEVEL (version 1)
re: (let ((x (big-computation-that-returns-22/7)))
(defmacro foo (y) `(list ,x ,y))
(defun bar (z) (foo (1+ z))))
(bar 2) => (22/7 3) if it evaluates to anything, but how could the
compiler know that?
This is perhaps a bad example of what you are trying to illustrate, for it
needlesly violates the "global environment" constraint of CLtL p145.
Since you are merely trying to show up a flaw in the "pre-processor" style
of evaluators (that pervasively expand macros before beginning evaluation),
you could adequately point that out with:
(let ((x (big-computation-that-returns-22/7)))
(defmacro foo (y) `(quote ,y))
;; or, use variant: (eval '(defmacro foo (y) `(quote ,y)))
(print x)
(defun bar (z) (foo (1+ z))))
[The problem is that the "call" to FOO inside BAR is resolved and macro-
expanded during the pre-process phase, at which time the "wrong" decision
will be made regarding it; during the evaluation phase, FOO will have
the macro definition of `(quote ,y) installed, but that is too late].
This also illustrates a problem with current compilation techniques (or,
rather, with the current lack of a definition for "top-level"), but without
involving the macro-expansion function in a lexical-capturing situation.
On the other hand, if we relenquish the strictures of CLtL p145 (which
some implementations do), then I don't see any problem with the following
example:
;;; Beginning of file
(eval-when (eval compile)
(let ((cnt 0))
(defmacro do-it-once (x) (incf cnt) `(PRINT ,x))
(defmacro total-count () ',cnt))
)
(defun foo (x)
(do-it-once x)
(do-it-once x)
(total-count))
;;; End of file
So I'm wondering what is meant by the claim:
"When you define a macro with a non-null closed-over environment, it is
clear that the compiler cannot know how to evaluate the expansion function.
It is therefore reasonable to assume that the compiler cannot expand uses
of that macro during the same compilation that encounters the DEFMACRO form.
If you want a macro like this, you must put the DEFMACRO in a separate file,
compile and load that file, and then compile any uses of the macro."
If this claim was intended to be limited to "solitary forms", as opposed
to files, then the following pathelogical function should be considered:
(defun tryit ()
(compiler-let ((cnt 0))
(compiler-let ((throw-away
(progn
(defmacro do-it-once (x) (incf cnt) `(QUOTE ,x))
(defmacro total-count () `(QUOTE ,cnt))
t)))
(defun foo (x)
(do-it-once x)
(do-it-once x)
(total-count)))))
I can make some sense of this claim if I make a lot of presumptions about
the notion of "top-level"; but this is still a murky area ("top-level").
For example, if the notion of top level "passes through" LET as well as
through COMPILER-LET, then the claim makes enough sense to be discussed;
and in that discussion, I would offer rebutting cases similar to the
ones above.
-- JonL --
∂04-Mar-88 0932 CL-Cleanup-mailer Re: Compiler cleanup issues, again
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Mar 88 09:32:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAR 88 09:32:39 PST
Date: 4 Mar 88 09:32 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Compiler cleanup issues, again
In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 1
Mar 88 16:15:28 MST
To: sandra%orion@cs.utah.edu
cc: smh%franz.uucp@ucbarpa.berkeley.edu, ram@c.cs.cmu.edu,
mike%acorn@LIVE-OAK.LCS.MIT.EDU, cl-cleanup@sail.stanford.edu
Message-ID: <880304-093239-8035@Xerox>
Sandra, I agree with you that if the compiler committee can't revive itself we
should take some more drastic action. Whether the cleanup committee does it or
another, new committee, (e.g., with you as chair), following the same model of
cleanup is less clear to me.
The problem with most of the proposals is that many of them require the
introduction of a new computational model for Common Lisp, with the following
attributes:
* clear definitions and descriptions of the relationships between read-time,
macro-expansion-time, lexical-analysis-time (compilation), and execution-time
* a clear(er) distinction between top-level and non-top-level
* the semantics of a "file" vs the interactive top level (read-eval-print) loop
* a model for errors which is more fine grained than the current "is an error",
"signals an error" and "must"
* a model for the semantics of declarations
The cleanup committee's proposal format and discussion mechanism isn't well
suited for concept definition. Given an accepted computational model, we can
consider, as cleanups, various changes to Common Lisp to bring things more in
line with that computational model. Perhaps it would help to try to separate out
the concept definition from cleanup proposals.
If previous experience holds, it may be that there will be iterations in the
concept definitions as various cleanup proposals are discussed.
My recollection is that "RAM's compiler proposal" combines both concept
definition and also proposals for changes to the language.
∂04-Mar-88 0940 CL-Cleanup-mailer Re: compiler-warning-break
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Mar 88 09:40:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAR 88 09:41:04 PST
Date: 4 Mar 88 09:40 PST
From: Masinter.pa@Xerox.COM
Subject: Re: compiler-warning-break
In-reply-to: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>'s message
of 23 Feb 88 14:06:00 EDT
To: vanroggen%aitg.decnet@hudson.dec.com
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <880304-094104-8049@Xerox>
Am I correct in reading your message ("As it stands we must oppose the
proposal"), that you feel the proposal writeup is unclear, and that you would
prefer to have a greater distinction between those errors for which
*break-on-warnings* have effect and those it does not?
(Your example, (EVAL-WHEN (COMPILE) (PRINT (+ 3 'A)))
, by the way, is not affected by *break-on-warnings*.)
My impression of the original intent is that the proposal writer very much
wanted *break-on-warnings* to cause a break "if the compiler happens to see a
variable that was bound but was unused", or other such anomolies.
However, this proposal was made before there had been more work on the signal
system. It might be more useful to arrive at a way that environment programs can
consistently interact with the compiler using well-defined signals rather than
the cruder *break-on-warnings* mechanism (which may well be obsolete.)
Do you think such a proposal be more suitable?
∂04-Mar-88 1052 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Mar 88 10:52:06 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAR 88 10:52:41 PST
Date: Fri, 4 Mar 88 10:52:27 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
In-reply-to: <8803040151.AA14256@bhopal.lucid.com>
To: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Cc: cl-cleanup@sail.stanford.EDU
Message-ID: <880304-105241-8203@Xerox>
I'm completely lost by your message. My point had nothing to do with top-level
forms at all. It was simply making a case for allowing DEFMACRO-defined
expansion functions to make use of their lexical environment.
Pavel
∂04-Mar-88 1140 CL-Cleanup-mailer Cleanup subcommittee meeting, Tuesday 15 March, 9:00-12:00
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Mar 88 11:40:35 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAR 88 11:32:47 PST
Date: 4 Mar 88 11:31 PST
From: Masinter.pa@Xerox.COM
Subject: Cleanup subcommittee meeting, Tuesday 15 March, 9:00-12:00
To: CL-Cleanup@sail.stanford.edu, vanroggen%aitg.decnet@hudson.dec.com
cc: Masinter.pa@Xerox.COM
Message-ID: <880304-113247-8304@Xerox>
The cleanup subcommittee will meet at Xerox PARC Tuesday 15 March, 9:00-12:00.
If you've not been here before, the address is
3333 Coyote Hill Road
Palo Alto, CA 94304
It is at the corner of Coyote Hill and Hillview, near the corner of Page Mill
Road and Foothill Expressway.
My phone number is (415) 494-4365.
I propose for the agenda that we take the list of current open issues (i.e., the
ones in the "in discussion" list) and spend a maximum of 5 minutes each seeing
who, if anyone, has some comment or opinion on the issue.
I think we will want to also reserve 30 minutes to talk about the schedule for
dealing with issues.
∂04-Mar-88 1304 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 13:02:12 PST
Received: by labrea.Stanford.EDU; Fri, 4 Mar 88 12:23:57 PST
Received: from bhopal.lucid.com by edsel id AA22090g; Fri, 4 Mar 88 12:50:24 PST
Received: by bhopal id AA17139g; Fri, 4 Mar 88 12:56:40 PST
Date: Fri, 4 Mar 88 12:56:40 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803042056.AA17139@bhopal.lucid.com>
To: Pavel.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Fri, 4 Mar 88 10:52:27 PST <880304-105241-8203@Xerox>
Subject: Issue: LET-TOP-LEVEL (version 1)
You were in the "TO:" line of my reply to Moon because he was commenting
on some distinction you were making between MACROLET and DEFMACRO. The
issue led into the problems of a compiler treating forms like DEFMACRO
"specially" at toplevel.
I took it for granted that we all prefer to have the restriction on
defmacro expansion functions removed.
-- JonL --
∂04-Mar-88 1414 CL-Cleanup-mailer Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Mar 88 14:13:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAR 88 13:53:03 PST
Date: 4 Mar 88 13:52 PST
From: Masinter.pa@Xerox.COM
Subject: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
In-reply-to: Pavel.pa's message of Fri, 4 Mar 88 10:52:27 PST
To: cl-cleanup@sail.stanford.EDU
Message-ID: <880304-135303-8627@Xerox>
I'd given a separate name, DEFMACRO-BODY-LEXICAL-ENVIRONMENT, to the issue of
the lexical environment of DEFMACRO. I think it is related to, but separate
from, the LET-TOP-LEVEL issue. LET-TOP-LEVEL is (from my perspective) a
clarification, while DEFMACRO-BODY-LEXICAL-ENVIRONMENT is a proposal for a
change.
I think we are in general agreement about LET-TOP-LEVEL with the only
discussion being wording (is this a "change" or a "clarification", etc., ) which
can probably be finessed.
DEFMACRO-BODY-LEXICAL-ENVIRONMENT has more problems, because we lack good
definitions the terms involved in giving a precise definition of when such
lexical environments can be used.
∂06-Mar-88 1148 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 88 11:48:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 356997; Sun 6-Mar-88 14:47:53 EST
Date: Sun, 6 Mar 88 14:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LET-TOP-LEVEL (version 1)
To: Pavel.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880303-121631-6583@Xerox>
Message-ID: <19880306194744.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 3 Mar 88 12:15:58 PST
From: Pavel.pa@Xerox.COM
Dave says:
``Think about this nonsensical program:
(let ((x (big-computation-that-returns-22/7)))
(defmacro foo (y) `(list ,x ,y))
(defun bar (z) (foo (1+ z))))
(bar 2) => (22/7 3) if it evaluates to anything, but how could the compiler know
that?''
This is just the issue that I addressed in my first message on this topic. When
you define a macro with a non-null closed-over environment, it is clear that the
compiler cannot know how to evaluate the expansion function. It is therefore
reasonable to assume that the compiler cannot expand uses of that macro during
the same compilation that encounters the DEFMACRO form. If you want a macro
like this, you must put the DEFMACRO in a separate file, compile and load that
file, and then compile any uses of the macro. This may be very reasonable for
some applications.
Right. The problem is, do you really want the definition of Common Lisp
to say that a DEFMACRO defines a macro that can be used in the same
compilation "sometimes"? "Sometimes" means it can be used if the body
of the macro doesn't reference any captured free identifiers, but not if
it does, unless the use is in a context where expansion happens at load
time instead of compile time. Ick.
I'm fairly sure that we went through this line of reasoning in 1983 or so,
and that's what led to the present restriction in the first paragraph on
CLtL page 145, as the lesser of two evils.
This style [captured free identifiers referenced in macro expander
functions] doesn't disgust me and I see no reason not to support it.
It doesn't disgust me either. The problem is the inconsistency you get
when a language supports both that style and the style of putting macro
definitions in the same file as macro invocations. This problem is
compounded by Common Lisp's present vague semantics of compilation, but
I think even with a crisp semantics of compilation, it would be a
problem; I might be wrong about that, depending on what the crisp
semantics said about "top level."
I'd rather not outlaw either style, but so far I don't see how to make
them coexist. I would not support changing Common Lisp incompatibly to
add the one style at the expense of outlawing the other, just because I
think incompatible changes are rarely warranted at this stage in Common
Lisp's life.
∂06-Mar-88 1203 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 88 12:02:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357003; Sun 6-Mar-88 15:02:18 EST
Date: Sun, 6 Mar 88 15:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LET-TOP-LEVEL (version 1)
To: Jon L White <edsel!jonl@labrea.Stanford.EDU>
cc: Pavel.pa@xerox.com, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8803040151.AA14256@bhopal.lucid.com>
Message-ID: <19880306200213.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 3 Mar 88 17:51:53 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
re: (let ((x (big-computation-that-returns-22/7)))
(defmacro foo (y) `(list ,x ,y))
(defun bar (z) (foo (1+ z))))
(bar 2) => (22/7 3) if it evaluates to anything, but how could the
compiler know that?
This is perhaps a bad example of what you are trying to illustrate, for it
needlesly violates the "global environment" constraint of CLtL p145.
On the contrary, violation of that constraint was precisely the topic
I was trying to illustrate. Removal of that constraint was the subject
under discussion.
Since you are merely trying to show up a flaw in the "pre-processor" style
of evaluators (that pervasively expand macros before beginning evaluation),
That is not at all what I was trying to do. You completely missed the
point. However, some of what you then went on to point out is worth
discussing; see below.
For more on the first point, see the message I just sent to Pavel cc to
CL-Cleanup.
....
On the other hand, if we relenquish the strictures of CLtL p145 (which
some implementations do), then I don't see any problem with the following
example:
;;; Beginning of file
(eval-when (eval compile)
(let ((cnt 0))
(defmacro do-it-once (x) (incf cnt) `(PRINT ,x))
(defmacro total-count () ',cnt))
)
(defun foo (x)
(do-it-once x)
(do-it-once x)
(total-count))
;;; End of file
This works because the variable named cnt is only referenced at compile
time. In a more complex case, such as others suggested earlier, where
some data structure was needed at run time too, this type of approach
would not work, or at least it's not clear that it would work. After
the problem of the conflict between the lexical environment of the macro
invocation and the lexical environment of the macro definition is resolved,
e.g. with Kohlbecker's scheme or one of the more recent similar schemes,
references to the compile time variable could be incorporated into code
resulting from macro expansion, and we would need to make sure that the
semantics of compilation and loading properly preserved the identity
of that variable binding.
An even weirder case would exist if you had said
(eval-when (eval load compile) ...), which would seem quite
reasonable to most users, and would be necessary if cnt had been
accessed by any defuns (in addition to defmacros). The eval-when
would evaluate its body twice, once at compile time, and again at
load time, creating two distinct variables named cnt. Now the
defuns would reference one variable and the defmacros would reference
the other. The point is that this kind of construction works fine
when interpreted, but does not work when compiled (to a file). We
want to minimize the semantic differences between those two ways of
executing a program.
So I'm wondering what is meant by the claim:
"When you define a macro with a non-null closed-over environment, it is
clear that the compiler cannot know how to evaluate the expansion function.
It is therefore reasonable to assume that the compiler cannot expand uses
of that macro during the same compilation that encounters the DEFMACRO form.
If you want a macro like this, you must put the DEFMACRO in a separate file,
compile and load that file, and then compile any uses of the macro."
You are correct in (implicitly) pointing out that this claim of Pavel's
should have been limited to the case where the non-null closed-over
environment (really the captured free identifiers) came from a load-time
binding rather than a compile-time binding. Throwing in an eval-when
compile (and not load) eliminates the issue by eliminating the magic
two-phase evaluation that the compiler does.
If this claim was intended to be limited to "solitary forms", as opposed
to files, then the following pathelogical function should be considered:
(defun tryit ()
(compiler-let ((cnt 0))
(compiler-let ((throw-away
(progn
(defmacro do-it-once (x) (incf cnt) `(QUOTE ,x))
(defmacro total-count () `(QUOTE ,cnt))
t)))
(defun foo (x)
(do-it-once x)
(do-it-once x)
(total-count)))))
I don't understand how this is relevant, since compiler-let is an operation
on dynamic variables, not lexical variables.
I can make some sense of this claim if I make a lot of presumptions about
the notion of "top-level"; but this is still a murky area ("top-level").
Precisely. See my message to Pavel cc to CL-Cleanup.
∂06-Mar-88 1230 CL-Cleanup-mailer Not about Issue: LET-TOP-LEVEL (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 88 12:30:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357014; Sun 6-Mar-88 15:29:39 EST
Date: Sun, 6 Mar 88 15:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Not about Issue: LET-TOP-LEVEL (version 1)
To: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Jon L White <jlw@SAIL.STANFORD.EDU>, pierson <pierson%mist@MULTIMAX.ARPA>,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <27876.8803022119@aiva.ed.ac.uk>
Message-ID: <19880306202933.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 2 Mar 88 21:19:16 gmt
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
I've extracted from this message a side-discussion, about the meaning
of Common Lisp's specification that except for a few primitive special
forms, all special forms are really macros that expand into something
other than special forms.
Some implementations do not expand DEFUN into anything so reasonable, or
else define DEFUN as a special form that is not equivalent to the macro
expansion. They may thus end up with DEFUN semantics that are different
from the semantics of functions produced by the appropriate SETF of
SYMBOL-FUNCTION.
I would say these implementations are incorrect, because of the
description of DEFUN on page 67 of CLtL, where a LAMBDA expression for
the function is explicitly given and where it is specified that that
function is "defined in the lexical environment in which the DEFUN form
was executed", and because the macro definition of a macro implemented
as a special form is supposed to be equivalent to the special form
definition (CLtL, p. 57)....
....In addition there is a more general problem
about macros that often occurs with defun -- nothing seems to rule out
expansions to expresions like (SYSTEM::DO-A-DEFUN '(DEFUN ...)).
Right. I've long felt that what CLtL says on page 57 is bankrupt. More
politely, it sounded like a nice idea, but when it comes to implement
it, you realize that the language does not contain all the primitives
needed to implement these macro expansions in a way that can truly be
understood by a portable program-understanding program. Furthermore,
as a practical matter it's unlikely that the implementations can all
agree with each other on the semantics of things like DEFUN at this
level of detail, because this impinges on the program development
environment; it's outside the domain of the language proper.
I think it would have been smarter to have more special forms. It's
easier to write a portable program-understanding program that recognizes
DEFUN, than to write one that recognizes the zillions of different
things that DEFUN might macroexpand into. Keeping the interface in
terms defined by CLtL ensures that the semantics that the
program-understanding program needs to be aware of are visible, and the
program development environment semantics that it's not interested in
are kept out of the way, rather than become visible as function calls to
implementation dependent functions.
Alternatively, we could have made a clean separation between the language
and the program-development environment, and defined as part of the
language all the hooks for the program-development environment. Then
we could have precisely specified the expansion of all these macros; not
just said "implementors are encouraged", but specified precisely what
the macros do. For example, we could have required DEFUN to be
implemented exactly as
(defmacro defun (name lambda-list &body declarations-and-forms
&environment env)
(multiple-value-bind (declarations documentation body)
(parse-declarations declarations-and-forms env)
`(progn
(program-development-environment:begin-definition
',name 'function)
(setf (symbol-function ',name)
(function (lambda ,lambda-list
(declare (name ,name))
(declare (documentation ,documentation))
,@declarations
,@body)))
(setf (documentation ',name 'function) ,documentation)
(compiler:notice-function-definition
,name ,lambda-list)
(program-development-environment:end-definition
',name 'function)
',name)))
Note all the things here that aren't in Common Lisp currently. I
don't guarantee that deeper thought wouldn't change the above expansion.
I think the above alternative approach would produce, in the end, a
better language. However, I suspect the amount of work required to get
there would be impractically large for either the present organizational
structure or the organizational structure that originally defined
Common Lisp.
A place where we went wrong in designing Common Lisp was to think that
the problem in writing a program-understanding program was in making it
understand all the special forms, and in thinking that that was a
syntactic problem, because special forms have idiosyncratic syntax.
It's true that it takes some code to understand all the special forms.
But that's just syntax, and it's easy. The real issue is idiosyncratic
semantics, and minimizing idiosyncratic syntax does nothing to help
with that problem, and in fact makes it worse by obscuring it and by
leading people to think at first that the problem has been solved
already.
Specifically, consider the implementation note on page 58. The
restriction on what may appear in macro expansions is insufficient to
"ensure that the expansion can be processed ... in an implementation-
independent manner". But what would be sufficient? A necessary
condition is that all implementation-specific special forms be
accompanied by equivalent (modulo efficiency and what else?) macro
definitions so that any expression can be "fully expanded" so as to
contain no implementation-specific special forms. CLtL does require
equivalent macros for special form implementations of operations
defined as macros in Common Lisp, but does not say anything about
other special forms an implementation may use. Such a requirement
should be added. However, for sufficiency something must rule out
functions of the DO-A-DEFUN sort (special forms in disguise).
I agree with you. My comments above are a restatement of the same
concerns, I think.
Perhaps this is being addressed as a compiler issue?
Not as far as I am aware. It's really not a compiler issue anyway:
if we only had an interpreter the issue would be exactly the same.
The meta-issue is whether to the goals on pp.1-3 of CLtL the community
wishes to add a goal of precisely defined, portable semantics for
things like DEFUN. If not, the half baked attempt on pp.57-8 should
be removed. If so, a lot needs to be added. I'm not sure any of
the existing committees are chartered to work on this.
∂06-Mar-88 1241 CL-Cleanup-mailer Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 88 12:41:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357018; Sun 6-Mar-88 15:41:14 EST
Date: Sun, 6 Mar 88 15:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880304-135303-8627@Xerox>
Message-ID: <19880306204110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 4 Mar 88 13:52 PST
From: Masinter.pa@Xerox.COM
I'd given a separate name, DEFMACRO-BODY-LEXICAL-ENVIRONMENT, to the issue of
the lexical environment of DEFMACRO. I think it is related to, but separate
from, the LET-TOP-LEVEL issue. LET-TOP-LEVEL is (from my perspective) a
clarification, while DEFMACRO-BODY-LEXICAL-ENVIRONMENT is a proposal for a
change.
I agree that these issues should be separated.
I think we are in general agreement about LET-TOP-LEVEL with the only
discussion being wording (is this a "change" or a "clarification", etc., ) which
can probably be finessed.
I don't think so. For example, the proposal only mentions LET. This is
obviously incomplete. It should at least mention LET*. But what about
the LAMBDA combination that is almost equivalent to LET? What about
other binding forms such as DO? What about other bindings besides
variables, such as MACROLET, FLET, and BLOCK? I think the proposal
needs much more careful attention to how narrow or broad its scope is
supposed to be. Understand that I do not object to the change proposed
by this proposal. I think that that change is going to be part of the
real proposal; I just don't think it makes sense to do that one change
by itself.
More generally, I think this proposal is patching Common Lisp's
ill-defined notion of "top level" instead of fixing it. While there
are some practical benefits to the patch, as it makes a small increase
in the number of programs that are portable, I don't think it really
solves the problem. In practical terms, I can't see asking my compiler
people to spend time implementing this when it's obvious that this is
an interim change and something better is, or should be, on its way.
I'd rather they spend their energies elsewhere until Common Lisp has
really got its act together on this "top level form" business, and then
they can implement what is really the right thing.
If this proposal were presented in its current form, I would oppose it.
No amount of wording changes would change my position. I want to see
a broader proposal.
DEFMACRO-BODY-LEXICAL-ENVIRONMENT has more problems, because we lack good
definitions the terms involved in giving a precise definition of when such
lexical environments can be used.
Agreed. See the other mail I sent today for more on that topic.
∂06-Mar-88 1620 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 88 16:20:26 PST
Received: by labrea.Stanford.EDU; Sun, 6 Mar 88 16:21:07 PST
Received: from bhopal.lucid.com by edsel id AA01167g; Sun, 6 Mar 88 16:03:38 PST
Received: by bhopal id AA20764g; Sun, 6 Mar 88 16:10:06 PST
Date: Sun, 6 Mar 88 16:10:06 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803070010.AA20764@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: Pavel.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Sun, 6 Mar 88 15:02 EST <19880306200213.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: LET-TOP-LEVEL (version 1)
re: This is perhaps a bad example of what you are trying to illustrate,
for it needlesly violates the "global environment" constraint of
CLtL p145.
On the contrary, violation of that constraint was precisely the topic
I was trying to illustrate. Removal of that constraint was the subject
under discussion.
Since you are merely trying to show up a flaw in the "pre-processor"...
That is not at all what I was trying to do.
Yes, Dave, I know that was not the main point of this series of discussions;
and I'm fully aware that you were trying to find another example where the
extent of the lexical environment for the expander function is critical.
I'm sorry for characterizing your comments so flippantly. What I was trying
to point out to you was that the problems of pre-processors occur long before
you get to the captured lexical environment problem. Since defmacros in
"the same form" as their clients don't in general work right during this
kind of pre-processing, I think it's moot to talk about the additional
problems of capturing lexical variables in such macros.
Thus your example:
(defun foo (x) (macrolet ((baz (x y)
(print `(baz ,x ,y expanded))
`(list ,x ,y)))
(lambda (z) (baz x z))))
nicely illustrates the need for indefinite extent of the lexical environment
containing the argument to FOO; but the example called "nonsensical program"
fails to make a similar point so strikingly, since attempts to compile or
pre-process it break down (in the typical pre-processor) regardless of the
lexical variable questions.
re: (defun tryit ()
(compiler-let ((cnt 0))
(compiler-let ((throw-away
(progn
(defmacro do-it-once (x) (incf cnt) `(QUOTE ,x))
(defmacro total-count () `(QUOTE ,cnt))
t)))
(defun foo (x)
(do-it-once x)
(do-it-once x)
(total-count)))))
I don't understand how this is relevant, since compiler-let is an operation
on dynamic variables, not lexical variables.
Ah, I thought this little cleverity might go over peoples' heads. The
issue being illustrated is how 'compiler-let' is a loophole, permitting
backdoor calls to EVAL during the simple compilation of a function. THERE
IS NO EXPECTATION THE VARIABLES USED ARE LEXICAL. The time-of-evaluation
issues related to "pre-processing" and/or compilation can to some degree be
circumvented by this loophole; thus there is no absolute need to put macros
in a file (or separate lexical environment) in order to get them to expand
"right".
Now it certainly would be a different question if the variable CNT in this
TRYIT example were referenced freely by the DEFUN for FOO. Then it would
be all very interesting to ask what the program might mean if the binding
for CNT were with a LET rather than a compiler LET (but the binding for
THROW-AWAY would still be a COMPILER-LET). This might, I think, illustrate
the weird situation that you have been hinting at, where there is a mismatch
of times at which a lexical environment must exist. [Note, of course, that
there is no "file" involved, so that not all of the issues called "Toplevel"
are restrictd to file compilations.]
However, your original "nonsensical program" doesn't have this property:
(let ((x (big-computation-that-returns-22/7)))
(defmacro foo (y) `(list ,x ,y))
(defun bar (z) (foo (1+ z))))
Notice that at eval time, (FOO (1+ Z)) expands as the equivalent:
(defun bar (z) (list 22/7 (1+ z)))
and this form doesn't have any pointers to the lexical environment outside
of the defun. And, conceivably, if "TopLevel" were to "pass thru" a LET,
then this would be the same situation at compile time.
IF instead, you had give the example as:
(defun bar (z) (list x (foo (1+ z))))
THEN it would illustrate the issue to be clarified, for then the
macroexpansion would lead to:
(defun bar (z) (list x (list 22/7 (1+ z))))
and "x" is the captured lexical variable whose compile-time/load-time
existence is in question. But I don't see this inconsistency as much
worse than the fact that macro expansions will "freeze" values at compile
time which would be different had the expansion function been run at a
later time (say, load time).
re: You are correct in (implicitly) pointing out that this claim of Pavel's
should have been limited to the case where the non-null closed-over
environment (really the captured free identifiers) came from a load-time
binding rather than a compile-time binding.
This clarification of the "claim" reduces its contention to the situation
where there is something like the ambiguity of compile-time/load-time just
mentioned. The TRYIT example says nothing about the reduced claim.
However, it still leaves open the question of what to do at compile time.
As I recall the discussions on this matter over the past years, I see:
(1) Many users who claim that having the defmacro expander function be
treated like any other form (i.e., its lexical environment is the
same as the surrounding context) is a very useful capabililty that
they full well understand how to use without causing problems;
(2) Attempts to illustrate an ambiguous extent situation for the lexical
environment of defmacros are not "garden variety" code, and are in
general subsidary to the problems of specifying even when the global
environment is to be changed [i.e., just when is the macro-function
"cell" named by a defmacro to be updated?].
To me, this looks like mounting evidence that retracting the special
limitation on defmacro would be in the best interests of the community.
On the other hand, I see stability as an even more paramount concern,
particularly since the user who wants the capability currently denied
him for defmacro can simply "hand-expand" the defmacro into a setf of
macro-function. No easy choice, again.
-- JonL --
P.S.: I also don't see future extensions to "TopLevel" being done in such a
way so that it will "pass thru" a LET. It's nice to contemplate this,
but I suspect it will cause more problems than it solves.
∂06-Mar-88 1935 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Mar 88 19:35:25 PST
Received: from Salvador.ms by ArpaGateway.ms ; 06 MAR 88 19:36:07 PST
From: masinter.PA@Xerox.COM
Date: 6 Mar 88 19:35:18 PST
Subject: Issue: LET-TOP-LEVEL (version 1)
To: cl-cleanup@sail.stanford.edu
Message-ID: <880306-193607-1193@Xerox>
I have the feeling we could go on forever on this topic with subtle examples
that illustrate various points... however, it doesn't seem to be converging.
I do have a feeling that if we can come to some agreement on the notion of "top
level" vs "embedded" and "file" and a few other things like that, it would help
out a lot in resolving things in subsequent discussions.
So: the floor is open for proposals for definitions of terms.
∂07-Mar-88 0637 CL-Cleanup-mailer compiler-warning-break
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 7 Mar 88 06:36:51 PST
Date: 7 Mar 88 09:27:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: compiler-warning-break
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
From: Masinter.pa@Xerox.COM Message-ID: <880304-094104-8049@Xerox>
Am I correct in reading your message ("As it stands we must oppose the
proposal"), that you feel the proposal writeup is unclear, and that you would
prefer to have a greater distinction between those errors for which
*break-on-warnings* have effect and those it does not?
Yes, not only a greater distinction, but some definition as to when and
how this could be used. What kinds of conditions must be "warned"?
Are "potential errors" detected by the compiler real "errors"? Is there
a difference in such behavior between COMPILE and COMPILE-FILE?
(Your example, (EVAL-WHEN (COMPILE) (PRINT (+ 3 'A)))
, by the way, is not affected by *break-on-warnings*.)
You're right. (Unless an implementation decided to WARN when an arithmetic
operation got illegal arguments, I suppose.) However the point of the
example was to distinguish run-time signalled conditions from conditions
detected by the compiler in examining source code.
My impression of the original intent is that the proposal writer very much
wanted *break-on-warnings* to cause a break "if the compiler happens to see a
variable that was bound but was unused", or other such anomolies.
However, this proposal was made before there had been more work on the signal
system. It might be more useful to arrive at a way that environment programs can
consistently interact with the compiler using well-defined signals rather than
the cruder *break-on-warnings* mechanism (which may well be obsolete.)
Do you think such a proposal be more suitable?
Yes, I think deciding on an error system and deciding what conditions are
signalled by the compiler should precede decisions on such minor things
as what *BREAK-ON-WARNINGS* means in a few particular situations.
---Walter
------
∂07-Mar-88 0936 CL-Cleanup-mailer New issues for the "pending" list, from Japan
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Mar 88 09:36:50 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 MAR 88 09:29:04 PST
Date: 7 Mar 88 09:27 PST
From: Masinter.pa@Xerox.COM
Subject: New issues for the "pending" list, from Japan
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880307-092904-1841@Xerox>
These issues were derived from the list submitted by the Japanese technical
working group on Lisp. They are all "need volunteer".
EVAL-OTHER
(Should structures, arrays, vectors, ... self-evaluate?)
LAMBDA-LIST-DUPLICATES
(Is it an error to have the same symbol more than once
in a lambda list?)
MAPPING-DESTRUCTIVE-INTERACTION
(The interaction of mapping functions and DOLIST and
destructive operations on the list operated on is explictly
left undefined.)
SPECIAL-VARIABLE-TEST
(Want a way to ask if a variable is proclaimed special.)
∂07-Mar-88 1030 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 10:30:03 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357557; Mon 7-Mar-88 13:30:18 EST
Date: Mon, 7 Mar 88 13:29 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880307132956.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: SPECIAL-VARIABLE-TEST
References: Declaring Global Variables and Named Constants (pp68-69),
Declaration Specifiers (p157)
Category: ADDITION
Edit history: 07-Mar-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL does not define a way to test to see if a variable has been
proclaimed special.
Programs such as macros, code-walkers, and program-generating programs
may need such information from time to time in order to do certain kinds
of reasoning about code-motion, unused variables, etc.
Proposal (SPECIAL-VARIABLE-TEST:SPECIALP)
Add a function SPECIAL-VARIABLE-P by analogy with SPECIAL-FORM-P
which is defined as:
SPECIAL-VARIABLE-P symbol &optional environment [Function]
Returns T iff -symbol- names a variable which is SPECIAL in the
indicated lexical -environment-. Otherwise, it returns NIL.
It is an error if -symbol- is not a symbol. If not supplied, the
-environment- defaults to NIL, meaning the null lexical environment.
Test Case:
(PROCLAIM '(SPECIAL SPECIAL-FOO))
(MACROLET ((TEST (NAME &ENVIRONMENT ENV)
`(,NAME ',(SPECIAL-VARIABLE-P NAME ENV))))
(LIST* (TEST SPECIAL-FOO) ;0
(TEST FOO)
(LET ((SPECIAL-FOO 1) (FOO 1))
(LIST* (TEST SPECIAL-FOO) ;1
(TEST FOO)
(LET ((SPECIAL-FOO 2) (FOO 2))
(DECLARE (SPECIAL FOO))
(LIST* (TEST SPECIAL-FOO) ;2
(TEST FOO)
(LET ((SPECIAL-FOO 3) (FOO 3))
(LIST (TEST SPECIAL-FOO) ;3
(TEST FOO)))))))))
=> ((SPECIAL-FOO T) (FOO NIL) ;0
(SPECIAL-FOO T) (FOO NIL) ;1
(SPECIAL-FOO T) (FOO T) ;2
(SPECIAL-FOO T) (FOO NIL)) ;3
Rationale:
This would allow programs that reason about other programs to obtain
important information about SPECIAL declarations and proclamations.
Current Practice:
Interpreters and compilers must, of necessity, have a way to do this
internally.
In some implementations, information about special variable proclamations
is kept on a symbol's plist, and users eventually "figure out" how to take
advantage of that.
In most implementations, getting information about special declarations
is neither documented nor easy to "figure out".
Cost to Implementors:
By necessity, compilers and interpreters must have a way to get the
information returned by this facility. In general, it should just be
a matter of providing a program interface to that facility.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
Some code-walkers, macros, etc. would continue be hard to write in a
portable way.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Although SPECIAL variables provide some benefit to Common Lisp, that
benefit has not been without price. It's difficult to do proper code
analysis if lexical and special variables look the same. The presence
of this operator makes it easier to write code which reasons clearly
and correctly about other programs, and so will probably tend to
improve the aesthetics of such programs.
Discussion:
This proposal came to the Cleanup committee from the Japanese community.
Pitman wrote it up formally and supports SPECIAL-VARIABLE-TEST:SPECIALP.
∂07-Mar-88 1040 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 10:40:34 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 357573; 7 Mar 88 13:40:46 EST
Date: Mon, 7 Mar 88 13:40 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880307132956.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <880307134024.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
That should have been `'(,NAME ,(SPECIAL-VARIABLE-P NAME ENV))
rather than `(,NAME ',(SPECIAL-VARIABLE-P NAME ENV))
in the test case, of course. Sorry about that. Whoever does the next
draft should make that correction.
∂07-Mar-88 1043 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 10:43:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357577; Mon 7-Mar-88 13:44:05 EST
Date: Mon, 7 Mar 88 13:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880307132956.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880307184333.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve of SPECIAL-VARIABLE-TEST:SPECIALP (except why isn't
the proposal named SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P ?)
For the current practice section: Symbolics Genera has a function
named SYS:SPECIAL-VARIABLE-P that does this. The function is not
documented, currently, probably because we've been waiting to see
if Common Lisp standardizes on a different name.
∂07-Mar-88 1059 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 10:59:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357594; Mon 7-Mar-88 14:00:08 EST
Date: Mon, 7 Mar 88 13:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880307132956.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Supersedes: <19880307184333.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: I noticed an overlooked issue after sending this message the first time.
Message-ID: <19880307185953.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve of SPECIAL-VARIABLE-TEST:SPECIALP (except why isn't
the proposal named SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P ?)
For the current practice section: Symbolics Genera has a function
named SYS:SPECIAL-VARIABLE-P that does this. The function is not
documented, currently, probably because we've been waiting to see
if Common Lisp standardizes on a different name.
After looking at our SYS:SPECIAL-VARIABLE-P, I note a possible oversight
in this proposal. With Common Lisp, as opposed to Zetalisp, scoping
rules for SPECIAL declarations, there are two distinct questions one can
ask about the declaration of a variable. One is, "would a reference to
this variable in this environment be special?". The second is, "would a
binding of this variable in this environment be special?". The proposal
only answers the first question.
The second question is a little harder because you need to figure out
how to feed local declarations attached to the binding to the predicate.
I suggest a very simple solution: to ask the second question, one
supplies NIL as the environment, which accesses the proclamations
without the declarations, and then one handles manually any local
declarations attached to the binding. This is minimalist but should
do the job. The proposal doesn't need any technical changes for this,
but should include a brief mention of this issue and the solution.
∂07-Mar-88 1206 CL-Cleanup-mailer Issue: LAMBDA-LIST-DUPLICATES (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 12:06:20 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357667; Mon 7-Mar-88 15:06:35 EST
Date: Mon, 7 Mar 88 15:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880307150614.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: LAMBDA-LIST-DUPLICATES
References: 5.1.2 Variables (pp55-56)
5.2.2 Lambda-Expressions (pp59-65),
LET* (p111-112), PROG* (pp131-132)
Category: ADDITION
Edit history: 07-Mar-88, Version 1 by Pitman
Related Issues: DECLARATION-SCOPE
Status: For Internal Discussion
Problem Description:
CLtL forbids binding the same variable more than once in the same
binding form. This rule is claimed by some to be overly restrictive
because there are some well-defined situations in which it would be
useful to duplicate a variable name in the same binding list.
Proposal (LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE):
Allow variable names to be repeated in situations where bindings are
sequential and the binding construct is non-iterative (specifically,
in the &AUX part of a normal lambda list, in the bindings of LET*, and
in the bindings of PROG*).
Test Case:
((LAMBDA (B &AUX (B (+ B 1)) (B (+ B 1))) B) 0) => 2
(LET* ((B 0) (B (+ B 1))) B) => 1
(PROG* ((B 0) (B (+ B 1))) (RETURN B)) => 1
Rationale:
Because these bindings are inherently sequential and non-iterative, there
would no ambiguity about the intended scope bindings, and it is sometimes
useful to repeat the name of a binding when doing various kinds of
encapsulations or successive refinements to the same value.
The intent of duplicated bindings in "parallel binding" constructs like
LET or iterative constructs like DO* is less easy to predict, so it is
not proposed that the current rule be relaxed for such constructs.
Current Practice:
The Symbolics implementation currently checks for this case and
signals an error.
[Others?]
Cost to Implementors:
Converting would be relatively easy, but not completely trivial.
There is some interaction with declaration processing which becomes
involved, too (see issue DECLARATION-SCOPE).
Cost to Users:
None. This is an upward-compatible change.
Cost of Non-Adoption:
Some useful expressional style would be lost.
Benefits:
A useful expressional style would be made available.
Aesthetics:
The rule for variable duplication would be more syntactically complex
but pragmatically simpler.
Discussion:
A request for a discussion of this issue came from the Japanese community.
Pitman drafted this formal proposal and supports
LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE.
∂07-Mar-88 1232 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 12:32:39 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357713; Mon 7-Mar-88 15:33:00 EST
Date: Mon, 7 Mar 88 15:32 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880307185953.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880307153239.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 7 Mar 88 13:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... why isn't the proposal named SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P ...
Editing error. I changed the name from SPECIALP to SPECIAL-VARIABLE-P
while evolving the proposal and didn't make the change completely enough.
For clarity, someone should change it in the next draft.
For the current practice section: Symbolics Genera has a function
named SYS:SPECIAL-VARIABLE-P that does this. The function is not
documented, currently, probably because we've been waiting to see
if Common Lisp standardizes on a different name.
After looking at our SYS:SPECIAL-VARIABLE-P, I note a possible oversight
in this proposal. With Common Lisp, as opposed to Zetalisp, scoping
rules for SPECIAL declarations, there are two distinct questions one can
ask about the declaration of a variable. One is, "would a reference to
this variable in this environment be special?". The second is, "would a
binding of this variable in this environment be special?". The proposal
only answers the first question.
The second question is a little harder because you need to figure out
how to feed local declarations attached to the binding to the predicate.
I suggest a very simple solution: to ask the second question, one
supplies NIL as the environment, which accesses the proclamations
without the declarations, and then one handles manually any local
declarations attached to the binding. This is minimalist but should
do the job. The proposal doesn't need any technical changes for this,
but should include a brief mention of this issue and the solution.
This sounds mostly ok, though we'd need to be clear about which of these
an appropriate type-2 call to SPECIAL-VARIABLE-P looked like:
1. (SPECIAL-VARIABLE-P 'FOO '((DECLARE (SPECIAL X) (FIXNUM X))
(DECLARE (SPECIAL Y))))
2. (SPECIAL-VARIABLE-P 'FOO '(DECLARE (SPECIAL X) (FIXNUM X) (SPECIAL Y)))
3. (SPECIAL-VARIABLE-P 'FOO '(((SPECIAL X) (FIXNUM X)) ((SPECIAL Y))))
4. (SPECIAL-VARIABLE-P 'FOO '((SPECIAL X) (FIXNUM X) (SPECIAL Y)))
5. (SPECIAL-VARIABLE-P 'FOO '(X Y))
1, 4, and 5 look ok to me. 1 seems like it would be easiest to arrange
for in practice, and hence perhaps the best choice.
I note also that this only works because special bindings are not
pervasive. If they were not, you'd have to have the environment argument
also. In philosophy courses I've taken, we'd say it is "true" that the
environment is not needed, but it is not "necessarily true" (i.e., there
exist consistent, possible universes in which it is not true). For
implementational flexibility in case anyone -wants- pervasive bindings
(as an, arguably incompatible, extension) or in case we later want to
change the language, it might be cleaner to say
(SPECIAL-VARIABLE-P 'FOO ENV '(...decls...))
and to mention to implementors that in fact the ENV may be ignored if the
decls are passed. It's especially interesting in the case of
(SPECIAL-VARIABLE-P 'FOO NIL) ;null environment
vs (SPECIAL-VARIABLE-P 'FOO '()) ;no decls
because these both do the same thing but for completely different reasons.
It really stretches the pun to unreasonable lengths. I'd be content to
rewrite the proposal to accomodate this additional issue if others
concurred.
∂07-Mar-88 1253 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 12:53:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357734; Mon 7-Mar-88 15:54:07 EST
Date: Mon, 7 Mar 88 15:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880307153239.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880307205356.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 7 Mar 88 15:32 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Mon, 7 Mar 88 13:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
After looking at our SYS:SPECIAL-VARIABLE-P, I note a possible oversight
in this proposal. With Common Lisp, as opposed to Zetalisp, scoping
rules for SPECIAL declarations, there are two distinct questions one can
ask about the declaration of a variable. One is, "would a reference to
this variable in this environment be special?". The second is, "would a
binding of this variable in this environment be special?". The proposal
only answers the first question.
The second question is a little harder because you need to figure out
how to feed local declarations attached to the binding to the predicate.
I suggest a very simple solution: to ask the second question, one
supplies NIL as the environment, which accesses the proclamations
without the declarations, and then one handles manually any local
declarations attached to the binding. This is minimalist but should
do the job. The proposal doesn't need any technical changes for this,
but should include a brief mention of this issue and the solution.
This sounds mostly ok, though we'd need to be clear about which of these
an appropriate type-2 call to SPECIAL-VARIABLE-P looked like:
1. (SPECIAL-VARIABLE-P 'FOO '((DECLARE (SPECIAL X) (FIXNUM X))
(DECLARE (SPECIAL Y))))
2. (SPECIAL-VARIABLE-P 'FOO '(DECLARE (SPECIAL X) (FIXNUM X) (SPECIAL Y)))
3. (SPECIAL-VARIABLE-P 'FOO '(((SPECIAL X) (FIXNUM X)) ((SPECIAL Y))))
4. (SPECIAL-VARIABLE-P 'FOO '((SPECIAL X) (FIXNUM X) (SPECIAL Y)))
5. (SPECIAL-VARIABLE-P 'FOO '(X Y))
Huh? I was proposing that the second argument to SPECIAL-VARIABLE-P
would be NIL and the caller would have to do his own declaration parsing.
Thus (OR (SPECIAL-VARIABLE-P var NIL) (MEMBER var parsed-special-dcls)).
If we wanted a function to help compute parsed-special-dcls, that would
be a separate function. I'm not sure we need one as part of the Common
Lisp standard.
I note also that this only works because special bindings are not
pervasive.
Yes, in Zetalisp they are pervasive and the issue does not arise, since
the two questions yield the same answer.
[philosophy deleted]
∂07-Mar-88 1257 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 12:57:13 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357740; Mon 7-Mar-88 15:57:37 EST
Date: Mon, 7 Mar 88 15:57 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EVAL-OTHER (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880307155717.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: EVAL-OTHER
References: 5.1.1 Self-Evaluating Forms (p55)
Category: ADDITION/CLARIFICATION
Edit history: 07-Mar-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL does not specify what the evaluation behavior of some data types.
Proposal (EVAL-OTHER:SELF-EVALUATE):
Standard data types (those mentioned by CLtL) other than those for which
a more explicit evaluation rule exists would be defined to self-evaluate.
Such data types include, for example, structures, arrays, vectors, and
pathnames.
Structure types defined by users using DEFSTRUCT should also self-evaluate
unless an explicit implementation type for the structure is given in the
DEFSTRUCT, in which case the rule for evaluation of that type should be
used. (This is important in the case of type LIST.)
Test Case:
(LET ((TEMP (MAKE-PATHNAME))) (EQ TEMP (EVAL TEMP))) => T
(LET ((TEMP (MAKE-ARRAY NIL))) (EQ TEMP (EVAL TEMP))) => T
Rationale:
There are numerous possible positions that could be taken, from
requiring that an error be signalled for all of these cases to
requiring that these all have some useful behavior.
By making implementations agree, code portability is enhanced.
By choosing not to make a change from things being useful to things
being useful (i.e., by biasing the decision away from the "signal
an error" end of the choice spectrum), the least interruption is
caused to implementations which already have working code.
There is still some chance that implementations will have some other
behavior than either signalling an error or self-evaluating, but there
are probably few if any.
Current Practice:
In many implementations, the other data types besides those mentioned in
CLtL will self-evaluate.
Cost to Implementors:
The cost is probably small. This is probably an "upward compatible"
change for most or all implementations -- a few lines of change in the
interpreter and/or compiler. Some code walkers may be affected as well.
Cost to Users:
None, if they are not exploiting implementation-dependent features of
some implementation that is being forced to make an incompatible change.
There should be no performance impact since the evaluator's test for these
new data types can simply be made to follow other tests already in place,
so existing code will not be slowed.
Cost of Non-Adoption:
Implementations will continue to differ in this relatively
user-visible way.
Benefits:
Portability will be enhanced because implementations will tend to agree
in places where they have traditionally not always agreed.
Aesthetics:
Some fans of 3LISP may find this invasive to their sense of distinction
between objects and the notation used to describe objects. In general,
however, this is a fairly picky detail that is not likely to trouble the
average programmer.
Discussion:
This idea for this proposal was suggested by the Japanese community.
Pitman drafted the formal proposal and supports EVAL-OTHER:SELF-EVALUATE.
∂07-Mar-88 1324 CL-Cleanup-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 13:24:38 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357783; Mon 7-Mar-88 16:25:04 EST
Date: Mon, 7 Mar 88 16:24 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880307162443.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: MAPPING-DESTRUCTIVE-INTERACTION
References: MAPCAR, MAPLIST, ... (p128);
DOLIST (p126); MAPHASH (p285);
DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS (pp187-188);
All functions using :TEST
Category: CLARIFICATION
Edit history: 07-Mar-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The interaction of mapping functions and DOLIST with destructive
operations on the list being operated on is unclear. For example,
if you destructively modify some tail of a list being mapped down,
does that affect the mapping process?
Proposal (MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE):
Document the fact that it is an error for code run by a
"structure traversing" operation to destructively modify the
set of things being traversed while the traversal operation is
going on.
Test Case:
(LET* ((L (LIST 'A 'B 'C)) (LL L) (I 0))
(DOLIST (FOO L)
(INCF I)
(IF (EQ FOO 'B)
(SETF (CDR LL) NIL)
(POP LL)))
(LIST I L)) might return (2 (A B)) or (3 (A B)), for example.
Rationale:
The likelihood that the user will want to destructively alter a structure
while it is being traversed is low. The likelihood that such code would
be readable and maintainable is also low. The likelihood that a compiler
could do some interesting optimization if this point were not pinned down
is high enough to be the overriding consideration in this case.
Current Practice:
The Symbolics implementation of DOLIST returns (3 (A B)) for the test case.
Cost to Implementors:
None. This simply makes the status quo explicit.
Cost to Users:
Technically none. People who were mistakenly assuming that CLtL guaranteed
things which it does not might be inclined to rewrite their code in a more
portable way.
Cost of Non-Adoption:
Users would be less informed.
Benefits:
users would be more informed.
Aesthetics:
Some might say it would be clearer to define this one way or the other, but
advocates of both camps exist and their arguments are fairly symmetric.
In any case, since this is a proposal to preserve the status quo, it has no
major impact on aesthetics.
Discussion:
This idea for this proposal was suggested by the Japanese community.
Pitman drafted the formal proposal and supports
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE.
∂07-Mar-88 1325 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 13:25:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357784; Mon 7-Mar-88 16:25:54 EST
Date: Mon, 7 Mar 88 16:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EVAL-OTHER (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880307155717.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880307212550.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor EVAL-OTHER:SELF-EVALUATE.
Under rationale, the sentence beginning "By choosing not to make a
change from things being useful to things being useful" is probably
a typographical error.
I remember this issue being discussed only a few months ago on either
Common-Lisp or CL-Cleanup. I think somebody had some reasons to oppose
this proposal, but I don't remember finding them convincing. Sorry I
don't remember any of the details, I mention it because perhaps this
will stimulate someone else's memory.
∂07-Mar-88 1326 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 13:26:32 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357786; Mon 7-Mar-88 16:26:49 EST
Date: Mon, 7 Mar 88 16:26 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880307205356.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880307162627.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 7 Mar 88 15:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
...
Huh? I was proposing that the second argument to SPECIAL-VARIABLE-P
would be NIL and the caller would have to do his own declaration parsing.
Thus (OR (SPECIAL-VARIABLE-P var NIL) (MEMBER var parsed-special-dcls)).
Oh, I see. This is fine.
∂07-Mar-88 1410 CL-Cleanup-mailer Are you coming to the cleanup meeting?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Mar 88 14:10:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 MAR 88 14:03:30 PST
Date: 7 Mar 88 14:03 PST
From: Masinter.pa@Xerox.COM
Subject: Are you coming to the cleanup meeting?
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880307-140330-2633@Xerox>
As I was ordering bagels etc for next Tuesday morning, I realized that I had no
idea how many people would be here. If you're coming to the cleanup meeting,
could you let me know?
∂07-Mar-88 1719 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1)
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 17:19:34 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Mon 7 Mar 88 20:19:44-EST
Date: Mon, 7 Mar 1988 20:19 EST
Message-ID: <FAHLMAN.12380551338.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: EVAL-OTHER (Version 1)
In-reply-to: Msg of 7 Mar 1988 16:25-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I favor EVAL-OTHER:SELF-EVALUATE. -- Moon
Me too. I don't remember any useful discussion of this recently, but I
do remember the original design discussions. It was proposed that
everything but lists and symbols evaluate to themselves, but at the time
(this was quite early in the process) some people felt that this might
close out interesting parts of the design space that might turn out to
be useful for something. This hasn't happened, and I think it would be
reasonable to close this door now. Some users do find it confusing that
you have to quote vectors but not strings.
-- Scott
∂07-Mar-88 2157 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 21:57:03 PST
Received: by labrea.Stanford.EDU; Mon, 7 Mar 88 21:57:43 PST
Received: from bhopal.lucid.com by edsel id AA05980g; Mon, 7 Mar 88 21:35:06 PST
Received: by bhopal id AA05406g; Mon, 7 Mar 88 21:41:38 PST
Date: Mon, 7 Mar 88 21:41:38 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803080541.AA05406@bhopal.lucid.com>
To: masinter.PA@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.PA@Xerox.COM's message of 6 Mar 88 19:35:18 PST <880306-193607-1193@Xerox>
Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1)
re: I do have a feeling that if we can come to some agreement on the notion of
"top level" vs "embedded" and "file" and a few other things like that, it
would help out a lot in resolving things in subsequent discussions.
Maybe not. At least not for the root cause that spurred the "flurry" of
examples. In case you hadn't noticed, the discussion that went on under
the subjet line of "LET-TOP-LEVEL (version 1)", after the first round of
interchanges, is really about an issue that would have better been by-lined
under the DEFMACRO-BODY-LEXICAL-ENVIRONMENT issue. [But that doesn't cover
the issue adequately either, since a strict interpretation on that topic
might limit it to the notion of "lexical environment".]
The problem underlying these still seems to be the discrepancy possible
between eval/load time definition and macroexpansion, and compile time
definition and macroexpansion. X3J13 had a subcommittee that was supposed
to investigate the semantics of macros. It appears to be defunct. And as
so often happens, the interest that could have been focused there has landed
on the Cleanup committee mails. Wegman once volunteered (I think) to head
up the macro committee. Mark?
-- JonL --
∂07-Mar-88 2216 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 22:16:18 PST
Received: by labrea.Stanford.EDU; Mon, 7 Mar 88 22:16:54 PST
Received: from bhopal.lucid.com by edsel id AA06092g; Mon, 7 Mar 88 22:04:35 PST
Received: by bhopal id AA05477g; Mon, 7 Mar 88 22:11:09 PST
Date: Mon, 7 Mar 88 22:11:09 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803080611.AA05477@bhopal.lucid.com>
To: Fahlman@c.cs.cmu.edu
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Mon, 7 Mar 1988 20:19 EST <FAHLMAN.12380551338.BABYL@C.CS.CMU.EDU>
Subject: Issue: EVAL-OTHER (Version 1)
re: . . . but I
do remember the original design discussions. It was proposed that
everything but lists and symbols evaluate to themselves, but at the time
(this was quite early in the process) some people felt that this might
close out interesting parts of the design space that might turn out to
be useful for something. . . .
Another way of saying this, and justifying the decision now to be made,
is that "Programs are encoded into lists and symbols; other data-types
viewed as programs shall be interpreted as constant data".
Thus the purpose of QUOTE is so that you can introduce, say, the particular
datum (CAR X) into the program described as
(DEFUN FOO (X) (LIST '(CAR X) '= (CAR X))) ;who is data, and who is program?
Lisp program syntax really hasn't changed much in 20 years. Note that
&OPTIONAL and :TEST-NOT are still symbols -- not some obscure internal
data structure invented for just this case of program syntax.
Someone may still want to nit-pick about numbers as tags in a tagbody,
but I don't think this is an important problem; it's merely a footnote
as to what a "program" is.
-- JonL --
∂08-Mar-88 0723 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 88 07:23:03 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 358321; Tue 8-Mar-88 03:08:49 EST
Date: Tue, 8 Mar 88 10:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1)
To: edsel!jonl@labrea.Stanford.EDU
cc: masinter.PA@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <8803080541.AA05406@bhopal.lucid.com>
Message-ID: <880308101753.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 7 Mar 88 21:41:38 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
... The problem underlying these still seems to be the discrepancy possible
between eval/load time definition and macroexpansion, and compile time
definition and macroexpansion. X3J13 had a subcommittee that was supposed
to investigate the semantics of macros. It appears to be defunct. ...
Well, kinda and kinda not.
The real problem is the committee overlap. When the macro committee was formed,
it was in specific answer to the Lisp1/Lisp2 issue and was to focus on macro
hygeine (a la Kohlbecker), which turns out to have nothing to do with (i.e., to
be complete orthogonal to) expansion -time-.
We on the committee studied Kohlbecker's thesis and while the ideas were
interesting, they were not clearly something we could just lift and use
directly in Common Lisp. It seemed clear that some "research" needs to
be done and none of us on the macro committee has had time to do the
necessary research. The Scheme community is still in flux on the macro
issue, and we're also waiting and watching to see what happens there...
We also decided not to feel terribly guilty about not doing the
aforementioned research because even if it were successful and we had
something to propose based on the results, it's very likely that it
would be "radical" and inappropriate for a standard at this time (though
not, for example, inappropriate for a new language or a particular
implementation). Put another way, our decision to do nothing was not
completely out of laziness. Our "informed judgement" at this point was
that while macros could use some cleanup, such cleanup might be
potentially destabilizing. It is not important to CL that every
committee form a proposal. It is only necessary that committees look
hard at the issues and determine if a proposal needs to be made.
One of the stumbling blocks we encountered in our discussions is that
there is no clear macro expansion time, but we felt that this issue was
outside of our charter. Rightly, we felt the Compiler committee was in
charge of this, but regardless of who is in charge, there's really no
practical way in the current political arena that I can see anyone giving
in on the following single very important point: to get good clear semantics
(and I use that word in the informal sense; subsitute the word "meaning" if
it makes you uncomfortable) you have to do initial pre-processing of forms
at a known time, even in the interpreter. My impression is that there is a
camp of die-hards who will not give up lazy macro expansion, and so I expect
this issue never to go anywhere.
Maybe I will write up a cleanup item on macro expansion time just to see
if my impression is imaginary. It would certainly clean up so many things if
we could get people to agree to it...
∂08-Mar-88 1126 CL-Cleanup-mailer Re: Are you coming to the cleanup meeting?
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 8 Mar 88 11:25:43 PST
Received: from relay2.cs.net by RELAY.CS.NET id ag25706; 8 Mar 88 13:12 EST
Received: from csc.ti.com by RELAY.CS.NET id an03153; 8 Mar 88 13:06 EST
Received: from home by tilde id AA10255; Tue, 8 Mar 88 10:54:08 CST
Received: by home id AA08511; Tue, 8 Mar 88 10:53:55 CST
Date: Tue, 8 Mar 88 10:53:55 CST
From: Ellen Waldrum <waldrum@home.csc.ti.com>
Message-Id: <8803081653.AA08511@home>
To: Masinter.pa@XEROX.COM, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Are you coming to the cleanup meeting?
Larry,
I currently plan to be there.
-- Ellen
∂08-Mar-88 1319 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:18:17 PST
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09784; 8 Mar 88 20:04 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 8 Mar 88 20:01:37 gmt
Message-Id: <18023.8803082001@aiva.ed.ac.uk>
To: KMP@scrc-stony-brook.arpa, jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK,
jonl <@labrea.stanford.edu:jonl@edsel.uucp>
Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1)
Cc: cl-cleanup@sail.stanford.edu, masinter.PA@xerox.com
> X3J13 had a subcommittee that was supposed to investigate the semantics
> of macros. It appears to be defunct.
As I recall, the macro committee was the subject of some confusion.
The subcommittee was originally formed to investigate issues arising
from Lisp1/Lisp2, and that aspect has been inactive, but I believe
Mark Wegman and Julian Padget did some work over the summer concerning
both the Lisp1/Lisp2 (name capture) issues and expansion environment
issues. Julian reported (briefly) on this at the last X3J13, which
surprised some people who hadn't know of this revival of activity.
-- Jeff
∂08-Mar-88 1350 CL-Cleanup-mailer Issue: LAMBDA-LIST-DUPLICATES (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:49:29 PST
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa10126; 8 Mar 88 20:36 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 8 Mar 88 20:28:54 gmt
Message-Id: <18233.8803082028@aiva.ed.ac.uk>
To: CL-Cleanup@sail.stanford.edu
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
Cc: KMP@scrc-stony-brook.arpa
Current practice:
Both PopLog Common Lisp and KCL allow variables to appear more
than once in a lambda-list. In the three suggested test cases,
they both have the later binding current in the body of the form
and so return the values 2, 1, and 1 respectively.
In addition, both allow variables in other cases, specifically:
KCL:
((lambda (a a) a) 1 2) => 2
PopLog:
((lambda (a a) a) 1 2) => 1
∂08-Mar-88 1351 CL-Cleanup-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:51:28 PST
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa10183; 8 Mar 88 20:41 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 8 Mar 88 20:22:00 gmt
Message-Id: <18213.8803082022@aiva.ed.ac.uk>
To: CL-Cleanup@sail.stanford.edu
Subject: Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
Cc: KMP@scrc-stony-brook.arpa
Current practice:
KCL and PopLog Common Lisp both return (3 (A B)) in the test case.
∂08-Mar-88 1457 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 88 14:57:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 358861; Tue 8-Mar-88 17:47:50 EST
Date: Tue, 8 Mar 88 17:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: edsel!jonl@labrea.Stanford.EDU, masinter.PA@xerox.com, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880308101753.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880308224806.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Tue, 8 Mar 88 10:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
We on the committee studied Kohlbecker's thesis and while the ideas were
interesting, they were not clearly something we could just lift and use
directly in Common Lisp. It seemed clear that some "research" needs to
be done and none of us on the macro committee has had time to do the
necessary research. The Scheme community is still in flux on the macro
issue, and we're also waiting and watching to see what happens there...
The paper by Bawden and Rees in the Lisp & Functional Programming 1988 ACM
conference should be very helpful in this respect. No, it hasn't been published
yet, the conference is in September(I think), coterminous with an X3J13 meeting.
You can probably get prepublication copies from them when they submit their
final draft to the conference. I deliberately didn't cc the authors on this
reply, as I did not want them to be deluged with any subsequent mail.
∂08-Mar-88 1712 CL-Cleanup-mailer [Now Macros, but formerly] Issue: LET-TOP-LEVEL (version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 88 17:10:11 PST
Received: by labrea.Stanford.EDU; Tue, 8 Mar 88 17:10:24 PST
Received: from bhopal.lucid.com by edsel id AA08997g; Tue, 8 Mar 88 16:28:52 PST
Received: by bhopal id AA07195g; Tue, 8 Mar 88 16:35:29 PST
Date: Tue, 8 Mar 88 16:35:29 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803090035.AA07195@bhopal.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: masinter.PA@xerox.com, cl-cleanup@sail.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Tue, 8 Mar 88 10:17 EST <880308101753.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: [Now Macros, but formerly] Issue: LET-TOP-LEVEL (version 1)
I generally agree with your comments (macros problems). It's conceivable
to me that the best we can hope to do -- while still retaining Lisp's
characteristic dynamic flexibility -- is to offer a coherent explanation
of the "meaning" of macroexpansion times, with liberal use of "it is an
error ..."
-- JonL --
∂09-Mar-88 1221 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Mar 88 12:19:19 PST
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09711; 9 Mar 88 17:53 GMT
Received: from m42 by mordell.maths.bath.AC.UK id aa10434; 9 Mar 88 17:50 GMT
To: jonl <@labrea.stanford.edu:jonl@edsel.uucp>
CC: masinter.PA@xerox.com, cl-cleanup@sail.stanford.edu
In-reply-to: Jon L White's message of Mon, 7 Mar 88 21:41:38 PST
Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1)
Date: Wed, 9 Mar 88 17:51:45 GMT
From: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
In fact, I spent some time at YKT last summer working *for* Mark on this.
I did give a short, inconclusive, report about this at Fort Collins and you
may have seen a very drafty note about it that I sent to the eulisp list -
I did hear that it did get a wider physical distribution after the electronic
one (which was a source of some embarassment to me).
I have just got down to doing some further work on macros (whilst I
was away during the last week) and had reached precisely the points
that people are now discussing on CL-cleanup, which is all useful
input for me. I doubt I will have anything finished for next week (it
is presently unclear whether I will be at X3J13 either, because of
airline reservation problems). I also doubt that the conclusions will
be popular, since the one obvious remark is that Lisp macros are a
terrible mess, are further compounded in Common Lisp and that "if I
were you, I wouldn't start from here"! It is precisely because of the
environment issue and the way that it has been attempted to finesse
multiple environments in CL that we have been treated to examples of
such subtlety on this mailing list of late.
Of course, it is easy to criticise rather than making a proposal and
laying oneself open to criticism...there might be something in a few
weeks, I hope.
--Julian.
∂09-Mar-88 1248 CL-Cleanup-mailer Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 9 Mar 88 12:47:31 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA07987; Wed, 9 Mar 88 15:49:33 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA09416; Wed, 9 Mar 88 15:49:03 EST
Message-Id: <8803092049.AA09416@mist.UUCP>
To: "David A. Moon" <Moon%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: cl-cleanup%SAIL.STANFORD.EDU@multimax
Subject: Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
In-Reply-To: Your message of Sun, 06 Mar 88 15:41:00 -0500.
Date: Wed, 09 Mar 88 15:49:01 EST
From: Dan L. Pierson <pierson@mist>
Date: Sun, 6 Mar 88 15:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I don't think so. For example, the proposal only mentions LET. This is
obviously incomplete. It should at least mention LET*. But what about
the LAMBDA combination that is almost equivalent to LET? What about
other binding forms such as DO? What about other bindings besides
variables, such as MACROLET, FLET, and BLOCK? I think the proposal
needs much more careful attention to how narrow or broad its scope is
supposed to be. Understand that I do not object to the change proposed
by this proposal. I think that that change is going to be part of the
real proposal; I just don't think it makes sense to do that one change
by itself.
I certainly agree with at least the first part of this; I should have
covered at least LET* in the original proposal. While the next
edition should include all of the areas mentioned above, I think that
the it may be best to explicitly not support some of them if the
current vague definition of "top level" stands.
More generally, I think this proposal is patching Common Lisp's
ill-defined notion of "top level" instead of fixing it. While there
are some practical benefits to the patch, as it makes a small increase
in the number of programs that are portable, I don't think it really
solves the problem. In practical terms, I can't see asking my compiler
people to spend time implementing this when it's obvious that this is
an interim change and something better is, or should be, on its way.
I'd rather they spend their energies elsewhere until Common Lisp has
really got its act together on this "top level form" business, and then
they can implement what is really the right thing.
There seems to be a lot of general agreement on this. Is it a cleanup
or compiler issue (or *the* compiler issue)?
If this proposal were presented in its current form, I would oppose it.
No amount of wording changes would change my position. I want to see
a broader proposal.
Does this mean that you would oppose anything that didn't include a
fixed definition of "top level"? If so, do you think that such a fix
is a required part of the standard we're working on or that
standardizing the status quo is preferable to any halfway measures?
∂09-Mar-88 1710 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 17:10:41 PST
Received: by labrea.Stanford.EDU; Wed, 9 Mar 88 17:11:24 PST
Received: from bhopal.lucid.com by edsel id AA14086g; Wed, 9 Mar 88 16:14:10 PST
Received: by bhopal id AA09209g; Wed, 9 Mar 88 16:20:49 PST
Date: Wed, 9 Mar 88 16:20:49 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803100020.AA09209@bhopal.lucid.com>
To: PADGET@rand-unix.rand.org
Cc: cl-cleanup@sail.Stanford.EDU
In-Reply-To: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK's message of Wed, 9 Mar 88 17:51:45 GMT <8803091808.AA12684@edsel.lucid.com>
Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1)
My apologies for not remembering earlier your presentation at Fort Collins.
[I may have even made some comment about the desirablity of documenting
the notion of "lexical shielding" in some macro expansions -- such as for
DEFSUBST -- while still permitting "lexical capturing" in more general
cases. Also, last month, I privately sent you some macro examples wherein
"lexical capturing" was put to productive use.]
Yes indeed, I'd feel quite uncomfortable if the future of macros in the
Lisp world were to be relegated to some kind of "pre-processor" status.
Shades of C-level programing! But as I mentioned to Kent the other day,
there has just got to be some theory of definition and use that makes
it easy to understand what's reasonable and doable, and helps the naive
user avoid troublesome situations.
-- JonL --
∂09-Mar-88 1711 CL-Cleanup-mailer PROCLAIM [and "lexical scoping"?]
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 17:11:37 PST
Received: by labrea.Stanford.EDU; Wed, 9 Mar 88 17:12:21 PST
Received: from bhopal.lucid.com by edsel id AA14195g; Wed, 9 Mar 88 16:42:42 PST
Received: by bhopal id AA09327g; Wed, 9 Mar 88 16:49:12 PST
Date: Wed, 9 Mar 88 16:49:12 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803100049.AA09327@bhopal.lucid.com>
To: vanroggen@hudson.dec.com
Cc: cl-compiler@sail.Stanford.EDU, cl-cleanup@sail.Stanford.EDU
In-Reply-To: "AITG::VANROGGEN"'s message of 9 Mar 88 15:01:00 EDT <8803092111.AA13223@edsel.lucid.com>
Subject: PROCLAIM [and "lexical scoping"?]
I tend to agree with your feelings about non-DEFUN forms in a file -- that
it's undesirable to have them all implicitly eval-when(eval compile).
At worst, one might want to include PROCLAIM in with the 7-extremely-randoms
-- perhaps as the eighth wonder of the randomness world.
On the other hand, I see lots of need for a lexical file proclaim. This
would be a good time to define something that has DECLARE syntax (i.e.,
isn't a function that "evaluates its arguments") but which also has
PROCLAIM pervasiveness within a file. The reason I call it "lexical file
proclaim" is that I want it to affect only the lexically-apparent code in
the file in which it is found at top level (for whatever it means to be "at
top level"). So unlike current PROCLAIM, it would not affect the evaluation
of random Lisp forms during, say, macro expansion, or during a sub-recursive
call to COMPILE-FILE, etc. On the other hand, unlike current semantics for
(LOCALLY (DECLARE (SPECIAL ...)) ...), it's effect would be "pervasive".
Would information from "lexical, file-proclaim" affect the code produced
by macroexpansions? after all, such code isn't "lexically apparent" in
the file? This issue is no different than the current controversy about
whether macro-expansion produced code should be "captured" by the
lexical environment surrounding it, or whether it should be insulated
from it. Thus this controversy should be left to the macro committee,
or whatever other body addresses it; it's independent of compile-file
semantics.
What is a file such that "lexical file-proclaim" makes sense. Again,
I think the answer is to defer to COMPILE-FILE; whatever it thinks a
"file" is, then that is what the scope of "lexical file-proclaim" is.
-- JonL --
∂11-Mar-88 1031 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 88 10:31:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 361116; 11 Mar 88 13:31:02 EST
Date: Fri, 11 Mar 88 13:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EVAL-OTHER (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880307212550.8.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<19880307234416.7.MLY@Bullwinkle.Palladian.COM>,
<8712181940.AA22225@tekchips.TEK.COM>
Message-ID: <19880311183058.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here's the message I was thinking of (thanks, Richard). By the way,
I don't buy Will's argument...I don't think making evaluating a
function or a closure an error will detect a very large fraction
of the errors typically made with backquote. I know it would detect
almost none of the errors I make, which are usually to evaluate
something at the wrong time rather than to evaluate something that
should not have been evaluated at any time. Just some input.
Date: Mon, 7 Mar 88 18:44 EST
From: Richard Mlynarik <Mly@JASPER.Palladian.COM>
Date: Mon, 7 Mar 88 16:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I remember this issue being discussed only a few months ago on either
Common-Lisp or CL-Cleanup. I think somebody had some reasons to oppose
this proposal, but I don't remember finding them convincing. Sorry I
don't remember any of the details, I mention it because perhaps this
will stimulate someone else's memory.
To: Fahlman@C.CS.CMU.EDU
Cc: Moon@SCRC-STONY-BROOK.ARPA, CL-CLEANUP@SAIL.STANFORD.EDU,
willc%tekchips.tek.com@RELAY.CS.NET
Subject: whether random objects self-evaluate (was cleaup issues from Japan)
In-Reply-To: Your message of Thu, 17 Dec 1987 21:12 EST.
<FAHLMAN.12359327290.BABYL@C.CS.CMU.EDU>
Date: 18 Dec 87 11:40:02 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
Let me report on the Scheme situation and my experience. As in Common Lisp,
it is "an error" to evaluate a random object, but most implementations
extend the language by allowing at least some random objects (notably
the empty list, since only a few implementations yet distinguish the empty
list from #f) to evaluate to themselves. MacScheme allows all random objects
to evaluate to themselves, but unlike Symbolics I have found this to be
a (minor) problem, and I recommend that implementors avoid my mistake.
The problem: In writing a macro using backquote I sometimes leave out a
quote mark, insert an extra comma, or put a comma in the wrong place.
Then an expanded macro can look like
(... #<PROCEDURE> ...)
when I wanted it to look like
(... '#<PROCEDURE foo> ...)
or
(... (lambda (...) ...) ...).
I would like to get an error message from the incremental compiler, because
I never deliberately write code with unquoted procedures, but with
self-evaluating procedures no error will occur until the expression is
executed, and then the values seen in the debugger can seem very strange.
In my code, this kind of macro bug almost always shows up as a procedure
that was closed in the wrong environment, but if I'm unlucky the incorrect
procedure will pass control to an altogether unfamiliar part of the system
before trapping on some unrelated error such as taking the car of the empty
list.
As better macro facilities become more universal, this is of course
becoming less of a problem.
Peace, Will
∂11-Mar-88 1039 CL-Cleanup-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 88 10:39:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361128; Fri 11-Mar-88 13:39:35 EST
Date: Fri, 11 Mar 88 13:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880307162443.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880311183925.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor the general idea of MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE,
but I have two comments:
Do we want to follow the lead of MAPHASH in explicitly defining that
destructive operations are permissible on the entry currently being
processed? For example, is
(let ((l (list 0 1 2 3 4)))
(dolist (x l)
(when (oddp x)
(setq l (delete x l))))
l)
a valid program that returns (0 2 4)? Note that making this valid
seems to imply a restriction on the implementation of DOLIST, that
it must call CDR before evaluating the body, not after. Personally
I don't care whether this practice is allowed or forbidden. Being
consistent with MAPHASH might lead to a clearer language.
The proposal needs to be expanded to include a complete list of
the functions affected. It also needs a clearer definition of
which destructive operations it covers. For example, I imagine your
intention was to forbid SETF of CDR but to allow SETF of CAR, inside
of DOLIST. However, you didn't say that explicitly. What about
destructive operations on vectors?
∂11-Mar-88 1043 CL-Cleanup-mailer Issue: LAMBDA-LIST-DUPLICATES (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 88 10:42:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361130; Fri 11-Mar-88 13:43:10 EST
Date: Fri, 11 Mar 88 13:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880307150614.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880311184311.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE; I think
Common Lisp should continue to forbid binding the same variable more
than once in the same binding form. I have two reasons:
1. This is an unnecessary complication of the language rules. Allowing
duplicated variable names doesn't make it possible to write programs
that you couldn't write before, it just allows the programs to be
written in a more obscure way.
2. This would result in an unnecessary complication of the scoping rules
for DECLARE. Common Lisp would have to define what happens when a
DECLARE of a variable is attached to a form that binds more than one
variable with the declared name.
∂11-Mar-88 1045 CL-Cleanup-mailer Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 88 10:45:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 237092; Fri 11-Mar-88 13:21:12 EST
Date: Fri, 11 Mar 88 13:21 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8803092049.AA09416@mist.UUCP>
Message-ID: <19880311182108.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 09 Mar 88 15:49:01 EST
From: Dan L. Pierson <pierson@mist>
Date: Sun, 6 Mar 88 15:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
If this proposal were presented in its current form, I would oppose it.
No amount of wording changes would change my position. I want to see
a broader proposal.
Does this mean that you would oppose anything that didn't include a
fixed definition of "top level"?
I'm not sure. It may be that a broader proposal that was more explicit about
its scope could still avoid precisely defining "top level", however it does
not seem likely. I suppose that means the answer is a conditional yes.
If so, do you think that such a fix
is a required part of the standard we're working on or that
standardizing the status quo is preferable to any halfway measures?
I don't see how we could standardize the status quo, since nobody seems to
be able to figure out what the status quo is. I'm not sure what "required"
means in practice. I suspect a successful standard could continue to
duck the issue of the meaning of "top level"; after all, ducking that
issue hasn't killed the de facto Common Lisp standard. Obviously, though,
it would be better to tackle the issue. I would have hoped that the
compiler committee would have solved this issue six months ago, but
unfortunately that committee doesn't seem to do much.
∂12-Mar-88 1527 CL-Cleanup-mailer New issue: STEP-ENVIRONMENT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 88 15:27:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361805; Sat 12-Mar-88 18:27:05 EST
Date: Sat, 12 Mar 88 18:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New issue: STEP-ENVIRONMENT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19880312232651.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: STEP-ENVIRONMENT
References: STEP (CLtL p.441)
TIME (CLtL p.441)
Category: CLARIFICATION
Edit history: Version 1, 12-Mar-88, Moon
Problem description:
CLtL does not specify in what lexical environment the form given to STEP
is evaluated. Some people think it's supposed to be evaluated in the
null environment, others think it is supposed to be evaluated in the
current environment, the one in which the STEP form was evaluated.
The same considerations apply to TIME.
An additional problem is that CLtL says that STEP is a macro. However,
it is unclear what portable expression the macro could expand into,
especially if STEP evaluates the form in the current environment. STEP
is really a variation of the Lisp interpreter, which makes it more like
a special form than like a macro.
The interaction of STEP with the compiler is not specified.
Proposal (STEP-ENVIRONMENT:CURRENT):
1. Clarify that STEP and TIME evaluate the form in the current environment.
2. Change STEP from a macro to a special form.
3. Clarify that it is an error to compile a STEP form.
Test Cases/Examples:
;Assuming X is not a special variable
(setq x 1)
(let ((x 2))
(step (print x)))
This should print and return 2, not 1, when interpreted.
Rationale:
1. It is more useful for the lexical environment to pass transparently
through STEP and TIME than to reset to the null environment.
2. STEP is really a variation of the Lisp interpreter, which makes it more
like a special form than like a macro.
3. As a debugging TOOL, STEP forms do not need to be compiled. It would
be difficult to specify precisely what should happen when a STEP form is
compiled (which parts of the form are to be executed interpretively), so
it's easier to duck the issue. Use "is an error" rather than "signals
an error" so that compile-only implementations are permitted to compile
STEP forms.
Current practice:
Symbolics Common Lisp behaves as proposed.
Cost to Implementors:
1 requires passing an environment around, which should be easy.
2 and 3 are just restrictions, so they should cost nothing.
Cost to Users:
None.
Cost of non-adoption:
These debugging tools will continue to have vague specifications.
Benefits:
Slightly more preicse specification of Common Lisp.
Esthetics:
Slightly improved.
Discussion:
None yet.
∂12-Mar-88 1600 CL-Cleanup-mailer New issue: DEFPACKAGE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 88 15:59:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361817; Sat 12-Mar-88 19:00:11 EST
Date: Sat, 12 Mar 88 19:00 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New issue: DEFPACKAGE
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19880313000007.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: DEFPACKAGE
References: CLtL section 11.7.
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Problem description:
The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system. The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished. Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended. These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and give Common Lisp a bad name.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. It encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. In addition, it allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Also expand MAKE-PACKAGE and IN-PACKAGE to take all the same keyword
arguments as DEFPACKAGE, for consistency.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is either a keyword or a list of a keyword and
arguments. A keyword standing by itself is an abbreviation for
a list (keyword T). Nothing in a DEFPACKAGE form is evaluated.
package-name is a symbol or a string; if a symbol, only its name
matters.
Standard options for DEFPACKAGE are as follows; additional options might
be present in an implementation, and each implementation must signal an
error if an option not recognized by that implementation is present.
Each option may appear at most once.
(:EXPORT {symbol/string}*)
Create symbols with the specified names and export them.
(:IMPORT {symbol}*)
Import the specified symbols.
(:IMPORT-FROM {(package-name {symbol/string}*)}*)
(:IMPORT-FROM package-name {symbol/string}*)
Find the specified symbols in the specified packages and import
them into the package being defined. The second syntax is a
convenient abbreviation when only one package is specified.
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified strings.
(:SHADOW {symbol/string}*)
Create the specified symbols in the package and place them
on the shadowing list.
(:SHADOWING-IMPORT {symbol}*)
Import the specified symbols into the package and make them
shadow any inherited symbols.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
(:USE {package}*)
Inherit from the specified packages.
Example:
(DEFPACKAGE MY-PACKAGE
(:USE LISP)
(:SHADOW CAR CDR CONS)
(:NICKNAMES MP MYPKG)
(:PREFIX-NAME MYPKG))
Rationale:
See first paragraph of Proposal section.
Current practice:
Symbolics Common Lisp has always had this, and uses it in preference
to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL version
of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time.
Cost to Implementors:
Should be small as the macro can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
The "Put in seven extremely random user interface commands" business
described at the end of chapter 11 could be removed, and the special
compiler handling of these functions necessary to support that could be
removed. As this would be an incompatible change, it is not part of
this proposal.
∂12-Mar-88 1614 CL-Cleanup-mailer New issue: DEFPACKAGE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 88 16:14:22 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361822; Sat 12-Mar-88 19:14:43 EST
Date: Sat, 12 Mar 88 19:14 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New issue: DEFPACKAGE
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
References: <19880313000007.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880312191420.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I support the general idea of this proposal, but have a few nits to pick...
* I think IN-PACKAGE is broken for being able to demand-create a package.
It serves two unrelated roles, one of which being selection and the other
being creation. Extending it to allow more keywords will worsen the problem.
Given DEFPACKAGE, I would rather see IN-PACKAGE incompatibly changed to NOT
allow demand creation. This would fix a lot of bugs.
* There might should be a :SHADOWING-IMPORT-FROM.
* I think that all options listed as symbol/string should be string-only.
People should be discouraged from naming symbols before the package structure
is fully in place. I'll stop short of suggesting that :IMPORT-FROM and
:SHADOWING-IMPORT-FROM completely replace :IMPORT and :SHADOWING-IMPORT,
which still muck with symbols.
* I'm surprised you left out the Genera :INCLUDE feature, but I guess that
could always be added later if it was seen to be desired so it's ok.
* :PREFIX-NAME is mentioned only in the same. To have it in an integrated fashion,
you'd need a PACKAGE-PREFIX-NAME function and some discussion of that it was
automatically a nickname if not explicitly in the list of names or nicknames.
I'm in a hurry so didn't write much on each of these. I can elaborate on any that
are found to be not clear.
∂12-Mar-88 1646 CL-Cleanup-mailer New issue: DEFPACKAGE
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 12 Mar 88 16:46:24 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Sat 12 Mar 88 19:47:02-EST
Date: Sat, 12 Mar 1988 19:46 EST
Message-ID: <FAHLMAN.12381856106.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: New issue: DEFPACKAGE
In-reply-to: Msg of 12 Mar 1988 19:00-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
In response to David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
This looks good, as far as it goes, and the fact that it has actually
been tested in practice is a big plus -- it tends to give one confidence
that nothign critical has been overlooked.
I'm a bit uneasy about the syntax that you propose for the options. It
would be more compatible with the rest of Common Lisp to use alternating
keywords and arguments. Some users may find the odd syntax of your
DEFPACKAGE to be confusing. Is there some real advantage to the syntax
you propose, or is this just a bit of Zetalisp culture peeking through?
-- Scott
∂12-Mar-88 1702 CL-Cleanup-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 88 17:02:51 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361839; Sat 12-Mar-88 20:03:09 EST
Date: Sat, 12 Mar 88 20:02 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880214-134110-1441@Xerox>
Message-ID: <880312200240.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[X3J13 removed.]
I support many ideas of this proposal, but I have two gripes which make me
have to oppose it:
* I can't deal with the idea of generalizing SYMBOL-FUNCTION. I would like
to see FDEFINITION introduced and SYMBOL-FUNCTION left alone.
* I'm also a little leary about TRACE being extended this way because
(TRACE (a list)) might later want to be interpreted as options rather
than as a function spec and I'd rather not have to risk heuristic resolution.
I would rather someone right now introduce a generalized syntax for TRACE
with syntactic space for trace options, such as
(TRACE (fn . options) (fn . options) (fn . options))
and then allow the generalized (non-symbol) fn to only occur within that
syntax so that no ambiguity results.
∂12-Mar-88 1808 CL-Cleanup-mailer Issue: LAST-N (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 88 18:07:58 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361856; Sat 12-Mar-88 21:08:14 EST
Date: Sat, 12 Mar 88 21:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAST-N (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <871204164910.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <880312210753.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: LAST-N
References: LAST (p267)
Category: ENHANCEMENT
Edit history: 04-Dec-87, Version 1 by Pitman,
12-Mar-88, Version 2 by Pitman
Status: For Internal Discussion
Problem Description:
People always ask why LAST returns a cons and not an element.
BUTLAST takes an argument N but LAST does not.
Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT):
Allow LAST to take an optional argument N, saying how many cells to return.
The default for N would be 1.
It is an error if N is negative or L is circular.
If N is zero, then the atom that terminates the list L is returned.
If N is greater than or equal to the number of cons cells in the list
L, then the result is L.
Test Cases:
(LAST '(A B C) 0) => ()
(BUTLAST '(A B C) 0) => (A B C)
(LAST '(A B C) 1) => (C)
(BUTLAST '(A B C) 1) => (A B)
(LAST '(A B C) 2) => (B C)
(BUTLAST '(A B C) 2) => (A)
(LAST '(A B C) 3) => (A B C)
(BUTLAST '(A B C) 3) => ()
(LAST '(A B C) 4) => (A B C)
(BUTLAST '(A B C) 4) => ()
(LAST '(A B C)) => (C)
(BUTLAST '(A B C)) => (A B)
(LAST '(A . B) 0) => B
(LAST '(A . B) 1) => (A . B)
(LAST '(A . B) 2) => (A . B)
Rationale:
BUTLAST and LAST would select complementary parts of a list in general.
That is (EQUAL L (APPEND (BUTLAST L N) (LAST L N))) would be T for N >= 0
and L being a proper list.
This would make it more obvious why LAST should return a list and not
an element. ie, it would return the "last N elements" where N=1 by default.
Current Practice:
Probably nobody does this.
Adoption Cost:
Very slight. The following code would suffice:
(DEFUN LAST (LIST &OPTIONAL (N 1))
(CHECK-TYPE N (INTEGER 0))
(DO ((L LIST (CDR L))
(R LIST)
(I 0 (+ I 1)))
((ATOM L) R)
(IF (>= I N) (POP R))))
Some implementations might want to provide compiler optimizations for
the N=1 case.
Benefits:
This utility is probably needed often enough to warrant its inclusion.
It's present (as a separate function called NLEFT) in Symbolics Common
Lisp and Interlisp.
Conversion Cost:
None. This is an upward compatible extension.
Aesthetics:
This would make things a little prettier.
Discussion:
This suggestion came up recently on a Symbolics design discussion list.
Symbolics is contemplating offering it as an extension, but it seemed like
the rest of the CL community might want to adopt it, too. Pitman thinks
it's a nice idea.
Masinter opposes this extension as gratuitous.
Moon and Daniels think this is very low priority but have expressed a
lack of major objection to this proposal.
∂13-Mar-88 1637 CL-Cleanup-mailer Re: New issue: DEFPACKAGE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Mar 88 16:37:12 PST
Received: from Salvador.ms by ArpaGateway.ms ; 13 MAR 88 16:31:47 PST
Date: Sun, 13 Mar 88 16:31:26 PST
From: Pavel.pa@Xerox.COM
Subject: Re: New issue: DEFPACKAGE
In-reply-to: <19880313000007.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880313-163147-1810@Xerox>
Just a nit for the moment:
``A keyword standing by itself is an abbreviation for a list (keyword T).''
This doesn't appear to be very useful, since none of the options will commonly
want to have an option-argument of T.
Pavel
∂14-Mar-88 0007 CL-Cleanup-mailer Re: the array type mess....
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 88 00:07:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 88 00:08:03 PST
Date: 14 Mar 88 00:07 PST
From: Masinter.pa@Xerox.COM
Subject: Re: the array type mess....
In-reply-to: various
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880314-000803-1132@Xerox>
This issue is now called "ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS", i.e., the
semantics of element types in ARRAY type descriptors.
It is listed as "needs volunteer".
I think we understand the problem sufficiently to attempt a writeup, and we've
heard several different proposals, discarded some but not all.
∂14-Mar-88 0013 CL-Cleanup-mailer Current issue status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 88 00:12:49 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 88 00:13:30 PST
Date: 14 Mar 88 00:13 PST
From: Masinter.pa@Xerox.COM
Subject: Current issue status
to: CL-CLEANUP@Sail.Stanford.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <880314-001330-1136@Xerox>
This is my updated list of issue status.
!
This is the list of issues distributed for the March 1988 X3J13 meeting:
- ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87)
(Interaction of ADJUST-ARRAY and displaced arrays)
- APPEND-DOTTED (Version 5, 14-Jan-88)
(What happens to CDR of last CONS? in other
than last arg?)
- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed X3J13/Jun87
Version 7 passed X3j13/Nov87
- ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87)
(Extend ASSOC-IF, etc. to allow :KEY)
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Version 1 passed X3J13/Nov87
- COMPILER-WARNING-BREAK (Version 4,23-Nov-87 )
(Does *BREAK-ON-WARNING* affect the compiler?)
<<<Too vague, current opposition.>>>
- DECLARE-MACROS (Version 3, 5-FEB-88)
(Disallow macros expanding into declarations.)
- DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87)
(Documentation string is not evaluated.)
- DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88)
(DISASSEMBLE doesn't smash the def if not compiled)
<<<VAXLisp Current Practice wrong.>>>
- DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87)
( DO-SYMBOLS can the same symbol twice?)
<<<The rationale contains a typo: DO-PACKAGE for DO-SYMBOLS>>>
- DRIBBLE-TECHNIQUE (Version 2, 14-Feb-88)
(dribble can't be used programmatically)
<<<VAXLisp Current Practice wrong.>>>
- FLET-DECLARATION (Version 2, 2 Feb 88)
(Allow declarations in FLET, MACROLET)
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Version 2 passed X3J13/Nov87
<<<example is bogus; that example was one of the better uses
for the facility, too>>>
- FORMAT-COLON-UPARROW-SCOPE (Version 3, 5 Feb 88)
(what iteration does ~:↑ exit from?)
- FUNCTION-TYPE-KEY-NAME (Version 3, 5 Feb 88)
(allow &KEY (:KEYNAME type)) in FUNCTION decls )
- FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88)
(allow &rest <type> in function types to refer to element
type)
<<<Discussion, objections, etc.>>>
- FUNCTION-TYPE (Version 9, 13-Feb-88)
(Change definition of FUNCTIONP, function type ...)
<<<STRICT-REDEFINITION has typo, 1a 6 PROCEDURE => FUNCTION.
COMPILED-FUNCTION optional subtype "compiled" implementation-dependent.>>>
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 passed X3J13/Nov87.
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Version 8 passed X3J13/Nov87
- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Version 6 passed X3J13/Nov 87
- PATHNAME-SYMBOL (Version 5, 5-Feb-88)
(Do symbols automaticly coerce to pathnames?)
- PUSH-EVALUATION-ORDER (Version 5,25-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
- REDUCE-ARGUMENT-EXTRACTION (version 3, 13-Feb-88)
(Add :KEY to REDUCE)
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
<<<Don't like SYMBOL-FUNCTION, TRACE extension.>>>
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5, 5-Feb-88)
(let FIND, SUBSTITUTE etc work on multi-dimensional arrays)
<<<VanRoggen opposes as stands.>>>
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
(What does SHADOW do if symbol is already there?)
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
(*FEATURES* are in the keyword package)
!
The following issues were mailed prior to the June 1987 meeting and passed at
that meeting; they will not be distributed again except by request.
- COMPILER-WARNING-STREAM (Version 6, 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87
- DEFVAR-INIT-TIME (Version 2, 29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
- DEFVAR-INITIALIZATION (Version 4, Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 pased X3J13, Jun87.
- FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
- FORMAT-ATSIGN-COLON (Version 4, 5-jun-87)
(@: == :@ in format)
Version 4 passed X3J13/Jun87.
- FORMAT-OP-C (Version 5, 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
- IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
- PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
!
For your information only, the following issues are still under consideration by
the cleanup committee. Volunteers to help out with the preparation of issue
writeups are welcome. If you would like to review the mail discussion on a given
topic, please let me know and I will forward it to you.
- ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
(What does (ARRAY FROB) mean?)
In discussion, needs volunteer
- ADJUST-ARRAY-FILL-POINTER
(Interaction of Adjust-ARRAY and fill pointers.)
Need volunteer to write up.
- COERCE-INCOMPLETE (Version 1, 28-Feb-88)
(Extend COERCE to handle default coercions.)
- CONSTANT-SIDE-EFFECTS (not yet submitted)
(It is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Will take on if no compiler proposal
- DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
- DECLARATION-SCOPE (Version 2, 2-Feb-88)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
Ready for release?
- DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS)
(Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e.,
not a subclass.)
Useful after CLOS
- DEFINITION-FUNCTIONS (not yet submitted)
JonL will submit, really "definition-delete" or some such
- DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
Interacts with compiler proposal?
- DEFPACKAGE (Version 1)
(Add DEFPACKAGE form.)
- DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- EQUAL-STRUCTURE (not yet submitted)
(Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.)
What do EQUAL EQUALP and friends do
on structures?
(Need volunteer.
ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu,
Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU?)
- EVAL-OTHER (Version 1, 07-Mar-88)
(Allow other data types to self-evaluate.)
- EXPORT-IMPORT (Version 2, ?)
??? Status, opinions?
- FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just
an open file-stream. Let it take a keyword argument :ELEMENT-TYPE,
defaulting to STRING-CHAR for non-stream arguments and to the
element-type of the stream for a stream argument."
Need volunteer to write up.
- FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Need volunteer.
- FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Need volunteer.
- FUNCTION-ARGUMENT-TYPE-SEMANTICS (not yet submitted)
(Change semantics of argument types in function declarations.)
- FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace etc)
beyond SETF-FUNCTION-VS-MACRO.
(SMH!franz@ucbarpa.berkeley.edu, JonL, RWK)
- GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
- LAMBDA-LIST-DUPLICATES (Version 1, 07-Mar-88)
(allow sequential non-iterative.)
Moon opposes
- LAST-N (version 2, 12-Mar-88)
(Extend LAST to take an optional N)
Ready for release?
- LET-TOP-LEVEL (version 1)
(clarification, not change?)
- LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
Merge with SPECIAL-FORM-SHADOW
Needs volunteer
- LOAD-TIME-EVAL (Versin 4, 2 Feb 88)
(evaluation when compiled file is loaded)
- MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
re-extracted from ENVIRONMENT-ARGUMENTS
CLOS committee to submit?
- MAPPING-DESTRUCTIVE-INTERACTION (Version 1, 08-Mar-88)
([don't] define interaction of DELETE on MAPCAR'd list.)
(? extended, needs list of fns & operations covered.)
- PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
make :DIRECTORY a list?
Need volunteer to rewrite.
- PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components, etc
in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
- PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal
interaction must or even ought to work."
- PROCLAIM-LEXICAL (Version 5, 14-Nov-87)
(add LEXICAL, GLOBAL, CONSTANT proclaimation)
some serious problems
- PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
- REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 )
(Specification of side-effect behavior in CL)
DEFINED, VAGUE and IN-BETWEEN
- REMF-MULTIPLE (Version 1, 26 Jan 88)
(What does REMF do if it sees more than one INDICATOR?)
- REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
- REST-LIST-ALLOCATION (not yet submitted)
(APPLY #'LIST X) == (COPY-LIST X)?
need volunteer
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
- SETF-SUB-METHODS (version 1, 12-Feb-88)
(more careful definition of order of evaluation
inside (SETF (GETF ...) ...) )
- SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
- SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
- SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
- SPECIAL-VARIABLE-TEST (Version 1, 7-Mar-88)
(Add SPECIALP)
- STANDARD-INPUT-INITIAL-BINDING (Version 2, 29 Feb 88)
(Change CLtL's wording about requirements
for *ERROR-OUTPUT*, etc.)
Moon comments appropriate.
- STEP-PACKAGE (Version 1)
(STEP isn't a macro, its a special form.)
- STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc
were CLOS classes?
Allow stream to be specializable class? (MMcM mail.)
Need volunteer
- STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Need volunteer to write up
- SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end
of the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array
out-of-bounds.)"
Need volunteer to write up
- TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
- TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
- UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87)
(What happens with non-local exits out of UNWIND-PROTECT
cleanup clauses?)
- VECTOR-PUSH-EXTEND-DEFAULT (no proposal yet)
CLtL says that vectors are extended by a "reasonable" amount. What's that?
∂14-Mar-88 0110 CL-Cleanup-mailer New issue: STEP-ENVIRONMENT
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 01:09:55 PST
Received: by labrea.Stanford.EDU; Mon, 14 Mar 88 01:10:35 PST
Received: from kent-state.lucid.com by edsel id AA11298g; Mon, 14 Mar 88 00:57:17 PST
Received: by kent-state id AA00535g; Mon, 14 Mar 88 01:06:06 PST
Date: Mon, 14 Mar 88 01:06:06 PST
From: Eric Benson <edsel!eb@labrea.Stanford.EDU>
Message-Id: <8803140906.AA00535@kent-state.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 12 Mar 88 18:26 EST <19880312232651.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: New issue: STEP-ENVIRONMENT
For Current Practice or an Implementation Note, this is the definition
of TIME in Lucid Common Lisp:
(defmacro time (form)
`(time-internal #'(lambda () ,form)))
The function TIME-INTERNAL looks something like:
(defun time-internal (thunk)
(let ((before-time (get-time-state)))
(unwind-protect
(funcall thunk)
(print-time-information before-time (get-time-state)))))
The definition of STEP is similar. This is just to show that it is
easy to get the right lexical environment even though TIME and STEP
are macros.
∂14-Mar-88 0115 CL-Cleanup-mailer New issue: DEFPACKAGE
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 01:14:20 PST
Received: by labrea.Stanford.EDU; Mon, 14 Mar 88 01:15:04 PST
Received: from kent-state.lucid.com by edsel id AA11326g; Mon, 14 Mar 88 01:02:08 PST
Received: by kent-state id AA00538g; Mon, 14 Mar 88 01:10:57 PST
Date: Mon, 14 Mar 88 01:10:57 PST
From: Eric Benson <edsel!eb@labrea.Stanford.EDU>
Message-Id: <8803140910.AA00538@kent-state.lucid.com>
To: Fahlman@c.cs.cmu.edu
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Sat, 12 Mar 1988 19:46 EST <FAHLMAN.12381856106.BABYL@C.CS.CMU.EDU>
Subject: New issue: DEFPACKAGE
Date: Sat, 12 Mar 1988 19:46 EST
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In response to David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
This looks good, as far as it goes, and the fact that it has actually
been tested in practice is a big plus -- it tends to give one confidence
that nothign critical has been overlooked.
I'm a bit uneasy about the syntax that you propose for the options. It
would be more compatible with the rest of Common Lisp to use alternating
keywords and arguments. Some users may find the odd syntax of your
DEFPACKAGE to be confusing. Is there some real advantage to the syntax
you propose, or is this just a bit of Zetalisp culture peeking through?
-- Scott
This syntax resembles that used for DEFSTRUCT options, so it does have
a precedent in CLtL.
∂14-Mar-88 0559 CL-Cleanup-mailer New issue: DEFPACKAGE
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 05:59:06 PST
Received: from KLYTEMNESTRA.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 98596; Mon 14-Mar-88 08:59:27 EST
Date: Mon, 14 Mar 88 08:59 EST
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: New issue: DEFPACKAGE
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12381856106.BABYL@C.CS.CMU.EDU>
Message-ID: <880314085910.1.MLY@KLYTEMNESTRA.AI.MIT.EDU>
Date: Sat, 12 Mar 1988 19:46 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I'm a bit uneasy about the syntax that you propose for the options. It
would be more compatible with the rest of Common Lisp to use alternating
keywords and arguments. Some users may find the odd syntax of your
DEFPACKAGE to be confusing. Is there some real advantage to the syntax
you propose, or is this just a bit of Zetalisp culture peeking through?
DEFSTRUCT (which nobody has ever accused of having non-`odd' syntax) also suffers
from the same non-&KEY-style.
The saddest things is that this type of syntactical lossage has infected
CLOS DEFxxx, probably because of the precedent in DEFFLAVOR. I personally
dislike the whole style; unfortunately it seems that few others feel strongly
enough about this issue to raise objections.
[As an aside, I generally prefer not to use macros whose syntax I can't
describe with destructuring lambda-list technology. Unfortunately,
LET doesn't fit into this class, which I hope says something about
missing &rest-destructuring functionality rather than about my own
inconsistency.]
When I implemented DEFPACKAGE some time ago I preferred and advertised
&KEY-style, but also allowed "(:keyword option)"-style for compatibility.
∂14-Mar-88 0637 CL-Cleanup-mailer DEFPACKAGE syntax
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 06:37:36 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Mon 14 Mar 88 09:38:01-EST
Date: Mon, 14 Mar 1988 09:37 EST
Message-ID: <FAHLMAN.12382269523.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: DEFPACKAGE syntax
Yes, DEFSTRUCT has a syntax similar to what is proposed for DEFPACKAGE.
In that case, people can see that DEFSTRUCT is so complex that the
simple alternating keyword/value style wouldn't cut it. In DEFSTRUCT,
the structure has its set of keyword values and each slot does as well.
I see no such complexity in DEFPACKAGE, so the question is whether there
is any reason we have to go to a less-familiar syntax in this case.
I'm not going to fight to the death over this. I just thought it was
needlessly confusing and thought I'd raise the issue while there was
still time. On the other side of the balance is the convenience to part
of the Common Lisp community of adopting a syntax compatible with the
DEFPACKAGE they are already using.
-- Scott
∂18-Mar-88 1405 CL-Cleanup-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Mar 88 14:05:00 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 366029; Fri 18-Mar-88 17:05:20 EST
Date: Fri, 18 Mar 88 17:05 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880318170509.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I wasn't quite sure what to write, so just kind of made something up.
Is this what people were looking for?
-----
Issue: ADJUST-ARRAY-FILL-POINTER
References: ADJUST-ARRAY (p297)
Category: CLARIFICATION
Edit history: 15-Mar-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL does not specify clearly the effect of ADJUST-ARRAY on the fill
pointer.
Proposal (ADJUST-ARRAY-FILL-POINTER:MINIMAL):
Clarify that the :FILL-POINTER keyword argument to ADJUST-ARRAY is treated
as follows...
If :FILL-POINTER argument is not given, then the fill-pointer of the array
to be adjusted (if any) is left alone. It is an error to adjust an array
to a size smaller than its fill pointer without specifying the :FILL-POINTER
option so that its fill-pointer is properly adjusted in the process.
If supplied, the :FILL-POINTER argument must be either an integer between 0
and the new size of the array, the symbol T (indicating that the new size
of the array should be used), or the symbol NIL (indicating that the fill
pointer should left as it is -- as if the :FILL-POINTER option had not been
specified).
An error is signalled if a non-NIL value for :FILL-POINTER is supplied and
the array to be adjusted does not already have a fill pointer.
Test Case:
(SETQ A1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ A2 (ADJUST-ARRAY A1 4))
(FILL-POINTER A1) => 3
(FILL-POINTER A2) => 3
(SETQ B1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ B2 (ADJUST-ARRAY B1 2 :FILL-POINTER 1))
(FILL-POINTER B1) => 1
(FILL-POINTER B2) => 1
(SETQ C1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ C2 (ADJUST-ARRAY C1 2 :FILL-POINTER T))
(FILL-POINTER C1) => 2
(FILL-POINTER C2) => 2
(SETQ D1 (MAKE-ARRAY 5 :ADJUSTABLE T))
(SETQ D2 (ADJUST-ARRAY D1 2 :FILL-POINTER 2)) signals an error.
(SETQ E1 (MAKE-ARRAY 5 :FILL-POINTER T :ADJUSTABLE T))
(SETQ E2 (ADJUST-ARRAY E1 4)) is an error.
Rationale:
This behavior must be more clearly defined if portable programs are going
to be able to depend on it.
Current Practice:
Symbolics Lisp implements the proposal. In case "E", it does not signal an
error. It simply leaves the illegal fill-pointer in place so that the
programmer can correct it using (SETF (FILL-POINTER E2) ...)
Cost to Implementors:
Probably most implementations do not deviate significantly from the proposed
behavior. The cost to implementors is probably very slight.
Cost to Users:
None. This clarifies a fuzzy area in the manual which users cannot currently
depend upon.
Cost of Non-Adoption:
The interaction between ADJUST-ARRAY and fill-pointers would continue to be
hazy, and portable programs would not be able to rely upon that behavior
being consistent across implementations.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
There is little if any aesthetic impact of this change.
Discussion:
Pitman volunteered to write this issue up for the Cleanup committee. He's
not very passionate about the details one way or another, but figures it's
a good idea that they be clarified.
∂18-Mar-88 1439 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Mar 88 14:39:05 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 366054; Fri 18-Mar-88 17:39:30 EST
Date: Fri, 18 Mar 88 17:39 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880318173922.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
This is somewhat sketchy, but I thought I'd get it on the table as is and people
could flesh it out as the discussion evolves...
-kmp
-----
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:RADICAL):
Remove EQUAL and EQUALP from the language. (Naturally, they could be retained
as implementation-dependent extensions.)
Rationale:
The name "EQUAL" suggests something very generic. It conjures in the mind
of the naive user the notion that there is a single, uniquely selected
predicate which is always good for equality testing. In fact, there is a
large space of useful equality predicates, each good for different
applications, and the choice of the current definition of EQUAL is
exceedingly arbitrary. Although the function chosen is sometimes quite
useful and some work is occassionally saved by having it be defaultly
available, confusion frequently results from its presence. Users for whom
the operator is not appropriate are inclined to describe it as broken,
rather than to recognize that it does a useful thing but that the
application they have does not call for that useful thing. The thing which
would be useful to them would not be useful in other situations. There is
simply no unique solution. The absence of the operator EQUAL would cause
people to think explicitly about what kind of equivalence is appropriate
to their application, and to write something better suited to that
application.
As an aside, this same notion of uniqueness carries over to COPY. People
have been observed to assert that a generic COPY function should be
present for copying arbitrary objects. A single COPY function is not
provided because there are many kinds of copying and no single function is
entitled to the generic name COPY. This argument does not sit well with
programmers who assert that if this is true, there should be no unique
EQUAL operator. We could solve that problem two ways -- one by creating a
COPY operator; another by eliminating the embarrassment of EQUAL and
friends.
Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Leave things as is.
Rationale:
The intent of a structure is different than the intent of an array. A
list is an anonymous entity which makes sense only in terms of its
length and contents, and is not rightly compared just by object identity
(EQ); a structure, on the other hand, has an identity of its own and is
appropriately compared with EQ.
Proposal (EQUAL-STRUCTURE:DESCEND):
Change EQUAL and EQUALP to descend structure slots.
Rationale:
A structure is a container and, like many other containers in Lisp,
should be compared by recursing into the contents of that container.
Proposal (EQUAL-STRUCTURE:ADD-KEYWORDS):
Add :TEST and :TEST-NOT keywords to EQUAL saying what comparison operator
to use at the leaves.
[This will need more details if anyone decides they want to push this line
of reasoning. I don't claim to have done an adqeuate job of laying the
issue out, though I could imagine someone doing so. -kmp]
Rationale:
There's ample precedent for resolving sticky situations like this in
Common Lisp by just adding a keyword option. :-)
Proposal (EQUAL-STRUCTURE:ADD-OPERATOR)
Introduce new operator(s) like EQUAL (and/or EQUALP) which descends
structures.
Rationale:
If people don't want to make EQUAL more complicated, but still like
the idea of a keyword-driven EQUAL, this is the only way to get it.
Current Practice:
There is no particular ambiguity in CLtL right now, so presumably
everyone agrees. The only question is whether what CLtL says is
sufficiently useful in practice.
Cost to Implementors:
The cost to implementors of most of these options is generally small.
The exception is that the ADD-KEYWORDS option may require hairy compiler
optimizations in order to get back the efficiency that a keyword would lose.
Cost to Users:
Writing an EQUAL or EQUALP function which is like the one that Common Lisp
now has would not be that hard to do as a compatibility measure in case
EQUAL or EQUALP were changed or removed. So the cost to users is technically
small.
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
Aesthetic considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
The ADD-KEYWORDS option will be the most controversial because some people
don't like keywords and some compiler writers will not like having to
optimize the keywords.
Discussion:
Pitman strongly supports EQUAL-STRUCTURE:RADICAL as the correct choice from
a purely language design standpoint, but acknowledges that it may not
ultimately be deemed practical for pragmatic reasons.
∂18-Mar-88 1611 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 88 16:11:40 PST
Received: by labrea.Stanford.EDU; Fri, 18 Mar 88 15:53:07 PST
Received: from kent-state.lucid.com by edsel id AA08362g; Fri, 18 Mar 88 15:37:18 PST
Received: by kent-state id AA03234g; Fri, 18 Mar 88 15:46:22 PST
Date: Fri, 18 Mar 88 15:46:22 PST
From: Eric Benson <edsel!eb@labrea.Stanford.EDU>
Message-Id: <8803182346.AA03234@kent-state.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Fri, 18 Mar 88 17:39 EST <880318173922.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 1)
Here's one more to add to your list. Kent, I will merge this and
create Version 2 if you like, otherwise I expect that you will include
these with any other changes you might have. (I actually prefer
EQUAL-STRUCTURE:RADICAL myself, but I'm trying to be practical.)
Proposal (EQUAL-STRUCTURE:CHANGE-EQUALP):
Change EQUALP so that it descends structures, is case sensitive, and
never considers numbers of different types to be equal.
Rationale:
Several users have independently inquired why there is no predicate
with this definition in Common Lisp. Also, use of EQUALP is not
widespread. Rather than invent a new name for a predicate, it
would be preferable to take an existing name which is not being
heavily used and give it a more useful definition.
It would also be useful to have EQUALP type hashtables, given this
new definition for EQUALP.
EQUALP did not exist in Lisp dialects preceding Common Lisp. There
are few programs that make use of EQUALP and only those depending
on case insensitivity or numeric coercion (or lack of structure
descending) would be affected.
Discussion:
Eric Benson supports EQUAL-STRUCTURE:CHANGE-EQUALP. He has never
used EQUALP in a "serious" program, but in every "casual" use he has
wished that it was case sensitive.
∂18-Mar-88 2051 CL-Cleanup-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 88 20:51:22 PST
Received: by labrea.Stanford.EDU; Fri, 18 Mar 88 20:51:25 PST
Received: from bhopal.lucid.com by edsel id AA09410g; Fri, 18 Mar 88 20:31:09 PST
Received: by bhopal id AA24393g; Fri, 18 Mar 88 20:38:24 PST
Date: Fri, 18 Mar 88 20:38:24 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803190438.AA24393@bhopal.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Fri, 18 Mar 88 17:05 EST <880318170509.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
Lucid Common Lisp implements the described behaviour, including the signalling
of errors in both error cases.
-- JonL --
∂18-Mar-88 2128 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 1)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 88 21:28:27 PST
Received: by labrea.Stanford.EDU; Fri, 18 Mar 88 21:28:55 PST
Received: from bhopal.lucid.com by edsel id AA09699g; Fri, 18 Mar 88 21:14:33 PST
Received: by bhopal id AA24439g; Fri, 18 Mar 88 21:21:51 PST
Date: Fri, 18 Mar 88 21:21:51 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803190521.AA24439@bhopal.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Fri, 18 Mar 88 17:39 EST <880318173922.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 1)
Generally ok write-up of the issues. You left out the option of adding
a jillion-skillion new functions -- one for each conceivable kind of
equivalence relation between s-expressions. But that's ok; I want to
focus on just one of your proposals.
re: Proposal (EQUAL-STRUCTURE:DESCEND):
Change EQUAL and EQUALP to descend structure slots.
EQUALP is already documented to descend structures (CLtL, p81). So this
proposal should just say "Change EQUAL ...".
Had all the negative arguments against this particular proposal -- the one
you call (EQUAL-STRUCTURE:DESCEND) -- been thought of 6 years ago, CL could
not even have an EQUALP function. The logical conclusion of these
"technical details" arguments is that EQUAL cannot be defined either.
These arguments go roughly as follows:
(1) The equivalence which EQUAL implements is not graph-isomorphism --
which *is* uniquely defined -- but rather an ill-defined one
making reference to the underspecified notion of "printing".
Attempts to make it more precise are merely arbitrary.
(2) EQUAL is not a total function since it is permitted to run amok
on circular structures. In fact, it is much more "likely" that
defstruct instances will contain ultimately circular links than
that cons cells will; hence one will "probably" lose more much
often if EQUAL were to descend structures.
The more "wizard", or "theorist" one is, the more compelling the above
arguments seem. On the other hand, the more a "user" one is, the more
likely he will argue as follows:
I've used the EQUAL function for over 15 years, and have almost never
been dissatisfied with it, as the Doctors of Technology say I should be;
and every instance of dissatisfaction was due to its failue to descend
through pointer vectors. I keep my house in order, and know exactly
how my data pyramids are built up; so why should I be punished just
because some Conehead somewhere got lost playing around with his
Klein bottles and Moebius strips?
All the problems alleged for EQUALP's descent into structures also apply
to EQUAL's descent into lists; it's only a matter of probabilities. Hence,
I don't believe this issue can be settled by technical discussion.
The only non-time-wasting effort I can see to do from now on is to look for
some way to present our dilemma to a broad "user" community. We could try
to tell them, in cursory terms and few words, of the technical arguments
that show EQUAL (and EQUALP) to be ill-behaved functions. Then let them
decide (by straw vote?) if the extra functionality provided by this proposal
is worth the extra risk.
Related Issues:
-- Are DEFSTRUCT-defined types and CONS, ARRAY, HASH-TABLE, PACKAGE,
READTABLE, STREAM, etc. pairwise disjoint?
-- Will CLOS require EQUAL to be "generic"? Also, what about COPY?
-- JonL --
∂19-Mar-88 1521 CL-Cleanup-mailer FUNCTION-TYPE proposal
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Mar 88 15:21:15 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA12899; Sat, 19 Mar 88 16:22:01 MST
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8803192322.AA12899@cs.utah.edu>
Date: Sat, 19 Mar 88 16:22:00 MST
Subject: FUNCTION-TYPE proposal
To: cl-cleanup@sail.stanford.edu
I just wanted to clarify the question about item 5 of the FUNCTION-TYPE
proposal that I brought up at the meeting. The current language in CLtL
*requires* FBOUNDP to return true for a symbol naming a macro or special
form. The proposal says that *it is permissible* for FBOUNDP to return
true in this situation, which in my mind leaves open the possibility
that it might not return true, and seems to be just the opposite of a
clarification.
Assuming that FBOUNDP must be true of macros and special forms, the
implication of item 5b is that SYMBOL-FUNCTION must *not* return a
function if the symbol names a macro or special form. In particular,
the language on p. 144 of CLtL makes it clear that macro functions are
ordinary functions of two arguments and that macro-ness is a property
of the symbol they are attached to, not the function which is used to
produce the expansion of the macro.
Since item 5a says that SYMBOL-FUNCTION must return *something* if its
argument names a macro or special form, and since that something can't
be a function, is there any reason why we couldn't say exactly what
it should return in those situations? For example, if it returned T,
one could use a bit of code like (AND (FBOUNDP f) (SYMBOL-FUNCTION f))
to test whether the symbol "f" has some interpretation when it appears
as the CAR of a list. A return value of NIL would also have its uses.
Certainly either one would be more useful than wimping out and saying
it's not well-defined.
-Sandra
-------
∂21-Mar-88 1121 CL-Cleanup-mailer Pending issue status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Mar 88 11:21:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAR 88 11:16:22 PST
Date: 21 Mar 88 11:12 PST
From: Masinter.pa@Xerox.COM
Subject: Pending issue status
To: cl-cleanup@sail.stanford.edu
Message-ID: <880321-111622-3697@Xerox>
These are my notes from the subcommittee meeting. I know that I've made some
mistakes, so please send any corrections (or just questions) if you have any
different recollection.
We should have *all* of these issues ready for release by the June meeting,
which means that we need to get started immediately.
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
JonL will submit a proposal, based on discussion of "The array type mess".
ADJUST-ARRAY-FILL-POINTER
KMP (has already submitted) a proposal
COERCE-INCOMPLETE
Pierson & Moon have comments and will mail them to CL-CLEANUP with
cc to Ida.
CONSTANT-SIDE-EFFECTS
To be deferred to compilation semantics committee; Walter Vanroggen
has some comments.
DATA-TYPES-HIERARCHY-UNDERSPECIFIED
Guy will send a proposal.
DECLARATION-SCOPE
JonL has a comment to send, none other.
DECLARE-TYPE-EXACT
I will mail the issue out (again?) for comment
DEFINITION-DELETE
(Renamed from DEFINITION-FUNCTIONS). JonL will submit.
DEFMACRO-BODY-LEXICAL-ENVIRONMENT
Defer to the compilation committee; Pavel will make his
suggestion there.
DEFPACKAGE
Haflich mentions that the compilation committee is looking at some
of the same issues. I will mail the DEFPACKAGE discussion
to Haflich, and we should cc him on mail.
DEFSTRUCT-SLOTS-CONSTRAINTS
DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Skona will write up.
EQUAL-STRUCTURE
KMP (has already) submitted proposal.
EVAL-OTHER
Guy will mail opposition.
EXPORT-IMPORT (really withdrawn)
FILE-LENGTH-PATHNAME
I have two notes, one is "withdrawn" and the other is "may return NIL".
I think the first is correct.
FILE-WRITE-DATE-IF-NOT-EXISTS
KMP will incorporate in the list-of-signals part of the signal proposal
FORMAT-NEGATIVE-PARAMETERS
KMP will incorporate in the list-of-signals part of the signal proposal
FUNCTION-ARGUMENT-TYPE-SEMANTICS
Eric Benson and Walter Vanroggen will submit a proposal based
on current practice.
FUNCTION-SPECS
Defer to the definition-specs subcommittee
GC-MESSAGES
Withdrawn for good this time
LAMBDA-LIST-DUPLICATES
Agree to outlaw in all cases. May need a clarification, depending on
what CLtL says.
LAST-N
Ready for release
LET-TOP-LEVEL
Defer to compilation committee
LISP-SYMBOL-DEFINITION
Masinter to write-up, it is an error to redefine Lisp symbols.
LOAD-TIME-EVAL
KMP and Moon will wrangle out. The compilation committee
is also looking at this issue so coordination is required.
MACRO-FUNCTION-ENVIRONMENT
Pavel will write up
MAPPING-DESTRUCTIVE-INTERACTION
KMP will mail new version
PATHNAME-SUBDIRECTORY-LIST
PATHNAME-UNSPECIFIC-COMPONENT
Moon and Pierson will work out a proposal. (I will send back mail
to Pierson.)
PEEK-CHAR-READ-CHAR-ECHO
I will remail issue and discussion to this list.
PROCLAIM-LEXICAL
JonL will submit a new proposal.
prompt-for
Withdrawn, this time for good.
REMF-DESTRUCTION-UNSPECIFIED
I will send back mail to Dussud
REMF-MULTIPLE
Yes, needs clarification
REQUIRE-PATHNAME-DEFAULTS
Moon will send proposal to remove REQUIRE from language
REST-LIST-ALLOCATION
Moon will send proposal
SETF-METHOD-FOR-SYMBOL
Withdrawn, subsumed by SETF-SUB-METHODS
SETF-SUB-METHODS
Continue mail discussion
SHARPSIGN-PLUS-MINUS-NUMBER
Codify current practice: allowed, read in base 10.
SHARPSIGN-BACKSLASH-BITS
Withdrawn (defer to character committee).
SPECIAL-FORM-SHADOW
To be merged with LISP-SYMBOL-REDEFINITION
SPECIAL-VARIABLE-TEST
JonL has a comment, but a nit.
STANDARD-INPUT-INITIAL-BINDING
Pierson will send a new version
STEP-ENVIRONMENT
Moon will separate into STEP-ENVIRONMENT and TIME-ENVIRONMENT.
STREAM-CLASS-ACCESS
I will revive FOLLOW-SYNONYM-STREAM as a separate proposal.
Walter will mail comments on current practice in VaxLisp
STRUCTURE-DEFINITION-ACCESS
I will revive, mail comments
SUBSEQ-OUT-OF-BOUNDS
Steele will send proposal
TAILP-NIL
I will mail again
TRACE-FUNCTION-ONLY
I will send a proposal to make TRACE undefined
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
JonL and Moon have comments. Moon has a
description of stack model and unwind as atomic.
VECTOR-PUH-EXTEND-DEFAULT
Withdrawn
My notes also have that we would entertain (again) adding EXIT and GC as common
names to the implementation dependent operations of "leave Lisp" and "initiate
garbage collection".
∂21-Mar-88 1628 CL-Cleanup-mailer Issue: MACRO-FUNCTION-ENVIRONMENT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Mar 88 16:28:28 PST
Received: from Salvador.ms by ArpaGateway.ms ; 21 MAR 88 16:06:28 PST
Date: Mon, 21 Mar 88 16:05:12 PST
From: Pavel.pa@Xerox.COM
Subject: Issue: MACRO-FUNCTION-ENVIRONMENT
To: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <880321-160628-1159@Xerox>
Issue: MACRO-FUNCTION-ENVIRONMENT
References: MACRO-FUNCTION, p. 144
MACROLET, pp. 113-4
&ENVIRONMENT, pp. 145-6
MACROEXPAND and MACROEXPAND-1, pp. 151-2
Category: ADDITION
Edit history: Pavel, March 21, 1988 (Version 1)
Problem description:
The &ENVIRONMENT argument to a macro-expansion function may only be used as the
second argument to the functions MACROEXPAND and MACROEXPAND-1. It is sometimes
more convenient, however, to be able to work directly with the more primitive
function MACRO-FUNCTION, on which MACROEXPAND and MACROEXPAND-1 are presumably
based. However, since MACRO-FUNCTION does not take an environment argument, it
cannot be used in situations in which that environment must be taken into
account.
Proposal (MACRO-FUNCTION-ENVIRONMENT:YES): Add an optional second argument to
MACRO-FUNCTION, that argument being an environment that was passed as the
&ENVIRONMENT argument to some macro expansion function. If the argument is not
passed, then it defaults to the null environment. MACRO-FUNCTION will now
consider macro definitions from that environment in preference to ones in the
global environment. It is an error to supply the environment argument in a use
of MACRO-FUNCTION as a SETF location specifier.
Examples:
(macrolet ((foo (&environment env)
(if (macro-function 'bar env)
''yes
''no)))
(list (foo)
(macrolet ((bar () :beep))
(foo))))
=> (no yes)
Rationale:
Intuitively, the more primitive operation in macro expansion is MACRO-FUNCTION,
not MACROEXPAND or MACROEXPAND-1, yet the environment argument can only be
supplied to the latter functions and not to the former one. By changing this
state of affairs, the model of macro expansion becomes somewhat simpler. Also,
more flexible use of the facility is enabled.
Current practice:
Xerox Common Lisp already implements this proposal. Symbolics Common Lisp,
Lucid/Sun Common Lisp and Kyoto Common Lisp do not.
Cost to Implementors:
This is presumably a simple change to make, a small matter of moving the
environment-searching code from MACROEXPAND-1 to MACRO-FUNCTION.
Cost to Users:
The change is upward-compatible and so poses no cost to users.
Cost of non-adoption:
One more (small) semantic wart on the language.
Benefits:
The function that users think of as being more primitive really is.
Aesthetics:
This slightly cleans up the language.
Discussion:
Pavel is strongly in favor of the proposal.
∂21-Mar-88 1726 CL-Cleanup-mailer RE: Issue: MACRO-FUNCTION-ENVIRONMENT
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 21 Mar 88 17:26:32 PST
Date: 21 Mar 88 20:09:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: RE: Issue: MACRO-FUNCTION-ENVIRONMENT
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Looks pretty good, but how about explicitly allowing NIL as the environment,
indicating the null lexical environment? This is just as in GET-SETF-METHOD-
ENVIRONMENT, which you might as well add to the list of references.
BTW, VAX LISP already implements the proposed behavior.
I'm receiving CL-CLEANUP mail now (thank you, rpg), so there's no need
to CC to me. Also, please note that my real name is different from my
account/user name: "Walter van Roggen", and thus should never be spelled
"Walter Vanroggen" except by blind use of DELETE and STRING-CAPITALIZE.
---Walter
------
∂21-Mar-88 1743 CL-Cleanup-mailer Issue: MACRO-FUNCTION-ENVIRONMENT
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 17:43:04 PST
Received: by labrea.Stanford.EDU; Mon, 21 Mar 88 17:43:30 PST
Received: from kent-state.lucid.com by edsel id AA04493g; Mon, 21 Mar 88 17:41:27 PST
Received: by kent-state id AA01518g; Mon, 21 Mar 88 17:41:12 PST
Date: Mon, 21 Mar 88 17:41:12 PST
From: Eric Benson <edsel!eb@labrea.Stanford.EDU>
Message-Id: <8803220141.AA01518@kent-state.lucid.com>
To: Pavel.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Mon, 21 Mar 88 16:05:12 PST <880321-160628-1159@Xerox>
Subject: Issue: MACRO-FUNCTION-ENVIRONMENT
Lucid Common Lisp 3.0 implements this proposal.
∂21-Mar-88 1748 CL-Cleanup-mailer Re: Issue: MACRO-FUNCTION-ENVIRONMENT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Mar 88 17:48:49 PST
Received: from Salvador.ms by ArpaGateway.ms ; 21 MAR 88 17:40:35 PST
Date: Mon, 21 Mar 88 17:40:32 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: MACRO-FUNCTION-ENVIRONMENT
In-reply-to: "Your message of 21 Mar 88 20:09:00 EDT"
To: cl-cleanup@sail.stanford.edu
Message-ID: <880321-174035-1359@Xerox>
Walter says: ``how about explicitly allowing NIL as the environment, indicating
the null lexical environment? This is just as in GET-SETF-METHOD-ENVIRONMENT''
I thought of that, but didn't put it in because I couldn't find a reference to
it being allowed. I now have one, but did we ever also say that NIL could be
passed as the second argument to MACROEXPAND and MACROEXPAND-1?
Pavel
∂22-Mar-88 0633 CL-Cleanup-mailer cleanup for equal ?
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 06:33:29 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 Mar 88 09:35-EST
Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 84952; 22 Mar 88 09:31:38-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 97300; Tue 22-Mar-88 08:58:02-EST
Date: Tue, 22 Mar 88 08:59 est
From: mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com after 1-April-88)
COMMENTS: NOTE %acorn@oak... CHANGES TO @GOLD-HILL.COM ON 1-April-88
To: cl-cleanup@sail.stanford.edu
Subject: cleanup for equal ?
Is there already a cleanup item for EQUAL? The definition
on page 80 of CLtL is very loose. If there is not, I will
compose one.
...mike beckerle
Gold Hill
∂22-Mar-88 0955 CL-Cleanup-mailer stream-access background information
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 22 Mar 88 09:55:33 PST
Date: 22 Mar 88 12:44:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: stream-access background information
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Here's a summary of some of the extensions we've added to VAX LISP
to make the functionality of CLtL more "complete". Instead of a new
LISTEN2 function, perhaps we should modify LISTEN to just return a
second value as well.
---Walter
-----------------------------------------------------------------------
VAX LISP provides access to more detailed information about streams
than is called for in COMMON LISP: The Language. VAX LISP provides a
separate data type for each stream type, a predicate for each stream
type, functions to retrieve elements that were used to construct streams,
and several new I/O functions.
Stream Data Types and Predicates
BROADCAST-STREAM BROADCAST-STREAM-P object
CONCATENATED-STREAM CONCATENATED-STREAM-P object
DRIBBLE-STREAM DRIBBLE-STREAM-P object
ECHO-STREAM ECHO-STREAM-P object
FILE-STREAM FILE-STREAM-P object
STRING-STREAM STRING-STREAM-P object
SYNONYM-STREAM SYNONYM-STREAM-P object
TERMINAL-STREAM TERMINAL-STREAM-P object
TWO-WAY-STREAM TWO-WAY-STREAM-P object
Stream Informational Functions
BROADCAST-STREAM-STREAMS broadcast-stream ==> list of streams
CONCATENATED-STREAM-STREAMS concatenated-stream ==> list of streams
ECHO-STREAM-INPUT-STREAM echo-stream ==> stream
ECHO-STREAM-OUTPUT-STREAM echo-stream ==> stream
SYNONYM-STREAM-SYMBOL synonym-stream ==> symbol
TWO-WAY-STREAM-INPUT-STREAM two-way-stream ==> stream
TWO-WAY-STREAM-OUTPUT-STREAM two-way-stream ==> stream
LINE-POSITION &OPTIONAL output-stream
Returns the number of characters that have been output on the current
line if that number can be determined and NIL otherwise.
Output-stream defaults to *STANDARD-OUTPUT*. If a value of T is
supplied, the value of *TERMINAL-IO* is used.
LISTEN2 &OPTIONAL input-stream
Returns two values. The first is identical to the value returned by
the COMMON LISP LISTEN function; the second is T if end-of-file was
encountered on the input stream, and NIL otherwise. You can use this
function wherever you would normally use LISTEN.
Input-stream defaults to *STANDARD-INPUT*. If a value of T is
supplied, the value of *TERMINAL-IO* is used.
OPEN-STREAM-P stream
Returns T if a stream is open, NIL if it is closed. It is an error
if the argument is not a stream.
------
∂22-Mar-88 1025 CL-Cleanup-mailer Re: stream-access background information
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Mar 88 10:25:01 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 22 MAR 88 10:15:47 PST
Date: 22 Mar 88 10:15 PST
From: Masinter.pa@Xerox.COM
Subject: Re: stream-access background information
In-reply-to: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>'s message
of 22 Mar 88 12:44:00 EDT
To: vanroggen%aitg.decnet@hudson.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880322-101547-1877@Xerox>
Of the ones in your list, DRIBBLE-STREAM, FILE-STREAM, TERMINAL-STREAM are the
ones that seem questionable. We've managed to evicerate DRIBBLE; we've had
trouble in the past defining what a "file" is (one that can be coerced to a
pathname?), and TERMINAL-STREAM is true of *TERMINAL-IO* sometimes? What is a
"terminal"?
On LISTEN2, how do you define "end-of-file"?
On OPEN-STREAM-P, how do you define "open"?
∂22-Mar-88 1324 CL-Cleanup-mailer RE: stream-access background information
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 22 Mar 88 13:24:10 PST
Date: 22 Mar 88 16:17:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: RE: stream-access background information
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
I just presented the types and functions we've publicized; it doesn't
mean they all have to be part of Common Lisp. I'd be quite happy if
they weren't part of any cleanup proposal; but I did want to make sure
that if people did want certain functionality, that the names agree
with what we chose (unless there's a good reason to the contrary).
I believe "end-of-file" for LISTEN2 is defined the same way as for
other input functions which deal with "end-of-file".
The need for OPEN-STREAM-P is because there's no way in Common Lisp
to tell if it's OK to do I/O to a stream; i.e., there's no way to tell
if a stream has been CLOSEd already. If your question was would
(open-stream-p (make-string-output-stream)) be true, then yes, for
any stream that hadn't been CLOSEd.
Which reminds me of another issue I don't recall having seen recently.
What does CLOSE do on compound streams? I believe we close that stream
and don't do anything with the component streams.
---Walter
------
∂22-Mar-88 1630 CL-Cleanup-mailer New "issue" and proposal
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 22 Mar 88 16:29:52 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa26807; 22 Mar 88 18:49 EST
Received: from tektronix.tek.com by RELAY.CS.NET id ac05018; 22 Mar 88 18:39 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA20128; Tue, 22 Mar 88 12:59:24 PST
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA25927; Tue, 22 Mar 88 12:58:15 PST
Message-Id: <8803222058.AA25927@tekchips.CRL.TEK.COM>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU, willc@tekchips.crl.tek.com
Subject: New "issue" and proposal
Date: 22 Mar 88 12:58:12 PST (Tue)
From: willc%tekchips.CRL@tektronix.tek.com
Issue: FUNCTION-CALL-EVALUATION-ORDER
References: none
Category: CLARIFICATION
Edit history: Version 1 by Clinger (22 March 1988)
Problem Description:
CLtL does not say whether the function expression of a call is evaluated
before or after the argument expressions.
Proposal (FUNCTION-CALL-EVALUATION-ORDER:UNSPECIFIED):
Common Lisp does not specify whether the function expression of a call is
evaluated before or after the argument expressions. Programs that rely on
a particular order of evaluation are in error.
Example:
(defun foo (x) (+ x 3))
(defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))
(foo (progn (bar) 20))
; may return 23 or 24
Rationale:
This makes the status quo explicit.
Current Practice:
TI and Symbolics evaluate the function expression last. Lucid and Coral
sometimes evaluate the function expression first and at other times evaluate
the function expression last.
Cost to implementors:
None.
Cost to users:
None.
Benefits:
Codifies an ambiguity.
Aesthetics:
Since Common Lisp evaluates argument expressions from left to right, it would
be more consistent for the function expression to be evaluated before the
argument expressions. On the other hand, the evaluation rules for function
expressions are already quite different from the rules for argument
expressions, and nobody in their right mind would write code that depends on
the order of evaluation, so aesthetics should not count for much in this case.
Requiring left to right evaluation would force some implementations to consume
an extra register for many function calls. The efficiency argument seems more
important than the aesthetic argument.
∂22-Mar-88 1649 CL-Cleanup-mailer Re: New "issue" and proposal
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Mar 88 16:48:55 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 22 MAR 88 16:42:15 PST
Date: Tue, 22 Mar 88 16:41:16 PST
From: Pavel.pa@Xerox.COM
Subject: Re: New "issue" and proposal
In-reply-to: <8803222058.AA25927@tekchips.CRL.TEK.COM>
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: willc@tekchips.crl.tek.com
Message-ID: <880322-164215-2817@Xerox>
I support this proposal.
Pavel
∂22-Mar-88 2030 CL-Cleanup-mailer Strings as streams
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 20:29:56 PST
Received: by labrea.Stanford.EDU; Tue, 22 Mar 88 20:30:35 PST
Received: from bhopal.lucid.com by edsel id AA09780g; Tue, 22 Mar 88 20:24:51 PST
Received: by bhopal id AA04807g; Tue, 22 Mar 88 20:24:36 PST
Date: Tue, 22 Mar 88 20:24:36 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803230424.AA04807@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Strings as streams
Does anyone know whether the following point has been "clarified" at all?
say, in Guy's previous notes about clarifications and corrections?
CLtL p386 says that formatting to a fill-pointer'd string should add
characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that
with-outuput-to-string will work "as if using VECTOR-PUSH-EXTEND if the
string is adjustable, and otherwise as if using VECTOR-PUSH".
Possibly the description of FORMAT merely needs the additional wording?
-- JonL --
∂23-Mar-88 1006 CL-Cleanup-mailer Strings as streams
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 10:05:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368588; Wed 23-Mar-88 11:28:13 EST
Date: Wed, 23 Mar 88 11:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Strings as streams
To: Jon L White <edsel!jonl@labrea.Stanford.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8803230424.AA04807@bhopal.lucid.com>
Message-ID: <19880323162809.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 22 Mar 88 20:24:36 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Does anyone know whether the following point has been "clarified" at all?
say, in Guy's previous notes about clarifications and corrections?
I don't recall this point coming up before. It's not in 86-003.
CLtL p386 says that formatting to a fill-pointer'd string should add
characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that
with-outuput-to-string will work "as if using VECTOR-PUSH-EXTEND if the
string is adjustable, and otherwise as if using VECTOR-PUSH".
Possibly the description of FORMAT merely needs the additional wording?
I think FORMAT is right and WITH-OUTPUT-TO-STRING is wrong. If more
characters are output than will fit in the string, VECTOR-PUSH-EXTEND
either does the right thing or signals an error, depending on whether
the string is adjustable, whereas VECTOR-PUSH just throws away the
excess characters. It seems clear to me that throwing away some
characters without signalling an error is not desirable behavior.
I suspect the mention of VECTOR-PUSH under WITH-OUTPUT-TO-STRING was
just a mistake, perhaps a momentary thought that VECTOR-PUSH-EXTEND
always signalled an error if handed a non-adjustable vector, even when
it wasn't full.
JonL, would you like to write up a cleanup proposal for this, or should I?
∂23-Mar-88 1048 CL-Cleanup-mailer Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 10:48:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368716; Wed 23-Mar-88 13:48:39 EST
Date: Wed, 23 Mar 88 13:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
To: willc%tekchips.CRL@tektronix.tek.com, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8803222058.AA25927@tekchips.CRL.TEK.COM>
Message-ID: <19880323184829.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 22 Mar 88 12:58:12 PST (Tue)
From: willc%tekchips.CRL@tektronix.tek.com
Problem Description:
CLtL does not say whether the function expression of a call is evaluated
before or after the argument expressions.
It also does not say in what order the argument expressions are evaluated!
Shouldn't we deal with that first, or at the same time? As far as I know
current practice is always to evaluate the argument expressions in a function
call from left to right, and I would certainly support a proposal to mandate
that in the language. Someone please tell me that I am confused and have
overlooked the place in CLtL that specifies the order of evaluation of
function arguments.
Proposal (FUNCTION-CALL-EVALUATION-ORDER:UNSPECIFIED):
Common Lisp does not specify whether the function expression of a call is
evaluated before or after the argument expressions. Programs that rely on
a particular order of evaluation are in error.
I support this proposal.
Current Practice:
TI and Symbolics evaluate the function expression last. Lucid and Coral
sometimes evaluate the function expression first and at other times evaluate
the function expression last.
Actually Symbolics is in the same camp as Lucid and Coral here, although
right now the answer is usually last. Whether TI evaluates the function
first or last depends on which release of TI software you're using.
∂23-Mar-88 1102 CL-Cleanup-mailer Issue: MACRO-FUNCTION-ENVIRONMENT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:01:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368731; Wed 23-Mar-88 14:01:36 EST
Date: Wed, 23 Mar 88 14:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MACRO-FUNCTION-ENVIRONMENT
To: Pavel.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880321-160628-1159@Xerox>
Message-ID: <19880323190138.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I support this proposal, with the modification to allow NIL as a
synonym for the global environment.
∂23-Mar-88 1105 CL-Cleanup-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:05:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368735; Wed 23-Mar-88 14:06:06 EST
Date: Wed, 23 Mar 88 14:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880318170509.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880323190609.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support ADJUST-ARRAY-FILL-POINTER:MINIMAL.
∂23-Mar-88 1110 CL-Cleanup-mailer Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:10:41 PST
Received: from Salvador.ms by ArpaGateway.ms ; 23 MAR 88 11:01:31 PST
Date: Wed, 23 Mar 88 11:01:26 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
In-reply-to: <19880323184829.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: willc%tekchips.CRL@tektronix.tek.COM, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880323-110131-1794@Xerox>
Dave says: ``[CLtL] also does not say in what order the argument expressions are
evaluated! Shouldn't we deal with that first, or at the same time?''
The closest thing I could find in CLtL to a statement about argument evaluation
order is the statement in the description of LET that the bound expressions are
evaluated in order. Since a number of implementations (including Lucid)
macro-expand LET into a called LAMBDA, they are clearly depending upon this
behavior.
While I would prefer, as a compiler writer and language designer, to leave the
order of argument evaluation unspecified, as in Scheme, I fear that so many user
programs critically depend upon the status quo (assumed always to be
left-to-right) that we can do nothing but reaffirm that officially.
Pavel
∂23-Mar-88 1117 CL-Cleanup-mailer Issue: LAST-N (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:17:16 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368759; Wed 23-Mar-88 14:17:52 EST
Date: Wed, 23 Mar 88 14:17 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAST-N (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880312210753.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880323191752.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support LAST-N:ALLOW-OPTIONAL-ARGUMENT on the basis that
"This would make it more obvious why LAST should return a list and not
an element. ie, it would return the "last N elements" where N=1 by default."
I certainly support releasing it to X3J13 and letting them decide what they
think of it.
∂23-Mar-88 1150 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:49:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368796; Wed 23-Mar-88 14:49:59 EST
Date: Wed, 23 Mar 88 14:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
References: <19880313000007.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19880323194958.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: DEFPACKAGE
References: CLtL section 11.7.
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Problem description:
The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system. The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished. Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended. These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and give Common Lisp a bad name.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. It encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. This file can be read in the USER package, avoiding any
package bootstrapping issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Also expand MAKE-PACKAGE and IN-PACKAGE to take all the same keyword
arguments as DEFPACKAGE, for consistency.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
package-name is a symbol or a string; if a symbol, only its name
matters, not what package it is in. If a string, capitalization
matters, normally uppercase is used.
Standard options for DEFPACKAGE are listed below. Additional options
might be present in an implementation, and each implementation must
signal an error if an option not recognized by that implementation is
present. Additional implementation-dependent options might take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
Each option may appear at most once. If duplicate options are present,
DEFPACKAGE signals an error.
(:EXPORT {symbol}*)
Create symbols with the specified names and export them.
Note that only the name of each argument symbol is used.
The symbol that gets exported is not necessarily the one given
as an argument; it's a symbol with that name but in the package
being defined.
(:IMPORT {symbol}*)
Import the specified symbols.
(:IMPORT-FROM {(package-name {symbol}*)}*)
(:IMPORT-FROM package-name {symbol}*)
Find the specified symbols in the specified packages and import
them into the package being defined. The second syntax is a
convenient abbreviation when only one package is specified.
Note that only the name of each argument symbol is used. The
actual symbol that gets imported is not necessarily the one
given as an argument; it's a symbol with that name accessible in
the named package.
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified strings.
(:SHADOW {symbol}*)
Create the specified symbols in the package and place them on
the shadowing list. Note that only the name of each argument
symbol is used.
(:SHADOWING-IMPORT {symbol}*)
Import the specified symbols into the package and make them
shadow any inherited symbols.
(:SHADOWING-IMPORT-FROM {(package-name {symbol}*)}*)
(:SHADOWING-IMPORT-FROM package-name {symbol}*)
Find the specified symbols in the specified packages and import
them into the package being defined, making them shadow any
inherited symbols. The second syntax is a convenient
abbreviation when only one package is specified. Note that only
the name of each argument symbol is used. The actual symbol
that gets imported is not necessarily the one given as an
argument; it's a symbol with that name accessible in the named
package.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
(:USE {package}*)
Inherit from the specified packages.
Example:
(DEFPACKAGE MY-PACKAGE
(:USE LISP)
(:SHADOW CAR CDR CONS)
(:NICKNAMES MYPKG MY-PKG))
Rationale:
See first paragraph of Proposal section.
Current practice:
Symbolics Common Lisp has always had this, and uses it in preference
to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL version
of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time.
Cost to Implementors:
Should be small as the macro can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
The "Put in seven extremely random user interface commands" business
described at the end of chapter 11 could be removed, and the special
compiler handling of these functions necessary to support that could be
removed. As this would be an incompatible change, it is not part of
this proposal.
KMP suggests that IN-PACKAGE should be incompatibly changed only to
recognize existing packages, not to create them, which would fix a lot
of bugs. IN-PACKAGE would then not accept any keyword arguments.
Moon thinks this is a reasonable idea but should be the subject of a
separate proposal.
∂23-Mar-88 1151 CL-Cleanup-mailer New issue: DEFPACKAGE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:50:50 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 368789; 23 Mar 88 14:45:34 EST
Date: Wed, 23 Mar 88 14:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New issue: DEFPACKAGE
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Pavel.pa@Xerox.COM, Eric Benson <edsel!eb@labrea.Stanford.EDU>, Richard Mlynarik <MLY@AI.AI.MIT.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880312191420.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<FAHLMAN.12381856106.BABYL@C.CS.CMU.EDU>,
<880313-163147-1810@Xerox>,
<8803140910.AA00538@kent-state.lucid.com>,
<880314085910.1.MLY@KLYTEMNESTRA.AI.MIT.EDU>,
<FAHLMAN.12382269523.BABYL@C.CS.CMU.EDU>
Message-ID: <19880323194526.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Here are my responses to comments received. My next message will be a
revised version of the proposal.
Date: Sat, 12 Mar 88 19:14 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I support the general idea of this proposal, but have a few nits to pick...
* I think IN-PACKAGE is broken for being able to demand-create a package.
It serves two unrelated roles, one of which being selection and the other
being creation. Extending it to allow more keywords will worsen the problem.
Given DEFPACKAGE, I would rather see IN-PACKAGE incompatibly changed to NOT
allow demand creation. This would fix a lot of bugs.
Agreed, but I think that should be a separate proposal. Added to the
discussion section.
* There might should be a :SHADOWING-IMPORT-FROM.
Agreed.
* I think that all options listed as symbol/string should be string-only.
People should be discouraged from naming symbols before the package structure
is fully in place. I'll stop short of suggesting that :IMPORT-FROM and
:SHADOWING-IMPORT-FROM completely replace :IMPORT and :SHADOWING-IMPORT,
which still muck with symbols.
I disagree because of alphabetic case issues in strings. Note that in
these symbol/string arguments, the symbol is being used only for its
name, so there are never any package issues. For instance, in :EXPORT,
if a symbol is given, the symbol that is exported from the package is
not necessarily that same symbol. It's a symbol with that name in the
package being defined. After looking at CLtL's writeup of SHADOW again,
I changed all of these to be symbol-only.
* I'm surprised you left out the Genera :INCLUDE feature, but I guess that
could always be added later if it was seen to be desired so it's ok.
I was not trying to propose any extensions to the semantics of packages.
(:INCLUDE is a Zetalisp release 4 compatibility feature that allows using
package A to automatically imply using package B as well.)
* :PREFIX-NAME is mentioned only in the same. To have it in an integrated fashion,
you'd need a PACKAGE-PREFIX-NAME function and some discussion of that it was
automatically a nickname if not explicitly in the list of names or nicknames.
This was an editing error. I didn't mean to propose the prefix-name
extension. (Prefix-name provides control over which name or nickname of
a package the printer uses when printing a symbol.)
Date: Sun, 13 Mar 88 16:31:26 PST
From: Pavel.pa@Xerox.COM
Just a nit for the moment:
``A keyword standing by itself is an abbreviation for a list (keyword T).''
This doesn't appear to be very useful, since none of the options will commonly
want to have an option-argument of T.
Right. This should have been in the part about implementation-dependent options.
I seem to have been pretty careless in the editing of this proposal.
Date: Sat, 12 Mar 1988 19:46 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
This looks good, as far as it goes, and the fact that it has actually
been tested in practice is a big plus -- it tends to give one confidence
that nothign critical has been overlooked.
Thanks.
I'm a bit uneasy about the syntax that you propose for the options. It
would be more compatible with the rest of Common Lisp to use alternating
keywords and arguments. Some users may find the odd syntax of your
DEFPACKAGE to be confusing. Is there some real advantage to the syntax
you propose, or is this just a bit of Zetalisp culture peeking through?
Symbolics has a very large number of macros that work this way, and we have
found it to be easier to use and less confusing than alternating keywords
and arguments. For one thing, it decreases the common confusion among both
naive and experienced users, in which they think they are supposed to put
in a ' in front of an argument when invoking a macro, as they would when
calling a function. Another point is that the semantics of duplicated
keywords is different. In a function call, Common Lisp specifies that
duplicate appearances of a keyword argument after the first are to be
ignored. In a macro, duplicate options should certainly not be ignored;
either the options should be combined in some way or an error should be
signalled, depending on the semantics of the particular option. I really
believe that a list of option name and arguments is the best syntax for
macros that take a bunch of options that are really a special-purpose
language for describing something.
With CLOS, Common Lisp will acquire several more macros that use this
syntax for options, which should make it less of a surprise to users who
have not seen this before.
Date: Mon, 14 Mar 88 01:10:57 PST
From: Eric Benson <edsel!eb@labrea.Stanford.EDU>
This syntax resembles that used for DEFSTRUCT options, so it does have
a precedent in CLtL.
Right.
Date: Mon, 14 Mar 88 08:59 EST
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
DEFSTRUCT (which nobody has ever accused of having non-`odd' syntax) also suffers
from the same non-&KEY-style.
The saddest things is that this type of syntactical lossage has infected
CLOS DEFxxx, probably because of the precedent in DEFFLAVOR. I personally
dislike the whole style; unfortunately it seems that few others feel strongly
enough about this issue to raise objections.
I have to strongly disagree with you here, for the reasons alluded to earlier.
∂23-Mar-88 1156 CL-Cleanup-mailer New issue: DEFPACKAGE
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:56:42 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Wed 23 Mar 88 14:57:11-EST
Date: Wed, 23 Mar 1988 14:57 EST
Message-ID: <FAHLMAN.12384686921.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: New issue: DEFPACKAGE
In-reply-to: Msg of 23 Mar 1988 14:45-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
OK, Moon's arguments for the proposed syntax are persuasive, to me at
least. Objection withdrawn. It would be a good idea to put that
part of Moon's message into the discussion section of the proposal.
-- Scott
∂23-Mar-88 1330 CL-Cleanup-mailer Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 23 Mar 88 13:29:49 PST
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09557; 23 Mar 88 21:26 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Wed, 23 Mar 88 21:25:42 gmt
Message-Id: <18525.8803232125@aiva.ed.ac.uk>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
Cc: willc <@NSS.Cs.Ucl.AC.UK,@tektronix.tek.com:willc@tekchips.crl>
Pavel says:
The closest thing I could find in CLtL to a statement about argument
evaluation order is the statement in the description of LET [...]
Actually, CLtL *does* say what the order of argument evaluation is.
It's on page 194, in the chapter on numbers:
... This does not affect the order in which argument forms
are evaluated, of course; that order is always left to right,
as in all Common Lisp function calls.
Cheers,
Jeff
∂24-Mar-88 0849 CL-Cleanup-mailer Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Mar 88 08:49:30 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 369322; Thu 24-Mar-88 11:19:40 EST
Date: Thu, 24 Mar 88 11:19 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <18525.8803232125@aiva.ed.ac.uk>,
<880323-110131-1794@Xerox>
References: <8803222058.AA25927@tekchips.CRL.TEK.COM>
Message-ID: <880324111926.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I support FUNCTION-CALL-EVALUATION-ORDER:UNSPECIFIED.
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Wed, 23 Mar 88 21:25:42 gmt
Pavel says:
The closest thing I could find in CLtL to a statement about argument
evaluation order is the statement in the description of LET [...]
Actually, CLtL *does* say what the order of argument evaluation is.
It's on page 194, in the chapter on numbers:
... This does not affect the order in which argument forms
are evaluated, of course; that order is always left to right,
as in all Common Lisp function calls.
Cheers,
Jeff
Also, p97 (in the description of SETF):
"SETF carefully arranges to preserve the usual left-to-right order
in which the various subforms are evaluated."
and again on p102 (in the description of DEFSETF):
"The implementation of DEFSETF takes care of ensuring that the
subforms of the reference are evaluated exactly once and in the
proper left-to-right order."
I will be happy to draft a separate proposal for the argument evaluation
order if people prefer to discuss that issue independently of the function
position. Certainly there is likely to be less (or different) controversy
on that issue, so separating them might not be unreasonable.
∂24-Mar-88 1052 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 Mar 88 10:52:25 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 24 Mar 88 13:51:39 EST
Received: by kali.think.com; Thu, 24 Mar 88 13:51:34 EST
Date: Thu, 24 Mar 88 13:51:34 EST
From: gls@Think.COM
Message-Id: <8803241851.AA10588@kali.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SUBSEQ-OUT-OF-BOUNDS
Issue: SUBSEQ-OUT-OF-BOUNDS
References: :START and :END arguments (246-247), SUBSEQ (248)
Category: CLARIFICATION
Edit history: 24-Mar-88, Version 1 by Steele
Problem description:
The descriptions of :START and :END arguments, and of SUBSEQ, do not
explicitly address the question of out-of-bounds indices. (The language on
page 246, "These arguments should be integer indices into the sequence," is
considered too vague on this point.)
Proposal (SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR):
Specify that it is an error for the :START argument of any standard
function, or the second argument to SUBSEQ, to be less than zero. Specify
that it is an error for the :END argument of any standard function, or the
third argument to SUBSEQ, to be greater than the length of the sequence in
question (as returned by LENGTH).
(Note that there is already a requirement that a start argument not
be greater than an end argument.)
Test Cases/Examples:
(SUBSEQ "Where's the beef?" -1 5) might be assumed to be "Where" or " Where".
(SUBSEQ "Where's the beef?" -3 -3) might be assumed to be "".
(SUBSEQ "Where's the beef?" 16 18) might be assumed to be "?" or "? ".
(SUBSEQ "Where's the beef?" 10000 10000) might be assumed to be "".
Under this proposal each of these situations is an error, and portable
programs may not rely on their behavior.
Rationale:
We don't want code indexing off the ends of arrays.
Current practice:
KCL interpreted and compiled code signals an error.
Symbolics Common Lisp interpreted and compiled code signals an error; the
compiler also issued an out-of-range warning (possible because the
arguments were all constant).
Lucid Common Lisp interpreted and compiled code signals an error.
Cost to Implementors:
None.
Cost to Users:
Users who depended on some specific implementation behavior in these cases
may find that their pragmatically unportable code is not officially
unportable.
Cost of non-adoption:
Confusion.
Benefits:
Removal of a small but important ambiguity in the spec.
Esthetics:
It seems cleaner not to allow indexing off the end of an array, and
by extension not allow it for any sequence.
Discussion:
This merely clarifies the original intent of the passage on page 246.
∂24-Mar-88 1438 CL-Cleanup-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 Mar 88 14:38:30 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 24 Mar 88 17:37:52 EST
Received: by kali.think.com; Thu, 24 Mar 88 17:37:48 EST
Date: Thu, 24 Mar 88 17:37:48 EST
From: gls@Think.COM
Message-Id: <8803242237.AA10817@kali.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED
Issue: DATA-TYPES-HIERARCHY-UNDERSPECIFIED
References: CLtL 33-35 (data types)
CLtL 312 (DEFSTRUCT :INCLUDE option)
Category: CHANGE
Edit history: 24-Mar-88, version 1 by Steele
Problem description:
The types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and
RANDOM-STATE currently are not required to be disjoint from CONS, SYMBOL,
ARRAY, NUMBER, or CHARACTER. The same is true of DEFSTRUCT types. With
the arrival of CLOS, lack of disjointness will be inconvenient because one
cannot reliably use generic function dispatch on these types.
Proposal (DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT):
Remove the third and antepenultimate bulleted items from section 2.15 is
CLtL and replace with the following:
* The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, HASH-TABLE, READTABLE,
PACKAGE, PATHNAME, STREAM, RANDOM-STATE, and any single other type created
by DEFSTRUCT [or DEFCLASS] are pairwise disjoint.
Also, in the discussion of the DEFSTRUCT :INCLUDE option, explicitly forbid
the type given to the :INCLUDE option to be CONS, SYMBOL, ARRAY, NUMBER,
CHARACTER, HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, or
RANDOM-STATE.
Test Cases/Examples:
Rationale:
It would be useful to extend sequence functions to operate on streams
or hash tables, for example, through the CLOS generic function mechanism.
This is not possible under the current specification.
Current practice:
Some implementations in effect use DEFSTRUCT to define data structures
such as hash tables and random-states.
Cost to Implementors:
Small or nonexistent. The main reason this disjointness was not specified
in CLtL was the possibility that structures might not be easily
distinguishable: a stupid concern over a slight efficiency. This
implementation freedom apparently has not been exploited in practice.
Cost to Users:
None.
Cost of non-adoption:
CLOS will be less useful.
Benefits:
CLOS will be more useful.
Esthetics:
This makes the type system simpler and easier to understand.
Discussion:
This suggestion originated in the CLOS committee.
∂25-Mar-88 1411 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Mar 88 14:11:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 370425; Fri 25-Mar-88 17:10:54 EST
Date: Fri, 25 Mar 88 17:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue SUBSEQ-OUT-OF-BOUNDS
To: gls@Think.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8803241851.AA10588@kali.think.com>
Message-ID: <19880325221052.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR, however I think we need
to be clearer about whether the upper bound is the fill-pointer or
the actual array length. I remember that this was controversial before.
Your rationale and esthetics could be taken as arguments for using the
actual array length. A close reading of your proposal shows that it
proposes using the fill pointer. Current practice in Symbolics Genera
is to use the fill pointer; I didn't check whether your other current
practice entries referred to the fill pointer or the actual array length.
Also be clearer that the start must less than or equal to the end even
if the end was defaulted or NIL.
In the cost to users section, I believe you have a typo, "not" where
you mean "now". This is one of those commonly made unfortunate typos
that reverses the meaning of a sentence.
∂25-Mar-88 1456 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 25 Mar 88 14:55:58 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 25 Mar 88 17:54:38 EST
Received: by kali.think.com; Fri, 25 Mar 88 17:54:32 EST
Date: Fri, 25 Mar 88 17:54:32 EST
From: gls@Think.COM
Message-Id: <8803252254.AA12274@kali.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 25 Mar 88 17:10 EST <19880325221052.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue SUBSEQ-OUT-OF-BOUNDS
Date: Fri, 25 Mar 88 17:10 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
I support SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR, however I think we need
to be clearer about whether the upper bound is the fill-pointer or
the actual array length. I remember that this was controversial before.
Your rationale and esthetics could be taken as arguments for using the
actual array length. A close reading of your proposal shows that it
proposes using the fill pointer. Current practice in Symbolics Genera
is to use the fill pointer; I didn't check whether your other current
practice entries referred to the fill pointer or the actual array length.
Right. The reference to LENGTH was intended to establish that the
fill pointer governs.
Also be clearer that the start must less than or equal to the end even
if the end was defaulted or NIL.
Good point, thank you.
In the cost to users section, I believe you have a typo, "not" where
you mean "now". This is one of those commonly made unfortunate typos
that reverses the meaning of a sentence.
OOPS. I will double-check that.
∂25-Mar-88 2152 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Mar 88 21:52:08 PST
Received: by labrea.Stanford.EDU; Fri, 25 Mar 88 21:52:42 PST
Received: from bhopal.lucid.com by edsel id AA25619g; Fri, 25 Mar 88 21:49:38 PST
Received: by bhopal id AA00832g; Fri, 25 Mar 88 21:49:33 PST
Date: Fri, 25 Mar 88 21:49:33 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803260549.AA00832@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: WITH-OPEN-STRING-APPEND-STYLE
Issue: WITH-OPEN-STRING-APPEND-STYLE
References: CLtL, pages 331, 386
Category: CLARIFICATION
Edit history: Version 1, 25-Mar-88 JonL
Problem description:
CLtL p386 says that FORMATting to a fill-pointer'd string should add
characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that
WITH-OUTUPUT-TO-STRING will work "as if using VECTOR-PUSH-EXTEND if the
string is adjustable, and otherwise as if using VECTOR-PUSH". It's very
unlikely that the original authors of these parts intended differing
semantics for these two cases. Furthermore, the semantics for
WITH-OUTUPUT-TO-STRING permit the inconspicuous loss of characters
written to the string, since VECTOR-PUSH will just "drop on the floor"
any characters that would go beyond the end.
Proposal (WITH-OPEN-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND):
Change the documentation of WITH-OPEN-STRING-APPEND-STYLE to be like
that under FORMAT. That is, replace the first sentence of the next-to-last
paragraph on CLtL p331 by:
"If *string* is specified, it must be a string with a fill pointer;
the output is incrementally appended to the string (as if by use of
VECTOR-PUSH-EXTEND)."
Test Case:
(let ((str (make-array 4 :element-type 'string-char :fill-pointer 0)))
(with-output-to-string (s str) (princ "You Luz, Bunkie!" s))
str)
CLtL behaviour will return "You "; proposed behaviour will signal an error.
Rationale:
It's unlikely that the mention of VECTOR-PUSH in CLtL p331 was intended
to suggest that characters could be quietly "dropped on the floor". In
any case, there is no practical or theoretical reason to make FORMAT and
WITH-OUTPUT-TO-STRING act differently on non-adjustable strings.
Current Practice:
VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier
versions implement CLtL. The question is entirely moot for Symbolics since
it is impossible to create a non-adjustable string, even upon demand.
Adoption cost:
Zilch.
Benefits:
Less special-casing in the semantics of "printing" to strings.
More conformity with current practice.
Estehtics:
To quote The Great Quux: "Hey, come'on guys, this is FORMAT; there
is no esthetics".
Discussion:
Implementations may want to actually call VECTOR-PUSH, rather than
VECTOR-PUSH-EXTEND, on non-adjustable string in order to test the
result -- nil means an overflow of the total length of the string;
thus they may signal an error more directly related to the problem,
rather than permitting VECTOR-PUSH-EXTEND to complain about a non-
adjustable array. But either way, the semantics is still that of
VECTOR-PUSH-EXTEND: when you get to the end of the string, adjustable
strings are extended, and non-adjustable strings cause error signals.
∂29-Mar-88 0759 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS, version 2
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Mar 88 07:59:37 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Tue, 29 Mar 88 10:57:02 EST
Received: by kali.think.com; Tue, 29 Mar 88 10:56:55 EST
Date: Tue, 29 Mar 88 10:56:55 EST
From: gls@Think.COM
Message-Id: <8803291556.AA17475@kali.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SUBSEQ-OUT-OF-BOUNDS, version 2
Issue: SUBSEQ-OUT-OF-BOUNDS
References: :START and :END arguments (246-247), SUBSEQ (248)
Category: CLARIFICATION
Edit history: 24-Mar-88, Version 1 by Steele
29-Mar-88, Version 2 by Steele, in response to Moon's comments
Problem description:
The descriptions of :START and :END arguments, and of SUBSEQ, do not
explicitly address the question of out-of-bounds indices. (The language on
page 246, "These arguments should be integer indices into the sequence," is
considered too vague on this point.)
Also, the language on page 246 does not make clear whether the prohibition
against "start > end" applies to defaulted values as well as explicit
values, and does not specify clearly whether the default value for the
end argument is the allocated length or the active length.
Proposal (SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR):
Specify that it is an error for the :START argument of any standard
function, or the second argument to SUBSEQ, to be less than zero.
Specify that it is an error for the :END argument of any standard function,
or the third argument to SUBSEQ, to be greater than the active length of
the sequence in question (as returned by LENGTH).
Specify that the start value, after defaulting, must not be greater than
the end value, after defaulting.
Specify that the default value for the end argument is the active length of
the sequence in question.
This may be summarized as follows:
Let X be the sequence within which indices are to be considered. Let S be
the :START argument of any standard function, or the second argument to
SUBSEQ, whether explicitly specified or defaulted, through omission, to
zero. Let E be the :END argument of any standard function, or the third
argument to SUBSEQ, whether explicitly specified or defaulted, through
omission or an explicitly passed NIL value, to the active length of X, as
returned by LENGTH. It is an error if the condition (<= 0 S E (LENGTH X))
is not true.
Test Cases/Examples:
(SUBSEQ "Where's the beef?" -1 5) might be assumed to be "Where" or " Where".
(SUBSEQ "Where's the beef?" -3 -3) might be assumed to be "".
(SUBSEQ "Where's the beef?" 16 18) might be assumed to be "?" or "? ".
(SUBSEQ "Where's the beef?" 10000 10000) might be assumed to be "".
Under this proposal each of these situations is an error, and portable
programs may not rely on their behavior.
Rationale:
We don't want code indexing off the ends of arrays.
Current practice:
KCL interpreted and compiled code signals an error.
Symbolics Common Lisp interpreted and compiled code signals an error; the
compiler also issued an out-of-range warning (possible because the
arguments were all constant).
Lucid Common Lisp interpreted and compiled code signals an error.
Cost to Implementors:
None.
Cost to Users:
Users who depended on some specific implementation behavior in these cases
may find that their pragmatically unportable code is now officially
unportable.
Cost of non-adoption:
Confusion.
Benefits:
Removal of a small but important ambiguity in the spec.
Esthetics:
It seems cleaner not to allow indexing off the end of an array, and
by extension not allow it for any sequence.
Discussion:
This merely clarifies the original intent of the passage on page 246.
∂29-Mar-88 1153 CL-Cleanup-mailer Re: Issue: WITH-OPEN-STRING-APPEND-STYLE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Mar 88 11:53:38 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAR 88 11:47:52 PST
Date: 29 Mar 88 11:47 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: WITH-OPEN-STRING-APPEND-STYLE
In-reply-to: Jon L White <edsel!jonl@labrea.Stanford.EDU>'s message of Fri, 25
Mar 88 21:49:33 PST
To: edsel!jonl@labrea.Stanford.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880329-114752-1361@Xerox>
In the first paragraph under "Proposal" WITH-OPEN-STRING-APPEND-STYLE should be
WITH-OUTUPUT-TO-STRING.
Xerox Common Lisp implements CLtL for WITH-OUTPUT-TO-STRING, but treats FORMAT
consistently, i.e., doesn't complain if you FORMAT off the end of a
fill-pointered, non-adjustable string.
I support this proposal.
-- Andy. --
∂29-Mar-88 1608 CL-Cleanup-mailer Re: Issue SUBSEQ-OUT-OF-BOUNDS, version 2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Mar 88 16:08:53 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAR 88 16:06:52 PST
Date: 29 Mar 88 16:06 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue SUBSEQ-OUT-OF-BOUNDS, version 2
In-reply-to: gls@Think.COM's message of Tue, 29 Mar 88 10:56:55 EST
To: gls@Think.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880329-160652-1908@Xerox>
Xerox Common Lisp implements the proposal, signalling an error in all cases.
I support it.
-- Andy. --
∂29-Mar-88 2140 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Mar 88 21:39:01 PST
Received: by labrea.Stanford.EDU; Tue, 29 Mar 88 21:37:36 PST
Received: from bhopal.lucid.com by edsel id AA11804g; Tue, 29 Mar 88 21:32:48 PST
Received: by bhopal id AA01840g; Tue, 29 Mar 88 21:32:59 PST
Date: Tue, 29 Mar 88 21:32:59 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803300532.AA01840@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
Issue: WITH-OPEN-STRING-APPEND-STYLE
References: CLtL, pages 331, 386
Category: CLARIFICATION
Edit history: Version 1, 25-Mar-88 JonL
Version 2, 29-Mar-88 JonL (fix typos; comments by Daniels)
Problem description:
CLtL p386 says that FORMATting to a fill-pointer'd string should add
characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that
WITH-OUTPUT-TO-STRING will work "as if using VECTOR-PUSH-EXTEND if the
string is adjustable, and otherwise as if using VECTOR-PUSH". It's very
unlikely that the original authors of these parts intended differing
semantics for these two cases. Furthermore, the semantics for
WITH-OUTPUT-TO-STRING permit the inconspicuous loss of characters
written to the string, since VECTOR-PUSH will just "drop on the floor"
any characters that would go beyond the end.
Proposal (WITH-OPEN-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND):
Change the documentation of WITH-OUTPUT-TO-STRING to be like that under
FORMAT. That is, replace the first sentence of the next-to-last paragraph
on CLtL p331 by:
"If *string* is specified, it must be a string with a fill pointer;
the output is incrementally appended to the string (as if by use of
VECTOR-PUSH-EXTEND)."
Test Case:
(let ((str (make-array 4 :element-type 'string-char :fill-pointer 0)))
(with-output-to-string (s str) (princ "You Luz, Bunkie!" s))
str)
CLtL behaviour will return "You "; proposed behaviour will signal an error.
Rationale:
It's unlikely that the mention of VECTOR-PUSH in CLtL p331 was intended
to suggest that characters could be quietly "dropped on the floor". In
any case, there is no practical or theoretical reason to make FORMAT and
WITH-OUTPUT-TO-STRING act differently on non-adjustable strings.
Current Practice:
VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier
versions implement CLtL. For WITH-OUTPUT-TO-STRING, Xerox Common Lisp
implements CLtL. The question is entirely moot for Symbolics since
it is impossible to create a non-adjustable string, even upon demand.
Adoption cost:
Zilch.
Benefits:
Less special-casing in the semantics of "printing" to strings.
More conformity with naive expectations about printing to strings.
Esthetics:
To quote The Great Quux: "Hey, come'on guys, this is FORMAT; there
is no esthetics".
Discussion:
Implementations may want to actually call VECTOR-PUSH, rather than
VECTOR-PUSH-EXTEND, on non-adjustable string in order to test the
result -- nil means an overflow of the total length of the string;
thus they may signal an error more directly related to the problem,
rather than permitting VECTOR-PUSH-EXTEND to complain about a non-
adjustable array. But either way, the semantics is still that of
VECTOR-PUSH-EXTEND: when you get to the end of the string, adjustable
strings are extended, and non-adjustable strings cause error signals.
The proposal is supported by by Andy Daniels of Xerox; and by JonL and
other senior staff at Lucid.
∂08-Apr-88 0951 CL-Cleanup-mailer special var type decls
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Apr 88 09:51:19 PDT
Received: by ti.com id AA28559; Fri, 8 Apr 88 11:49:24 CDT
Received: from dsg by tilde id AA20789; Fri, 8 Apr 88 11:29:46 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 4 Apr 88 13:55:55 CDT
Message-Id: <2785172148-710565@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 4 Apr 88 13:55:48 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Subject: special var type decls
Here's something that the Common Lisp clean-up committee might want to
consider for clarification:
Is the following legal?
(PROCLAIM '(TYPE NUMBER *X*))
(DEFVAR *X*)
(DEFUN FOO ()
(LET ((*X* T))
(DECLARE (TYPE SYMBOL *X*))
(BAR)))
Page 156 of Steele says that a proclamation is "always in force unless
locally shadowed" and page 158 says type declarations "only affect
variable bindings", which might be interpreted to mean that the DECLARE
locally shadows the PROCLAIM. However, that interpretation would make
the global type proclamation useless because it could not be relied on
when compiling a function such as BAR. Consequently I would be inclined
to say that the above example is an error. That still leaves a question
of whether local type declarations for special bindings should be
permitted if they specify a subtype of the globally proclaimed type, or
whether (DECLARE (TYPE ...)) is only meaningful for lexical variables.
Another example of ambiguity regarding global versus local declarations
is that section 9.2 of Steele begins "Here is a list of valid
declaration specifiers for use in DECLARE." What about PROCLAIM? Does
that imply that FTYPE cannot be used in a PROCLAIM since it is not
explicitly mentioned under the PROCLAIM function? On the other hand,
IGNORE doesn't make sense in a PROCLAIM, but it doesn't explicitly say
that it can't be used there.
-- David Gray
∂08-Apr-88 0951 CL-Cleanup-mailer special var type decls
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Apr 88 09:51:30 PDT
Received: by ti.com id AA28563; Fri, 8 Apr 88 11:49:29 CDT
Received: from dsg by tilde id AA20827; Fri, 8 Apr 88 11:30:21 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 4 Apr 88 13:55:55 CDT
Message-Id: <2785172148-710565@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 4 Apr 88 13:55:48 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Subject: special var type decls
Here's something that the Common Lisp clean-up committee might want to
consider for clarification:
Is the following legal?
(PROCLAIM '(TYPE NUMBER *X*))
(DEFVAR *X*)
(DEFUN FOO ()
(LET ((*X* T))
(DECLARE (TYPE SYMBOL *X*))
(BAR)))
Page 156 of Steele says that a proclamation is "always in force unless
locally shadowed" and page 158 says type declarations "only affect
variable bindings", which might be interpreted to mean that the DECLARE
locally shadows the PROCLAIM. However, that interpretation would make
the global type proclamation useless because it could not be relied on
when compiling a function such as BAR. Consequently I would be inclined
to say that the above example is an error. That still leaves a question
of whether local type declarations for special bindings should be
permitted if they specify a subtype of the globally proclaimed type, or
whether (DECLARE (TYPE ...)) is only meaningful for lexical variables.
Another example of ambiguity regarding global versus local declarations
is that section 9.2 of Steele begins "Here is a list of valid
declaration specifiers for use in DECLARE." What about PROCLAIM? Does
that imply that FTYPE cannot be used in a PROCLAIM since it is not
explicitly mentioned under the PROCLAIM function? On the other hand,
IGNORE doesn't make sense in a PROCLAIM, but it doesn't explicitly say
that it can't be used there.
-- David Gray
∂08-Apr-88 2242 CL-Cleanup-mailer floating point questions
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Apr 88 22:42:47 PDT
Received: by labrea.Stanford.EDU; Fri, 8 Apr 88 21:42:13 PST
Received: from bhopal.lucid.com by edsel id AA10628g; Fri, 8 Apr 88 22:35:20 PDT
Received: by bhopal id AA08201g; Fri, 8 Apr 88 22:36:11 PDT
Date: Fri, 8 Apr 88 22:36:11 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804090536.AA08201@bhopal.lucid.com>
To: chapman%lisp.DEC@decwrl.dec.com
Cc: edsel!jonl@labrea.Stanford.EDU, cl-cleanup@sail.stanford.edu
In-Reply-To: chapman%lisp.DEC@decwrl.dec.com's message of Fri, 8 Apr 88 07:23:21 PDT <8804081423.AA17359@decwrl.dec.com>
Subject: floating point questions
re: Dick reviewed my snapshot draft of the standard and suggested I talk to you
about floating point number representation. . . . Do you have other
thoughts on how floating point data types should be specified/implemented?
I don't see any clean-up proposals that have to do with this topic, just
the LEAST-POSITIVE-<mumble>-FLOAT communication.
There are three problems of concern that I know about:
First, for purposes of CLOS, it is very inconvenient to have sub-range
types for any numerical type. In one sense, the short-float, single-float,
double-float, and long-float types are sub-ranges of float; and the thorny
issue is that that there are three possible variations one how they are
merged. I don't know how to solve this one, except by ignoring the
existence of differing float types [and there is probably at least one or
two manufactures who will fight that to the hilt, since they have optimized
one extreme end or the other and perhaps see this distinction as a
"competitive edge"]. I *could* make a case for having only FLOAT as a
Common Lisp type, leaving to the vendors the issue of foisting distinctions
off on to the user [since in many cases, the distinctions will be irrelevant].
Very briefly, the three main points of this case are
(1) As a standard, CLtL p16-17 guarantees virtually nothing about what
single-float, double-float etc. mean; in one implementation, single
could mean a 23-bit mantissa, and in another it could mean a 96-bit
mantissa. Hence there is no guarantee of portability, so why bother?
(2) A recent survey of some numerical analysts, in a company dedicated
to selling Fortran engines, discovered the all-too-obvious fact that
many many algorithms are numerically unstable when run under the IEEE
32-bit format, but are quite well-behaved under the 64-bit format;
but interestingly, it turned up *no* cases of ill behaviour in the
64-bit mode that were correctible by going to a 128 bit format.
[Now, this is not the same as an "ill conditioned" problem]. In short,
there is a "good enough" size -- larger isn't needed, and smaller
could be justified only ocasionally by savings in space and/or time.
(3) On most machines, there seems to be a "preferred" format. In fact,
I'm aware of some hardware where single-float operations are a tad
slower than double-float ones; the driving motivation is that the
numerical analysts wanted the fastest possible floating point of
"good enough" size, and the other sizes were supported only for
"compatibility". Also, compact representations inside arrays
provide the only intesting space savings; this is quite analogous
to packed arrays of integers [e.g., an array element-type of
(signed-byte 8)]
[Since a larger group is being cc'd, I'd like to appeal to that group *not*
to flood the mailing list with lots of trivial counterexamples to each of
the above generalizations. I'm sure they've all been thought of before;
and since the status quo will remain until an actual proposal is made,
there is no need to argue against a non-proposal. If anyone would like
to contact me privately about pursuing such a proposal, I will respond;
but so far, I haven't seen much interest].
Second, some implementations permit "extremals" to be representable numbers,
and others don't; e.g., the IEEE standard allows for "denormalized" and
"infinity" numbers, while VAX and IBM/370 don't. So the question arises
as to just what "least-positive-<mumble>-float" means; is it the smallest
possible representation, or is it the smallest "normal" representation?
Paul Hilfinger (at Berkeley) feels rather strongly that is should be
the smallest possible representation; but now that raises the issue that
on some implementatons, "least-positive-<mumble>-float" is a perfectly
normal number causing no exceptions whatsoever, while on others it will
cause an "underflow" type trap whenever it is produced (unless you turn
off trapping, and yes, "gradual underflow" really is "underflow"). About
the best consensus I could get was to follow Symbolics lead and add the
names "least-positive-normalized-<mumble>-float", so that there would be a
portable way of dealing with the smallest reasonable number. Also:
(eql least-positive-<mumble>-float least-positive-normalized-<mumble>-float)
could be used as a test to determine whether or not the implementation
supports denormalized numbers.
A possible third trouble is with "most-positive-<mumble>-float" -- should
this be the largest reasonable number, or the largest possible representation?
If the latter, then in the IEEE format, the positive infinity should be
"most-positive-<mumble>-float" since it certainly is larger than any other
float. By analogy with the difference between "least-positive-..." and
"least-positive-normalized-...", I would have liked to see "most-positive-..."
and "most-positive-normalized-..."; that way, the test
(= most-positive-<mumble>-float most-positive-normalized-<mumble>-float)
could be used to determine whether or not the implementation supports
infinities. But alas, I couldn't convince QUUX (Guy Steele) about this one,
so I'm not sure it's worth wasting any more time over.
-- JonL --
∂10-Apr-88 1509 CL-Cleanup-mailer Issue: REST-ARGUMENT-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Apr 88 15:09:34 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 379386; Sun 10-Apr-88 18:09:16 EDT
Date: Sun, 10 Apr 88 18:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REST-ARGUMENT-EXTENT
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM,
Hornig@ALDERAAN.SCRC.Symbolics.COM,
PRobertson@MEAD.SCRC.Symbolics.COM, Laddaga@MEAD.SCRC.Symbolics.COM
Message-ID: <880410180905.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I wrote the following "straw man" proposal mostly because I'm tired of
seeing the incessant mail on Common-Lisp about this topic and I'm hoping
we can quickly work toward having something to push back at the
Common-Lisp community to appease them on this obviously important issue.
I expect that this will go through a few iterations before the form and
content settle down, but I just wanted to get something concrete (straw?)
on our table...
-----
Issue: REST-ARGUMENT-EXTENT
References: 5.2.2 Lambda Expressions (pp59-66)
Category: ADDITION
Edit history: 10-Apr-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Currently, all lists created for use with the &REST syntax in lambda lists
have indefinite extent. Many users have complained that this is not always
necessary and often creates unnecessary garbage.
Proposal (REST-ARGUMENT-EXTENT:GENERAL)
Introduce a DYNAMIC-EXTENT declaration such that
(DECLARE (DYNAMIC-EXTENT variable))
would permit the implementation to make the list held by the indicated
VARIABLE to have only dynamic extent.
Example: (DEFUN FOO (&REST L)
(DECLARE (DYNAMIC-EXTENT L))
(APPLY #'BAR L))
Rationale:
This would allow the programmer to declare general information about
data flow which it might be difficult or impossible for a compiler to
obtain mechanically.
Proposal (REST-ARGUMENT-EXTENT:CONSERVATIVE)
Introduce a DYNAMIC-EXTENT declaration such that
(DECLARE (DOWNWARD-REST-ARGUMENT))
would permit the implementation to make the list held by the rest argument
to the immediately containing binding form have only dynamic extent. It would
be an error if the immediately containing binding form did not have an
&REST specifier to which this declaration could apply.
Example: (DEFUN FOO (&REST L)
(DECLARE (DOWNWARD-REST-ARGUMENT))
(APPLY #'BAR L))
Rationale:
This would allow the programmer to declare specific information about
rest argument data flow which it might be difficult or impossible for
a compiler to obtain mechanically, but would not attempt to treat the
more general issue of how this related to other kinds of data flow.
Current Practice:
Lucid implements REST-ARGUMENT-EXTENT:GENERAL [at least for rest arguments;
I don't know if they attach a meaning to its use for any other arguments. -kmp]
Symbolics Cloe implements REST-ARGUMENT-EXTENT:CONSERVATIVE.
Cost to Implementors:
Since implementations are only allowed (and not required) to make any use
of this declaration, there is no forced cost. In practice, though, some
users will probably get irritated if implementations fail to do something
useful with this declaration, so some implementors may end up having to pay
even if they don't technically have to.
Fully implementing even dynamic rest lists (let alone dynamic objects of
all kinds or for other data flow paths, whatever that may mean) may not be
a small change in some implementations. There is possible interaction with
garbage collection, possible implications on hidden assumptions in code
generation for stack winding and unwinding, TYPEP, etc. depending on how the
details of how dynamic lists end up being implemented.
Cost to Users:
None. This is an upward-compatible change for users.
Many users are already exploiting this feature in an implementation-dependent
way, so this change will improve the maintainability of code for those
implementations and may encourage some new implementations to offer equivalent
functionality.
Cost of Non-Adoption:
Some users will continue to be discouraged with implementations that do
"gratuitous heap consing" of rest lists.
Benefits:
Many implementors claim that large improvements in the performance of programs
(and their associated garbage collection) are to be had from adopting some form
of proposal such as this.
Aesthetics:
Debugging program errors involving dynamic extent objects can be very tricky.
This feature should be strongly discouraged for naive programmers.
Discussion:
The example above is perhaps not the best example because APPLY is something
the compiler can have primitive knowledge about, and good compilers may in fact
already optimize this case even without the need for a user declaration.
Nevertheless, if the function were MY-APPLY rather than APPLY, the case would
be made because (non-block) compilers cannot make assumptions about what
MY-APPLY would do without violating the normal rules for modular compilation.
KMP supports REST-ARGUMENT-EXTENT:CONSERVATIVE pending discussion of why
REST-ARGUMENT-EXTENT:GENERAL is not overkill.
∂11-Apr-88 0831 CL-Cleanup-mailer Issue: REST-ARGUMENT-EXTENT
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 11 Apr 88 08:31:32 PDT
Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 184615; Mon 11-Apr-88 11:31:03 EDT
Date: Mon, 11 Apr 88 11:31 EDT
From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: REST-ARGUMENT-EXTENT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, CL-Cleanup@SAIL.STANFORD.EDU
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, PRobertson@MEAD.SCRC.Symbolics.COM,
Laddaga@MEAD.SCRC.Symbolics.COM
In-Reply-To: <880410180905.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880411153115.5.HORNIG@WINTER.SCRC.Symbolics.COM>
I favor REST-ARGUMENT-EXTENT:GENERAL. In its current form it can
replace use of WITH-STACK-LIST, which I consider a major improvement.
Extended slightly to apply to other aggregates, it could replace
STACK-LET, another simplification.
Things to consider:
Should there be a form of this that makes the same guarantees about all
levels of structure? This would allow building trees with dynamic
extent.
It might be nice to have a form analogous to the use of THE with type
declarations for this declaration.
∂11-Apr-88 1032 CL-Cleanup-mailer Re: Issue: REST-ARGUMENT-EXTENT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Apr 88 10:32:11 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 APR 88 10:24:35 PDT
Date: 11 Apr 88 10:23 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REST-ARGUMENT-EXTENT
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Sun, 10 Apr 88 18:09 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM,
Hornig@ALDERAAN.SCRC.Symbolics.COM, PRobertson@MEAD.SCRC.Symbolics.COM,
Laddaga@MEAD.SCRC.Symbolics.COM
Message-ID: <880411-102435-11763@Xerox>
I find the distinction between parameters and arguments useful enough to want to
change the name of this issue. The &REST parameter is bound to a list containing
the rest of the arguments; the issue is not the extent of the argument but
rather REST-PARAMETER-VALUE-EXTENT, or, more concicely although more
ambiguously, REST-LIST-EXTENT.
As a feature to be added to the standard, this proposal is fairly weak: it adds
an optional declaration which exists in some implementations. For
implementations that do not already have this feature, is this the "optimal"
feature to add? For example, should it instead be the case that we might allow
the rest parameter to be bound to a vector (as JonL has suggested?).
Note that there is a related issue, currently named REST-LIST-ALLOCATION, which
addresses the ambiguity over whether rest lists are shared in the case where
APPLY is used. I think we do have some obligation to resolve ambiguities in the
current specification before going on to add (optional) features.
∂12-Apr-88 0347 CL-Cleanup-mailer Issue: REST-ARGUMENT-EXTENT
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Apr 88 03:47:35 PDT
Received: by labrea.Stanford.EDU; Tue, 12 Apr 88 02:47:03 PST
Received: from bhopal.lucid.com by edsel id AA23917g; Tue, 12 Apr 88 03:36:41 PDT
Received: by bhopal id AA18246g; Tue, 12 Apr 88 03:37:44 PDT
Date: Tue, 12 Apr 88 03:37:44 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804121037.AA18246@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu,
Moon@stony-brook.scrc.symbolics.com,
Hornig@alderaan.scrc.symbolics.com, PRobertson@mead.scrc.symbolics.com,
Laddaga@mead.scrc.symbolics.com
In-Reply-To: masinter.pa@Xerox.COM's message of 11 Apr 88 10:23 PDT <880411-102435-11763@Xerox>
Subject: Issue: REST-ARGUMENT-EXTENT
I generally agree with your assessment, Larry, although I am pessimistic
about bringing up &rest vectors again -- a *lot* of code already exists
in the Common Lisp world which assumes that the &rest parameter is bound
to a list.
On the other hand, while Kent may have noticed the large number of messages
sent recently to Common-Lisp@sail on this topic, but I wonder if he read
them? The overwhelming majority of them concerned user disatisfaction with
the unexpected "sharing" of rest lists -- our issue REST-LIST-ALLOCATION. As
Gail Z put it so succinctly -- if the CL spec can't get its act together to
guarantee non-sharing in &rest lists, then there *must* be some construct
added to the language so that the discerning user can prevent it. In my
message to Common-Lisp@sail of 8 Apr 88 01:00:38 PDT I quoted her:
Gail Zacharias talked about the common idiom of simply doing a COPY-LIST on
every &rest argument, to insure some normalcy. Her reasoning seems, to me,
to bolster the case for those who claim that that CL semantics are deficient
Subject: &REST Lists
Date: 24 Mar 88 12:23:15 EST (Thu)
From: gz@spt.entity.com (Gail Zacharias)
. . .
If Common Lisp doesn't require unshared &rest lists, then I think
it must provide a declarative version of this idiom so the COPY-LIST can
be portably avoided when it's redundant. Seems to me that the fact that
this is a common case where users find a need for conditionalization
indicates a real deficiency in Common Lisp's specification.
. . .
Of course, the problem isn't only the sharing of &rest lists, but the more
common flaw that they may, unannouncedly, have dynamic extent. By this, I
mean the bug where a stack-allocated &rest list can creep out into global
data structures, even though it will surely disappear when the frame that
created it returns. Allegedly, Symbolics is going to fix this bug in their
next release (and TI may have already fixed it?); but we are now five years
beyond the first CL specification!
So as you say, we have a responsibility to resolve the very thorny issue
of REST-LIST-ALLOCATION.
On the other hand, since CL semantics already requires indefinite extent
for &rest values, and since Symbolics has been in violation of this part
for so many years, *** and because a subset of users find dynamic extent
extremely userful *** then I don't think it would hurt all that much
to bless the effort to standardize the syntax for asking for it.
-- JonL --
P.S.: When I questioned whether Kent read the messages sent to Common-Lisp
mailing list, there was no intent to question his mental compotence.
Some months back he defended the dumping of a Symbolics internal
discussion onto the CL-Cleanup mailing list by saying that he refused
to read the allegedly voluminous Common-Lisp mails, and thus couldn't
carry on the discussion there.
∂13-Apr-88 1331 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 13 Apr 88 13:31:19 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA03781; Wed, 13 Apr 88 16:31:20 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA00868; Wed, 13 Apr 88 16:32:28 EDT
Message-Id: <8804132032.AA00868@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: FORMAT-PRETTY-PRINT (version 1)
Date: Wed, 13 Apr 88 16:32:26 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Sorry, I've been sitting on this one for a while.
Issue: FORMAT-PRETTY-PRINT
References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 3/4/88
Status: For Internal Discussion
Problem description:
The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively. The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.
Proposal (FORMAT-PRINT-PRETTY:YES):
The ~A and ~S FORMAT operators (and the ~B, ~D, ~E, ~F, ~G, ~$, ~O,
~R, and ~X FORMAT operators when they encounter a non-numeric value)
are required to treat all *PRINT-foo* variables the same as PRINC and
PRIN1 respectively. [[ Yes, this is a bit broader than the title, but
if we're going to clarify this we might as well do the whole job. I
don't think any of the other variables are likely to be controversial.]]
Test Cases/Examples:
(LET ((TEST '(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL TEST TEST))
This should print four copies of the above lambda expression. The
first pair should appear identical and the second pair should appear
identical. The only difference between the two pairs should be the
absence of string quotes in the second pair. Note that this example
won't work as written if the proposal FUNCTION-TYPE:STRICT-REDEFINITION
is accepted.
Rationale:
FORMAT should interact with the *PRINT-foo* variables in a predictable
way. This proposal is one of the two simplest possible definitions
and provides the most flexibility to the user.
Current practice:
Ibuki Lisp obeys the binding of *PRINT-PRETTY*. Lucid Common Lisp
always applies ~A and ~S with *PRINT-PRETTY* bound to NIL.
Cost to Implementors:
While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications. How does a pretty-printing ~A
interact with MINCOL, etc? How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?
Cost to Users:
Truely portable code shouldn't be affected because existing
implementations are inconsistent. Despite this, there are probably a
number of user programs in non-complying which will have to change
whichever way this is decided.
Cost of non-Adoption:
The interaction of FORMAT and the *PRINT-foo* variables (especially
pretty printing) will remain undefined. This will continue to make
portable Common Lisp programming harder than it need be.
Benefits:
Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.
Aesthetics:
The interaction between two related parts of output will be clarified
in a simple way.
Discussion:
Pierson feels that this is important because the ease of implementing
major system interfaces with FORMAT can unintentionally lead to less
flexibility for the user compared to an old-style PRIN1/PRINC/TERPRI
implementation. This clarification would generate some up front work
but would make it harder for people to accidentally create restrictive
interfaces.
∂13-Apr-88 1334 CL-Cleanup-mailer [Jim McDonald: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)]
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 13 Apr 88 13:34:39 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA03790; Wed, 13 Apr 88 16:34:43 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA00898; Wed, 13 Apr 88 16:35:51 EDT
Message-Id: <8804132035.AA00898@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: [Jim McDonald: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)]
Date: Wed, 13 Apr 88 16:35:45 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Jim asked me to forward this to the cleanup committee a while ago. I
think that it has some interesting ideas, but delves too much into
specifying implmentation for standards proposal.
------- Forwarded Message
Return-Path: @multimax.ARPA:edsel!jlm@labrea.Stanford.EDU
Received: from multimax.ARPA by mist.UUCP (3.2/4.7)
id AA23038; Wed, 2 Mar 88 10:00:47 EST
Received: by multimax.ARPA (5.51/25-eef)
id AA15330; Wed, 2 Mar 88 10:00:47 EST
Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 12:37:31 PST
Received: from bhopal.lucid.com by edsel id AA06372g; Tue, 1 Mar 88 11:47:41 PST
Received: by bhopal id AA05626g; Tue, 1 Mar 88 11:53:43 PST
Date: Tue, 1 Mar 88 11:53:43 PST
From: Jim McDonald <edsel!jlm@labrea.Stanford.EDU>
Message-Id: <8803011953.AA05626@bhopal.lucid.com>
To: pierson@multimax.arpa
In-Reply-To: Dan L. Pierson's message of Mon, 29 Feb 88 18:55:14 EST <8802292355.AA19855@mist.UUCP>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)
Cc: edsel!eb@labrea.Stanford.EDU, edsel!jonl@labrea.Stanford.EDU,
edsel!lnz@labrea.Stanford.EDU, edsel!kdo@labrea.Stanford.EDU
Dan -- you might want to consider these comments I drafted a few weeks
ago. They're not quite in proposal format (the header is just for
your reference), but if you like the sense of this I can clean it up.
I think this is basically a generalization of your proposal (or at
least is more open-ended):
- -----
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by McDonald 3/01/88
Status: For Internal Discussion
A number of primitive streams are instantiated when lisp starts
(via the function primitive-streams), and the results of that
function are then used to build the higher level streams seen by
users.
- ------
primitive-streams &optional create-streams-p [function]
If create-streams-p is true, creates and opens primitive streams in
an implementation-dependant manner. Data associated with any
previously existing streams may be lost, and the effects of previous
calls to add-primitive-stream and delete-primitive-stream may be
lost. Normally, create-streams-p will be true for just a single
call made when lisp starts.
Always returns a list of triples of the form:
(<keyword> <input-stream or nil> <output-stream or nil>).
The following triples must be included in this list, but more are
allowed, and various of the stream objects may be eq:
((:terminal-input #<input-stream> nil)
(:terminal-output nil #<output-stream>)
(:standard-input #<input-stream> nil)
(:standard-output nil #<output-stream>)
(:error-output nil #<output-stream>)
(:query-input #<input-stream> nil)
(:query-output nil #<output-stream>))
It is an error to destructively modify this list or any of the
triples within it. Different calls to primitive-streams are free to
return eq lists or not, as convenient.
- ------
add-primitive-stream (keyword input-stream-or-nil output-stream-or-nil)
Causes a three element list of the arguments to be prepended to the
list of triples returned by subsequent calls to (primitive-streams).
Signals an error if the first argument is not a keyword, if the
second argument is not nil or an input-stream, or if the third
argument is not nil or an output-stream.
Returns NIL.
Note that this can be used to "shadow" :terminal-input, etc.
- ------
delete-primitive-stream (keyword)
The first triple starting with keyword which would otherwise have
been returned by (primitive-streams) will no longer appear in the
list of triples returned by (primitive-streams).
Signals an error if the argument is not a keyword.
Returns the triple which is deleted, or NIL if none existed, or
:ERROR if the triple selected may not be removed.
Note that this can be used to remove shadowing triples for
:terminal-input, e.g., but not all triples for it.
- ------
During lisp startup, two forms are executed:
(primitive-streams t)
(initialize-stream-variables)
Initialize-stream-variables is defined by default as follows, but
implementations and/or users, applications, etc., can redefine it or
simply reset or rebind the stream variables as they choose.
(defun initialize-stream-variables ()
(let ((primitive-streams (primitive-streams)))
(setq *terminal-io*
(make-two-way-stream
(second (assoc :terminal-input primitive-streams))
(third (assoc :terminal-output primitive-streams))))
(setq *standard-input*
(second (assoc :standard-input primitive-streams)))
(setq *standard-output*
(third (assoc :standard-output primitive-streams)))
(setq *error-output*
(third (assoc :error-output primitive-streams)))
(setq *query-io*
(make-two-way-stream
(second (assoc :query-input primitive-streams))
(third (assoc :query-output primitive-streams))))
))
- ------
Rather than mandating portability via some least common denominator,
this proposal makes stream initialization more of an open system, easy
to tailor to individual situations.
The rules are also intended to enable user code to be able to restore
*terminal-io*, *standard-input*, *standard-output*, *error-output*,
and *query-io* to reasonable values, even if all of them have been
set to NIL or other undesirable values.
The functional interface to the triples is designed to discourage
random tampering with sensitive data.
------- End of Forwarded Message
∂17-Apr-88 1740 CL-Cleanup-mailer FORMAT-PRETTY-PRINT
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 17 Apr 88 17:39:58 PDT
Date: 17 Apr 1988 20:38-EDT
Sender: MATHIS@A.ISI.EDU
Subject: FORMAT-PRETTY-PRINT
From: MATHIS@A.ISI.EDU
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]17-Apr-88 20:38:31.MATHIS>
we should include Dick Waters at MIT on this one, but I don't
have his address in front of me right now. -- Bob
∂26-Apr-88 2114 CL-Cleanup-mailer miscellaneous questions about declarations and type specfiers
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Apr 88 21:14:34 PDT
Received: by labrea.Stanford.EDU; Tue, 26 Apr 88 21:14:38 PDT
Received: from bhopal.lucid.com by edsel id AA12440g; Tue, 26 Apr 88 19:57:24 PDT
Received: by bhopal id AA03767g; Tue, 26 Apr 88 19:59:27 PDT
Date: Tue, 26 Apr 88 19:59:27 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804270259.AA03767@bhopal.lucid.com>
To: goldman@vaxa.isi.edu
Cc: common-lisp@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: goldman@vaxa.isi.edu's message of Tue, 26 Apr 88 13:27:25 PDT <8804262027.AA08691@vaxa.isi.edu>
Subject: miscellaneous questions about declarations and type specfiers
re: 1)is there any portable way to obtain the expansion of a type
specifier (FOO ...), given that FOO was defined by
(deftype FOO ...)
I don't think so. Sounds reasonable enough though -- I'll put it on my
personal list of items which ought to be submitted to the X3J13 Cleanup
committee for consideration. [I already have 7 or 8 issues relating
to the type system]
2) is there any portable way to ask if DEC is a legitimate declaration
specifier in an implementation (including the possibility that DEC
has been legitimized with
(PROCLAIM '(DECLARATION DEC))
Again I don't think so. Maybe this ought to go in with a proposal for some
functions that will query the global database relevant to proclamations and
declarations (e.g., has a particular variable been proclaimed special? what
is the current global settings of the OPTIMIZE qualities? and so on.)
3) is there any portable way to ask if a symbol or list S is a legitimate
type specifier in an implementation?
Guy Steele circulated several pages of "Clarifications" in December 1985,
in which he proposed adding a function TYPE-SPECIFIER-P. I don't see it
on the current agenda of the X3J13 Cleanup committee; consequently it has
been on my personal list of items that ought to be submitted "soon"
-- JonL --
∂13-May-88 0236 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 13 May 88 02:36:31 PDT
Received: by labrea.stanford.edu; Fri, 13 May 88 02:23:56 PDT
Received: from bhopal.lucid.com by edsel id AA11362g; Fri, 13 May 88 02:15:28 PDT
Received: by bhopal id AA25649g; Fri, 13 May 88 02:18:34 PDT
Date: Fri, 13 May 88 02:18:34 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805130918.AA25649@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Problem description:
The distinction between type-specifiers "for declaration" and "for
discrimination" is made only for array type specifiers -- those that are
subtypes of ARRAY. Discussion on the Common Lisp electronic mailing list
in late 1987 and January 1988 shows that many people are confused by this
one-of-a-kind situation. This may be one of the more insidious flaws
in the current CL design.
A consequence of this "flaw" is that a variable declared to be of type
<certain-type>
and all of whose assigned objects are created in accord with that type,
still may have *none* of its values ever satisfied by the TYPEP predicate
with that type-specifier. One type-specifier with this property in most
implementations of CL is <certain-type> = (ARRAY (SIGNED-BYTE 5)).
An array created with this type specifier will, depending on the vendor,
either be of typep (ARRAY (SIGNED-BYTE 8)) or (ARRAY T); but (almost)
never of typep (ARRAY (SIGNED-BYTE 5)).
It would be much simpler if the real source of the problem that led to
this split up could be resolved. Two proposals will be offered, each
rejecting this odd distinction, but in different ways. Because there
are two proposals, some of the common discussion has been moved up
into the problem description part.
No one seems to remember just exactly why this "warp" was put into Common
Lisp in the first place; possibly it was added in a mistaken belief that
it would promote portability. ["Mistaken", because the source of non-
portability is the permission to upgrade; if two different implementations
do any upgrading differently, then the effect will be the same kind of
non-portability that results when two different implementations set the
boundary between fixnums and bignums differently.]
A common feeling among Common Lisp users is that the set of type-specifiers
forms a mathematical language, and the SUBTYPEP relation is generated by some
basic, generating set of relations between these names. People want to see
this language actually describing the implementation in which it is running
-- that the objects of the implementation are a model for that language --
rather than seeing it be limited to some theoretical model which no vendor
bothers to implement. Hence, typep and subtypep should be changed to
reflect what kinds of arrays get built; alternatively, make-array should
be changed to exhibit the distinctions that typep makes.
One possibility for unification arises from focusing on type specifiers
as names for collections of objects, and on SUBTYPEP as a kind of "subsetp"
for collections of objects.
-- The second paragraph of page 11 makes it clear that "data types" are
just sets of objects; subsequent discussion makes it clear that the
second argument to TYPEP (a type specifier) is a name for some such
set, and that there may be several distinct names specifying the same
set (or type). The first paragraph of section 6.2.1 on page 72 says
that TYPEP is a set membership test, and SUBTYPEP is a subset test.
-- The first two paragraphs of section 4.5, on page 45, describe a
permission for what may be called "element-type upgrading" on arrays;
the documentation for ARRAY-ELEMENT-TYPE on page 291 also makes it
clear that a conforming implementation is permitted to "collapse"
array element types into some more limited set of types, providing
that the array returned by make-array is at most an "upgrade". The
array types STRING and BIT-ARRAY are excluded from upgrading.
For example, depending on how primitive arrays are actually implemented,
(make-array <dims> :element-type '(signed-byte 5))
and
(make-array <dims> :element-type '(signed-byte 8))
might legitimately create arrays specialized to hold exactly the same set of
objects. The only constraint seems to be that that (array (signed-byte 8))
be the most specific type *** in that implementation *** which can hold
all the arrays made by (make-array <dims> :element-type '(signed-byte 5) ...).
In this case, we say that the array element type has been upgraded from
(signed-byte 5) to (signed-byte 8), and we imply that there is no particular
special provisions for arrays of element type, say, (signed-byte 6).
By the bulletted paragraphs above, (array (signed-byte 5)) and
(array (signed-byte 8)) are in fact names for exactly the same
set of objects.
However pages 45 and 46 go at length to specify that these two different
names for the same set of objects must be treated differently by TYPEP
and SUBTYPEP. This seems to "warp" the utility of TYPEP since it puts
it at variance with the fundamental principle: "SUBTYPEP means subsetp".
To get a sense of how the community is "confused", see the arpanet
mailing list for Common Lisp, in a series of exchanges started on
Thu, 17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
under the subject line of "Types in CL". Also see the exchange started
Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
under the subject line of "TYPEP warp implications"
[Notation: because of the inability to show meta- or linguistic variables
in a different typeface, some code examples will use a backquote format;
a form like ",x" will simply mean "substitute the value of x here".
and a form like `(...) will simply mean "evaluate this first, doing
the indicated comma substitutions." Also, the term "type-equivalent"
will be used to denote two types which are each subtypes of the other;
this relation establishes a partition on the set of type-specifiers
into disjoint sets, and members of the same equivalence class are
simply different names for the same type.]
One interesting krinkle in this issue is the question as to whether two
non-EQ but type-equivalent type-specifiers ,aet-x and ,aet-y could give
rise to different array types. Remember that `(array ,aet-x) and
`(array ,aet-y) are type-equivalent only if ,aet-x is type-equivalent
to ,aet-y. But this doesn't say anything about the reverse implication:
does ,aet-x being type-equivalent to ,aet-y necessarily imply that
`(array ,aet-x) is type-equivalent to `(array ,aet-y)? For example,
consider SHORT-FLOAT and SINGLE-FLOAT in an implementation where these
are type-equivalent (because only one internal float type is provided for
Lisp objects -- see CLtL section 2.1.3). One may desire to implement
(ARRAY SHORT-FLOAT) and (ARRAY SINGLE-FLOAT) differently; say, for example
that the former is packed into 16-bit half-words, whereas the latter is
packed into 32-bit words. But for either kind of packing, the result of
AREF is an ordinary "single-float"; the whole point is merely to specify
a packing technique for "packed float" arrays.
Test case:
Let aet-x and aet-y be two distinct type specifiers that are definitely
not type-equivalent in a given implementation, but for which make-array
will return an object of the same primitive type; let this primitive
type be described by `(array ,aet-y). This will be an implementation
dependent search, but in every implementation that the present writer
(JonL) has tested, there will be some such types; often, (signed-byte 5)
and (signed-byte 8) will work. Thus in each case, it should be true that:
(array-element-type (make-array 0 :element-type ',aet-x)) ==> ,aet-y
(array-element-type (make-array 0 :element-type ',aet-y)) ==> ,aet-y
and if such a function exists, then:
(upgrade-array-element-type ',aet-x) ==> ,aet-y
(upgrade-array-element-type ',aet-y) ==> ,aet-y
Now for a first set of tests; to eliminate the distinction between "for
declaration" and "for discrimination" both of the following should be true:
[A]
`(typep (make-array 0 :element-type ',aet-x)
'(array ,aet-x))
`(typep (make-array 0 :element-type 'aet-y)
'(array ,aet-y))
Since `(array ,aet-x) and `(array ,aet-y) are different names for exactly
the same set of objects -- those arrays specialized to hold elements of
type aet-y -- then if the correlation between type-names and sets of objects
is being observed, these names should be type-equivalent. That means that
both of the following tests should be true:
[B]
`(subtypep '(array ,aet-x) '(array ,aet-y))
`(subtypep '(array ,aet-y) '(array ,aet-x))
Additionally, to show that un-equivalent type-specifiers that are upgraded
to the same "element type" should be equivalent as element-type specifiers,
then both the following type tests should be true:
[C]
`(typep (make-array 0 :element-type ',aet-y)
'(array ,aet-x))
`(typep (make-array 0 :element-type ',aet-x)
'(array ,aet-y))
Proposal (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
-- Delete all the documentation that suggests the :element-type argument
to make-array might not be a satisfactory element-type in the type
specifier for the kind of array produced. Particularly, delete the
documentation that permits a difference between type-specifiers "for
declaration" and "for discrimination; primarily this means parts
of the discussion in CLtL, section 4.5, p. 45 and 46. Include a
statement that `(array ,aet) is a suitable type-specifier for the
array made by `(make-array <dims> :element-type ',aet ...).
-- Change the documentation of ARRAY-ELEMENT-TYPE, CLtL p. 291 by deleting
the sentence begining "This set may be larger than the set requested
when the array was created; for example . . ."
-- Introduce a function UPGRADE-ARRAY-ELEMENT-TYPE, which will reveal how
a particular :element-type argument to make-array will be treated.
Semantically, this would be equivalent to:
(defun upgrade-array-element-type (element-type)
(array-element-type (make-array 0 :element-type element-type)))
but it wouldn't have to cons up the 0-element array first. Also,
the presence of this name, as a documented function in the language,
would serve notice that "upgrading" is an important aspect of any real
implementation of CL arrays.
-- Change TYPEP (and SUBTYPEP) so that `(typep x '(array ,aet)) is true
if and only if `(typep x '(array ,(upgrade-array-element-type aet)))
is true.
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and "for
discrimination".
Current Practice:
Every vendor's implementation that the present writer has queried does
some amount of non-trivial "upgrading" [generally, using (signed-byte 5)
as an :element-type argument to make-array will show it]; this includes
LUCID, VAXLISP, SYMBOLICS, FRANZ, and XEROX. Most implementations fail
tests [A] and [C] part 1, but pass tests [A] and [C] part 2; this is a
consequence of implementing the distinction between "for declaration" and
"for discrimination". Lucid and Xerox both pass test [B], and the other
vendors fail it [it may be that these two vendors have implemented a
partial solution for subtypep, with a view to future extensions.]
Adoption Cost:
Typically, a small amount of work will be required in every vendor's
implementation of TYPEP and SUBTYPEP; some vendors may have already
done the work, but not fully integrated it.
Benefits:
It will greatly reduce confusion in the user community; the fact that
(make-array <n> :element-type '<aet>) frequently is not of type (array <aet>)
has been very confusing to almost everyone. That is, in practice,
the distinction between "for declaration" and "for discrimination" has
been a disaster.
Conversion Cost:
Because of the prevalence of confusion in this area, it seems that no
user code will have to be changed. In fact, it is more likely that
some of the vendors will cease to get bug reports about some array
that didn't seem to be of "the obvious type".
Esthetics:
Discussion:
Many persons are in favor of the permission to upgrade; but they would not
like to see CL become a language like C where there are a prescribed set of
kinds of arrays that must be implemented (e.g, "int", "long int", "single",
"double" etc), and no others can exist. In short, no one would not want to
gain portability at the expense of limiting the language to the architectural
features of the hardware on which it was first implemented.
Many senior implementors at Lucid favor this proposal. In network mail
"Date: Sat, 9 Jan 1988 15:54 EST" Rob McLaughlin favored the gist of this
proposal -- namely that upgrading should be continued, and that TYPEP should
be fixed. Here is an excerpt of his words:
There are two obvious solutions, one of which has already been proposed:
-- Make the mapping more direct. Eliminating "array element type
upgrading" would be an instance of this.
-- Make the mapping explicitly ill-defined in a more useful way.
I think we need to do the latter because the former won't work. I don't
see how to eliminate "array element type upgrading" without creating
more problems [than] we solve. . . .
My conclusion is that it isn't array types that are wrong, it is the
understanding of the meaning of TYPEP that is wrong.
One possible criticism of this proposal is that it hinders portability by
exposing an implementation dependent facet, namely the "upgrading" function.
But the kind of portabililty achieved by a programmer ignorant of the
realities of array implementations -- that only a finite number of
type classes are really implemented efficiently in any particular
CL implementation -- would be a very pyrrhic victory to say the least.
The kinds of attention a programmer would have to pay to these array type
boundaries is the same kind of attention he now has to pay to the
fixnum/bignum boundary (i.e., arithmetic that is doable in unit time,
and that which requires tens to hundreds of units of time).
Proposal (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:FLUSH-UPGRADING)
-- Delete all the documentation that suggests the :element-type argument
to make-array might not be a satisfactory element-type in the type
specifier for the kind of array produced. Particularly, delete the
documentation that permits a difference between type-specifiers "for
declaration" and "for discrimination; primarily this means parts
of the discussion in CLtL, section 4.5, p. 45 and 46. Include a
statement that `(array ,aet) is a suitable type-specifier for the
array made by `(make-array <dims> :element-type ',aet ...). Include
also a statement that if `(array ,aet-x) and `(array ,aet-y) are
type-equivalent, then it must be the case that ,aet-x and ,aet-y are
also type-equivalent.
-- Change the documentation of ARRAY-ELEMENT-TYPE, CLtL p. 291 by deleting
the sentence begining "This set may be larger than the set requested
when the array was created; for example . . ."
-- Change the implementation of arrays so that a canonical member of
the equivalence class around the :element-type argument is always
remembered; ARRAY-ELEMENT-TYPE should return this canonical member.
Rationale:
This makes for maximum portability; type specifiers are "remembered"
exactly as the user typed them in (up to type-equivalence transformations).
Current Practice:
No vendor implements this.
Adoption Cost:
Array implementations would have to be changed in every vendor; for some,
this could be an enormous amount of work. In some implementations, the
"cheapest" primitive arrays might become considerably more costly. Since
arrays seem to be at the base of every Common Lisp system, the effects of
this change could be widespread, and costly to fix.
Benefits:
Being in love with portability means never having to say you're sorry
about TYPEP.
Conversion Cost:
Because of the prevalence of confusion in this area, it seems that no
user code will have to be changed. However, knowing what :element-type
specifiers are implemented efficiently will likely still be of concern to
most vendor's clients.
Esthetics:
Discussion:
The test case is, unfortunately, not relevant to this proposal, since it
presumes that some non-trivial upgrading is going on. In particular,
there will be no "two, distinct type specifiers ,aet-x and ,aet-x that are
definitely not type-equivalent, but for which
(array-element-type (make-array 0 :element-type ',aet-x)) ==> ,aet-y"
Many people are in favor of this proposal, at least initially. See the
arpanet interchanges mentioned above.
One (or more) senior implementor(s) at Lucid favor(s) this proposal.
It may be desirable to introduce a new function CANONICAL-TYPE of one
argument, which takes a type-specifier into a canonical type-specifier
for that type-equivalence class.
∂17-May-88 0213 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 17 May 88 02:11:55 PDT
Received: by labrea.stanford.edu; Tue, 17 May 88 02:12:11 PDT
Received: from bhopal.lucid.com by edsel id AA29539g; Tue, 17 May 88 02:02:32 PDT
Received: by bhopal id AA03785g; Tue, 17 May 88 02:05:55 PDT
Date: Tue, 17 May 88 02:05:55 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805170905.AA03785@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 23 Mar 88 14:49 EST <19880323194958.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)
There is one very dangerous loophole in this proposal, which could be
trivially plugged up. The issue is whether symbols are a critical
arugment to any of the options, or whether "names" would be satisfactory.
What would you say to the following alterations:
(1) Change most uses of the meta-variable {symbol} to {name}, with
an explicit statement that such a {name} must be either a string,
or a symbol. Thus the description of :IMPORT-FROM would go from
(:IMPORT-FROM {(package-name {symbol}*)}*)
to
(:IMPORT-FROM {(package-name {name}*)}*)
or maybe even
(:IMPORT-FROM {(package-name {symbol-name}*)}*)
Change also the phrase "Note that only the name of each argument symbol
is used." to something like "Note that only the name of each argument
is used; if a symbol is passed, its symbol-name is used".
(2) Flush the two options that require symbols, as opposed to names --
namely :IMPORT and :SHADOWING-IMPORT. Note that these are the only
two that don't have the phrase "Note that only the name of each
argument symbol is used." in their description. These two options
are superfluous since their functionality is completely covered by
:IMPORT-FROM and :SHADOWING-IMPORT-FROM.
The :IMPORT option as currently specified makes it all too easy to violate
reasonable package modularity rules -- e.g. (:IMPORT foo::bar) -- without
considering the warning given on CLtL p175 (top of page) "... since
accessing an internal symbol of some other package is usually a mistake".
Much worse, I've seen even very experienced hackers (more than 10 years
experience) fall into the trap of thinking that FOO::BAR means "access
the internal symbol BAR in the FOO package", or "access the symbol BAR
present in the FOO package, regardless of whether it is external or not".
The disaster that occurs once in a long while is that merely reading in
FOO::BAR creates some imposter symbol in the BAR package that shouldn't
be there at all; but the poor loser who does this doesn't find that out
until a much later time, when a USE-PACKAGE or EXPORT is done. And of
course by the time he finds it out, there is little hope of ferreting
out all the structures already read-in that point to the bogon symbol.
It may be too much to ask that the :IMPORT-FROM option signal an error
if no symbol of the requested name is available in the specified package.
This would (desirably, I think) differ from the reader's action when
parsing a double-colon notation. But at the very least, why add the
:IMPORT and :SHADOWING-IMPORT options that *require* symbols as opposed to
names? Why, when there are perfectly good alternatives that don't have
the modularity-violating implications described above?
If these two alterations are made, then a DEFPACKAGE can be written with
all data specified as strings; and in the cases when symbols are actually
are supplied, then the compiler can convert them to strings as they are
put out into the fasl file. (Essentially the same compiler conversion
takes place now in Symbolics treatment of SHADOW, and in Lucid's 3.0
release version of SHADOW).
-- JonL --
∂19-May-88 0042 CL-Cleanup-mailer Features
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 19 May 88 00:42:42 PDT
Received: by labrea.stanford.edu; Thu, 19 May 88 00:43:03 PDT
Received: from bhopal.lucid.com by edsel id AA09223g; Thu, 19 May 88 00:11:16 PDT
Received: by bhopal id AA11771g; Thu, 19 May 88 00:14:48 PDT
Date: Thu, 19 May 88 00:14:48 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805190714.AA11771@bhopal.lucid.com>
To: Gumby@mcc.com
Cc: common-lisp@sail.stanford.edu
In-Reply-To: David Vinayak Wallace's message of Wed, 18 May 88 20:58 CDT <880518205815.3.GUMBY@BRAHMA.ACA.MCC.COM>
Subject: Features
re: What do you do if you encounter #+nasa:hyperdrive but you don't have the
nasa package defined?
If an alleged feature name "doesn't exist", that means that the feature
isn't present [and it can fail to "exist" in several different ways].
This is the behaviour Lucid implements, and I'm sure I saw some network
mail a long time ago agreeing to this meaning. But I don't see any
statement about this case in the X3J13 CLeanup Committee's issue
SHARPSIGN-PLUS-MINUS-PACKAGE. Kent? Larry?
-- JonL --
∂19-May-88 1125 CL-Cleanup-mailer ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Received: from hub.ucsb.edu by SAIL.Stanford.EDU with TCP; 19 May 88 11:24:57 PDT
Received: from csilvax.ucsb.edu by hub.ucsb.edu (5.59) id AA15596; Thu, 19 May 88 11:26:00 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA27191; Thu, 19 May 88 11:20:30 PDT
Date: Thu, 19 May 88 11:20:30 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 19 May 88 11:20:30 PDT
To: cl-cleanup@sail.stanford.edu
Subject: ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
References: CLtL p.308-10 & 86-003 p.4
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
There is some confusion over whether default initialization
forms for defstruct slots get evaluated, when they are not needed
because a keyword argument was supplied to the constructor function.
As a consequence of this confusion, there is confusion over whether
there can be a type-mismatch error between the specified type of the slot
and the type of the default value.
On page 308, it says "The default-init is a form that is evaluated
each time a structure is to be constructed; the value is used as the
initial value of the slot. If no default-init is specified, then the
initial contents of the slot are undefined and implementation-dependent."
On the next page, however, it says that the default-init is evaluated if
the keyword argument is not supplied and the converse, although not stated,
is intended and informally implied.
Proposal (DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED):
Clarify that the converse is true. i.e that the default-init is not evaluated
if the keyword argument is supplied.
In the quote from page 308, delete the second sentence and replace
"a structure is to be constructed; the value is" by "its value is to be".
To section 19.3, add a clarification,
such as the following from Guy's issues file:
"The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Test Case:
In the following sequence, only the last call is an error.
(defstruct person (name 007 :type string))
(make-person :name "James")
(make-person)
Rationale:
It is inefficient, and inconsistent with the rest of the language, for the
default initialization form to be evaluated when it is not needed.
Consequently, when it's not needed, such type-mismatch errors should not be
detectable in general.
Any existing confusion should be clarified by this proposal.
Current Practice:
KCL does not evaluate the default initialization form unless it is needed;
even when it is needed, the type checking is not done at all.
Cost to Implementors:
If there are any implementations that currently behave differently from
the proposed way, then they need some slight modification.
Cost to Users:
None.
Benefits:
Clarity and portability. In particular, clarifying that the unaesthetic
situation mentioned in the next section is allowed should be reassuring.
Aesthetics:
It appears slightly unaesthetic to have a default value that violates a
type specification.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
∂19-May-88 1126 CL-Cleanup-mailer When is the Cambridge cleanup meeting?????
Received: from hub.ucsb.edu (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 19 May 88 11:26:23 PDT
Received: from csilvax.ucsb.edu by hub.ucsb.edu (5.59) id AA15623; Thu, 19 May 88 11:27:57 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA27212; Thu, 19 May 88 11:22:27 PDT
Date: Thu, 19 May 88 11:22:27 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 19 May 88 11:22:27 PDT
To: cl-cleanup@sail.stanford.edu
Subject: When is the Cambridge cleanup meeting?????
Cc: skona@csilvax.ucsb
Is there a cleanup subcommittee meeting scheduled for the day or two
before the Boston meeting in June, and, if so, when and where is it?
∂19-May-88 1136 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
Received: from hub.ucsb.edu (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 19 May 88 11:34:33 PDT
Received: from csilvax.ucsb.edu by hub.ucsb.edu (5.59) id AA15701; Thu, 19 May 88 11:35:49 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA27124; Thu, 19 May 88 11:18:53 PDT
Date: Thu, 19 May 88 11:18:53 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 19 May 88 11:18:53 PDT
To: cl-cleanup@sail.stanford.edu
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
I have divided the issue DEFSTRUCT-SLOTS-CONSTRAINTS into 2 issues,
DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER and DEFSTRUCT-SLOTS-CONSTRAINTS-NAME,
even though they are both trivial, because otherwise practically every
section of the proposal had 2 parts, and also it seemed reasonable to
separate a change from a clarification, for approval purposes (actually the
main reason is that I couldn't think of a name for the joint proposal).
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
References: CLtL p.307 & 86-003 p.4
Category: CHANGE
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
Structures defined by defstruct currently are required to have at least
one slot. This seems to have been a mistake in the design of the language.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER:ALLOW-ZERO):
Allow a call to defstruct to have zero slot-descriptions.
i.e. change the + to a * in the syntax of calls to defstruct
given at the bottom of page 307 of CLtL.
Test Case:
(defstruct s), which is not allowed according to CLtL, would be allowed.
Rationale:
The current restriction is in marked contrast to the generality allowed
elsewhere in the language. And removing it slightly increases the
usefulness of defstruct - by allowing the zero slot case when it may be
deemed useful and by not requiring a check for it when it doesn't matter.
Current Practice:
KCL allows zero slots.
Cost to Implementors:
None for implementations that currently allow zero slots.
Very slight for others.
Cost to Users:
None.
Benefits:
Slightly increases the usefulness of defstruct and is aesthetic.
Aesthetics:
In general, it is more aesthetic to allow for generality rather than to
specifically prohibit a particular case. And the generality in this case
is consistent with that of many other features of the language, such as
that arrays can be empty, functions like + and list can take zero arguments,
etc.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
The case of two slots of a structure having the same name is not
discussed in CLtL.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have the same name.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
Test Cases:
(defstruct struc slot slot) would be an error. So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).
Rationale:
Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error. Checking for it
would be costly so signaling this error is not required.
Current Practice:
In KCL, if 2 slots have the same name, no warning message is
given but mysterious behavior ensues. (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
∂19-May-88 1152 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
Received: from hub.ucsb.edu (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 19 May 88 11:52:42 PDT
Received: from csilvax.ucsb.edu by hub.ucsb.edu (5.59) id AA15559; Thu, 19 May 88 11:24:25 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA27124; Thu, 19 May 88 11:18:53 PDT
Date: Thu, 19 May 88 11:18:53 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 19 May 88 11:18:53 PDT
To: cl-cleanup@sail.stanford.edu
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
I have divided the issue DEFSTRUCT-SLOTS-CONSTRAINTS into 2 issues,
DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER and DEFSTRUCT-SLOTS-CONSTRAINTS-NAME,
even though they are both trivial, because otherwise practically every
section of the proposal had 2 parts, and also it seemed reasonable to
separate a change from a clarification, for approval purposes (actually the
main reason is that I couldn't think of a name for the joint proposal).
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
References: CLtL p.307 & 86-003 p.4
Category: CHANGE
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
Structures defined by defstruct currently are required to have at least
one slot. This seems to have been a mistake in the design of the language.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER:ALLOW-ZERO):
Allow a call to defstruct to have zero slot-descriptions.
i.e. change the + to a * in the syntax of calls to defstruct
given at the bottom of page 307 of CLtL.
Test Case:
(defstruct s), which is not allowed according to CLtL, would be allowed.
Rationale:
The current restriction is in marked contrast to the generality allowed
elsewhere in the language. And removing it slightly increases the
usefulness of defstruct - by allowing the zero slot case when it may be
deemed useful and by not requiring a check for it when it doesn't matter.
Current Practice:
KCL allows zero slots.
Cost to Implementors:
None for implementations that currently allow zero slots.
Very slight for others.
Cost to Users:
None.
Benefits:
Slightly increases the usefulness of defstruct and is aesthetic.
Aesthetics:
In general, it is more aesthetic to allow for generality rather than to
specifically prohibit a particular case. And the generality in this case
is consistent with that of many other features of the language, such as
that arrays can be empty, functions like + and list can take zero arguments,
etc.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
The case of two slots of a structure having the same name is not
discussed in CLtL.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have the same name.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
Test Cases:
(defstruct struc slot slot) would be an error. So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).
Rationale:
Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error. Checking for it
would be costly so signaling this error is not required.
Current Practice:
In KCL, if 2 slots have the same name, no warning message is
given but mysterious behavior ensues. (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
∂19-May-88 1301 CL-Cleanup-mailer Re: When is the Cambridge cleanup meeting?????
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 May 88 13:01:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAY 88 13:00:08 PDT
Date: 19 May 88 13:00 PDT
From: masinter.pa@Xerox.COM
Subject: Re: When is the Cambridge cleanup meeting?????
In-reply-to: Skona Brittain <skona%csilvax@hub.ucsb.edu>'s message of Thu, 19
May 88 11:22:27 PDT
To: skona%csilvax@hub.ucsb.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880519-130008-6484@Xerox>
I fell into a hole. I haven't scheduled a meeting. When would you like one?
∂19-May-88 1354 CL-Cleanup-mailer PASSED X3J13 March 1988
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 May 88 13:53:57 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAY 88 13:47:40 PDT
Date: 19 May 88 13:47 PDT
From: masinter.pa@Xerox.COM
Subject: PASSED X3J13 March 1988
To: CL-CLEANUP@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
Message-ID: <880519-134740-6575@Xerox>
I have a breather, and can get back to cl-cleanup work. It is late, but lets do
what we can in the remaining time. First are a couple of status lists.
These issues passed at X3J13, March 1988. They will not be distributed again.
- ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87)
(Interaction of ADJUST-ARRAY and displaced arrays)
- APPEND-DOTTED (Version 5, 14-Jan-88)
(What happens to CDR of last CONS? in other
than last arg?)
- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed X3J13/Jun87
Version 7 passed X3j13/Nov87
- ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87)
(Extend ASSOC-IF, etc. to allow :KEY)
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Version 1 passed X3J13/Nov87
- DECLARE-MACROS (Version 3, 5-FEB-88)
(Disallow macros expanding into declarations.)
- DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87)
(Documentation string is not evaluated.)
- DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88)
(DISASSEMBLE doesn't smash the def if not compiled)
- DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87)
( DO-SYMBOLS can the same symbol twice?)
<<<The rationale contains a typo: DO-PACKAGE for DO-SYMBOLS>>>
- DRIBBLE-TECHNIQUE (Version 2, 14-Feb-88)
(dribble can't be used programmatically)
<<<VAXLisp Current Practice wrong.>>>
- FLET-DECLARATION (Version 2, 2 Feb 88)
(Allow declarations in FLET, MACROLET)
- FORMAT-COLON-UPARROW-SCOPE (Version 3, 5 Feb 88)
(what iteration does ~:↑ exit from?)
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Version 2 passed X3J13/Nov87
<<<example is bogus; that example was one of the better uses
for the facility, too>>>
- FUNCTION-TYPE-KEY-NAME (Version 3, 5 Feb 88)
(allow &KEY (:KEYNAME type)) in FUNCTION decls )
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 passed X3J13/Nov87.
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Version 8 passed X3J13/Nov87
- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Version 6 passed X3J13/Nov 87
- PATHNAME-SYMBOL (Version 5, 5-Feb-88)
(Do symbols automaticly coerce to pathnames?)
- PUSH-EVALUATION-ORDER (Version 5,25-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
- REDUCE-ARGUMENT-EXTRACTION (version 3, 13-Feb-88)
(Add :KEY to REDUCE)
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
(What does SHADOW do if symbol is already there?)
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
(*FEATURES* are in the keyword package)
- - - - - - - - - - - - - - - - - - - - - - - - - - -
These issues were rejected at X3J13 March 1988. They will not be distributed
again.
- COMPILER-WARNING-BREAK (Version 4,23-Nov-87 )
(Does *BREAK-ON-WARNING* affect the compiler?)
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5, 5-Feb-88)
(let FIND, SUBSTITUTE etc work on multi-dimensional arrays)
∂19-May-88 1500 CL-Cleanup-mailer Issue: FUNCTION-TYPE (version 10)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 May 88 15:00:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAY 88 14:46:30 PDT
Date: 19 May 88 14:23 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 10)
To: CL-CLEANUP@Sail.stanford.edu
CC: Masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880519-144631-1033@Xerox>
Here is my attempt to rewrite FUNCTION-TYPE as per the discussion at the March X3J13 meeting. I added a comment at the end.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
19-May-88, Version 10 by Masinter, (modify as per X3J13)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
Proposal FUNCTION-TYPE:X3J13-MARCH-88
This proposal is basically the STRICT-REDEFINITION proposal of version 9
of this issue, with a few typos corrected and changes to section 2E as
agreed upon at X3J13, March 1988.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any FUNCTION subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
with CAR = LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Clarify that, under this definition of the FUNCTION type,
the functions FUNCALL and APPLY, and, by extension, any
function that takes a "functional" argument, will accept
any object that can be coerced to a FUNCTION, including
objects of type FUNCTION, symbols, and lists that begin
with lambda. (This is a clarification because it is a
restatement of the current meaning of CLtL using the new
terminology.)
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(FUNCTIONP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type FUNCTION.
6a. (COERCE symbol 'FUNCTION) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'FUNCTION) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the
expansion interface hook by MACROEXPAND-1.
Rationale:
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
This proposal is a compromise between a CONSERVATIVE proposal (which left
FUNCTION alone and introduced a new type), and STRICT-REDEFINITION proposal,
which incompatibility changed not only the FUNCTION type and SYMBOL-FUNCTION,
but also the behavior of FUNCALL, APPLY and functions with functional arguments.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is true for values
returned by FUNCTION, symbols that are FBOUNDP, and lambda expressions.
In some implementations, (TYPEP x 'FUNCTION) is true only for values
returned by FUNCTION.
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations have exactly the
semantics described in this proposal.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or to some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The changes to FUNCTIONP and the FUNCTION type declaration are relatively easy
to deal with.
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell, or expected lists back, will
have to change. Such code was already not portable, however, since some
implementations signal an error when this is done.
Benefits:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
The type hierarchy would be simplified.
This proposal brings Common Lisp slightly closer to Scheme and
the work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with the FUNCTION type.
Aesthetics:
This proposal improves the aesthetics of the language.
Discussion:
This issue has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. Two proposals were circulated at the March 1988 meeting of X3J13;
this version is the result of discussions at that meeting. It is a compromise
between the conflicting goals of backward compatibility, flexibility in the
language, and simple semantics.
This proposal does not address the issue of when coercion to functions occur.
For example, it is allowed to write
(MAPCAR 'FROB my-list)
It is not specified when the coercion of FROB to its SYMBOL-FUNCTION
occurs. For example,
(DEFUN FROB (X)
(WHEN (> X 0) (SETF (SYMBOL-FUNCTION 'FROB) #'(LAMBDA (X) NIL)))
T)
(MAPCAR 'FROB '(-1 -1 1 1))
may return different results if MAPCAR coerces its functional argument
once rather than for each element. This may require a separate
cleanup issue.
∂20-May-88 1914 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 20 May 88 19:14:40 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191384; Fri 20-May-88 22:12:41 EDT
Date: Fri, 20 May 88 22:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8805170905.AA03785@bhopal.lucid.com>
Message-ID: <19880521021246.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 17 May 88 02:05:55 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
There is one very dangerous loophole in this proposal, which could be
trivially plugged up. The issue is whether symbols are a critical
arugment to any of the options, or whether "names" would be satisfactory.
What would you say to the following alterations:
(1) Change most uses of the meta-variable {symbol} to {name}, with
an explicit statement that such a {name} must be either a string,
or a symbol. Thus the description of :IMPORT-FROM would go from
(:IMPORT-FROM {(package-name {symbol}*)}*)
to
(:IMPORT-FROM {(package-name {name}*)}*)
or maybe even
(:IMPORT-FROM {(package-name {symbol-name}*)}*)
Change also the phrase "Note that only the name of each argument symbol
is used." to something like "Note that only the name of each argument
is used; if a symbol is passed, its symbol-name is used".
Saying symbol-name instead of symbol is a reasonable change to the
presentation.
(2) Flush the two options that require symbols, as opposed to names --
namely :IMPORT and :SHADOWING-IMPORT. Note that these are the only
two that don't have the phrase "Note that only the name of each
argument symbol is used." in their description. These two options
are superfluous since their functionality is completely covered by
:IMPORT-FROM and :SHADOWING-IMPORT-FROM.
The :IMPORT option as currently specified makes it all too easy to violate
reasonable package modularity rules -- e.g. (:IMPORT foo::bar) -- without
considering the warning given on CLtL p175 (top of page) "... since
accessing an internal symbol of some other package is usually a mistake".
....
The disaster that occurs once in a long while is that merely reading in
FOO::BAR creates some imposter symbol in the BAR package that shouldn't
be there at all; but the poor loser who does this doesn't find that out
until a much later time, when a USE-PACKAGE or EXPORT is done. And of
course by the time he finds it out, there is little hope of ferreting
out all the structures already read-in that point to the bogon symbol.
It may be too much to ask that the :IMPORT-FROM option signal an error
if no symbol of the requested name is available in the specified package.
This would (desirably, I think) differ from the reader's action when
parsing a double-colon notation. But at the very least, why add the
:IMPORT and :SHADOWING-IMPORT options that *require* symbols as opposed to
names? Why, when there are perfectly good alternatives that don't have
the modularity-violating implications described above?
Well, wait a minute. Either :IMPORT-FROM does exactly the same thing as
:IMPORT in terms of creating symbols that did not already exist, in
which case removing :IMPORT doesn't solve anything, or else :IMPORT-FROM
refuses to create symbols, which as you say ("it may be too much to
ask") is likely to cause problems because things will only work if done
in a certain order so that the symbols get created before they are
needed. In Symbolics Common Lisp, :IMPORT-FROM will create symbols if
they don't already exist, it's exactly like a double-colon package
prefix.
People who use double-colon-prefix are either confused and asking for
trouble, or know exactly what they're doing. Either way, your suggested
change to DEFPACKAGE isn't going to help them, as far as I can see.
Thus if people feel that having both :IMPORT and :IMPORT-FROM is redundant,
I'd prefer removing :IMPORT-FROM. However, I think current practice shows
it's better to have both. Do you think :IMPORT-FROM should be changed
to be like single-colon package prefix?
∂20-May-88 1921 CL-Cleanup-mailer Issue: FUNCTION-TYPE (version 10)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 20 May 88 19:21:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191385; Fri 20-May-88 22:21:02 EDT
Date: Fri, 20 May 88 22:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 10)
To: masinter.pa@Xerox.COM
cc: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <880519-144631-1033@Xerox>
Message-ID: <19880521022111.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Approved, except for one thing. The word "procedure" appears
three times without being defined. One occurrence is legitimate,
but I believe these two are typos for "function".
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error.
6a. (COERCE symbol 'FUNCTION) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
∂20-May-88 2102 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 May 88 21:02:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 408141; 20 May 88 23:59:59 EDT
Date: Fri, 20 May 88 23:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8805130918.AA25649@bhopal.lucid.com>
Message-ID: <19880521035951.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING seems like the
beginning of a reasonable proposal. There are a few problems with it:
You don't list what type specifiers it applies to. I assume you mean
to include SIMPLE-ARRAY and VECTOR in addition to ARRAY. What about
COMPLEX?
Your proposal assumes without stating it explicitly that
(array-element-type (make-array dimensions :element-type element-type
options...))
is independent of the values of dimensions and options. I believe this
to be true of most implementations, but see nothing in CLtL that requires
it. I can easily imagine an implementation that offers more specialized
arrays of rank 1 than of other ranks, more specialized adjustable than
non-adjustable arrays, or size-dependent specializations (why bother with
packed formats for very small arrays?). This could seriously impact the
adoption cost. I think I have mentioned this before; do I have to drag
out all the other comments I made last time this issue came up?
You should specify more clearly that you are incompatibly changing the
meaning of (typep array '(array <element-type>)) from "(aref array i)
is guaranteed to result in an object of type <element-type>" to "(setf
(aref array i) x) is type-valid if and only if x is of type
<element-type>."
I don't understand the justification for introducing the function
UPGRADE-ARRAY-ELEMENT-TYPE. There are plenty of other type operators
missing from Common Lisp, why put in just this one?
In the discussion section, "In short, no one would not want to
gain portability at the expense of limiting the language to the architectural
features of the hardware on which it was first implemented." does
not say what I think you meant it to say, unless you've suddenly
changed your views radically. Take out a "not."
The proposal is much too long and contains too many digressions. It
should be extensively pared down before it is presented to X3J13. You
can judge from my 1-week delay in response how difficult I found it to
read all the way through this proposal. I haven't noticed any other
responses, so others may have found it very difficult also.
∂21-May-88 0207 CL-Cleanup-mailer Issue: FUNCTION-TYPE (version 10)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88 02:07:48 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 02:08:07 PDT
Received: from bhopal.lucid.com by edsel id AA19226g; Sat, 21 May 88 01:58:30 PDT
Received: by bhopal id AA07793g; Sat, 21 May 88 02:02:10 PDT
Date: Sat, 21 May 88 02:02:10 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805210902.AA07793@bhopal.lucid.com>
To: CL-CLEANUP@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE (version 10)
re: 5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound[sic],
(FUNCTIONP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
I don't understand the motivation behind this point (5b). Since (5a) says
that SYMBOL-FUNCTION is permitted to return "something", and is not
"well-defined" in the case when the symbol names a macro or special form,
then what is the advantage of preventing it from returning a function?
I've seen lots of CL code like:
(defun foo-expander (x) `(QUOTE ,x))
(setf (macro-function 'FOO) #'foo-expander)
How will one fetch the current "expander function" for this macro?
Is the issue merely that some implementations will have to cons in order to
return a value for MACRO-FUNCTION? In that case, maybe we need a predicate
MACRO-P, just as there is a predicate SPECIAL-FORM-P.
-- JonL --
∂21-May-88 0247 CL-Cleanup-mailer ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88 02:47:32 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 02:47:00 PDT
Received: from bhopal.lucid.com by edsel id AA19314g; Sat, 21 May 88 02:35:44 PDT
Received: by bhopal id AA07861g; Sat, 21 May 88 02:39:21 PDT
Date: Sat, 21 May 88 02:39:21 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805210939.AA07861@bhopal.lucid.com>
To: skona%csilvax@hub.ucsb.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Skona Brittain's message of Thu, 19 May 88 11:20:30 PDT <8805191831.AA11226@edsel.lucid.com>
Subject: ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
You can add to the "Current Practice:" section:
LUCID does not evaluate the default initialization form unless it is
needed; even when it is needed, the type checking is not done at all.
However, at structure definition time, if an initial value form is
constanp and doesn't satisfy the :type specification, a warning message
is printed.
Oddly enough, Lucid's interpreter ensures that SETF's of slots obey the
:type specifier, even though init-forms aren't checked. Furthermore, in
safety levels 2 or higher, the compiled code will do minimal "memory-
integrity" type checking for SETF's (which is what I suspect the various
special-purpose microcoded machines do); however except for low-level numeric
types, this is rarely equivalent to what a full type check would do.
I have long suggested that there should be at least one mode of operation
such that all :type information is checked when setting values into structure
slots (setf as well as initialization). Some have suggested that this mode
could be "when running interpretively, or when when compiled with the highest
degree of SAFETY and lower degrees of SPEED." However, since the wording of
CLtL p310 suggests that the :type slot options is merely a DECLARE, and since
some vendors effectively ignore any and all declarations [except for SPECIAL],
then this suggestion hasn't reached proposal stage yet.
-- JonL --
∂21-May-88 0248 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88 02:48:07 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 02:48:23 PDT
Received: from bhopal.lucid.com by edsel id AA19322g; Sat, 21 May 88 02:36:28 PDT
Received: by bhopal id AA07864g; Sat, 21 May 88 02:40:05 PDT
Date: Sat, 21 May 88 02:40:05 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805210940.AA07864@bhopal.lucid.com>
To: skona%csilvax@hub.ucsb.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Skona Brittain's message of Thu, 19 May 88 11:18:53 PDT <8805191852.AA11302@edsel.lucid.com>
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
You can add to the "Current Practice:" section:
LUCID allows zero slots.
-- JonL --
∂21-May-88 0520 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88 05:20:44 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 05:21:08 PDT
Received: from bhopal.lucid.com by edsel id AA19658g; Sat, 21 May 88 05:10:11 PDT
Received: by bhopal id AA08230g; Sat, 21 May 88 05:13:49 PDT
Date: Sat, 21 May 88 05:13:49 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805211213.AA08230@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 20 May 88 22:12 EDT <19880521021246.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)
re: Well, wait a minute. Either :IMPORT-FROM does exactly the same thing as
:IMPORT in terms of creating symbols that did not already exist, in
which case removing :IMPORT doesn't solve anything, . . .
That isn't quite right. :IMPORT explicitly requires you to put symbols
in the source code, and it is the reading in of that code (with its
liklihood of having bogon-producing :: syntax) that causes the lossage.
For example, if your file had in it:
(defpackage my-package (:import 'uluz::bunkie))
then the damage to the ULUZ package is done by the reader long before
defpackage or :import ever has a chance to muck things up.
I suggest removing :IMPORT because the :IMPORT-FROM format can be made
to work given only the symbol-name (not the symbol itself, with it's home
package known); there would be no other way to indicate the package
information for :IMPORT if you used only symbol-names as arguments.
Oddly enough, looking back over the mail on this issue, it seems as though
KMP wanted to suggest exactly the same thing, in a messaged dated
Sat, 12 Mar 88 19:14 EST. Your disagreement with him was phrased as
follows:
I disagree because of alphabetic case issues in strings. Note that in
these symbol/string arguments, the symbol is being used only for its
name, so there are never any package issues. . . .
but this argument fails to account for the fact that the damage is done
by the reader, when it is required to read in symbols, rather than by
any action of defpackage itself.
re: Do you think :IMPORT-FROM should be changed
to be like single-colon package prefix?
Well, only in that it not create an entry *** in some other package *** where
one doesn't already exist; I wouldn't necessarily want it to require the
symbol to be external. Yes, I think it would be a tremendous step forward
in helping to prevent one of the most obscure nits that even an experienced
package user can fall into.
-- JonL --
∂21-May-88 0613 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88 06:13:23 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 06:13:50 PDT
Received: from bhopal.lucid.com by edsel id AA19922g; Sat, 21 May 88 06:02:08 PDT
Received: by bhopal id AA08320g; Sat, 21 May 88 06:05:42 PDT
Date: Sat, 21 May 88 06:05:42 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805211305.AA08320@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 20 May 88 23:59 EDT <19880521035951.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
You raise a number of good points here. I'm going to reply to several
of them out-of-order, to do the "easier" ones first.
re: In the discussion section, "In short, no one would not want to
gain portability at the expense of limiting the language . . .
Take out a "not."
Yes, several persons here at Lucid noted the typo too. Take out a "not".
re: I don't understand the justification for introducing the function
UPGRADE-ARRAY-ELEMENT-TYPE. There are plenty of other type operators
missing from Common Lisp, why put in just this one?
Because of the prevalence of user confusion about "upgrading" in arrays;
this gives him a reasonable query mechanism for a very common problem. It
also, quite likely, reflects a functionality that each implementation will
have to provide for itself anyway.
re: You don't list what type specifiers it applies to. I assume you mean
to include SIMPLE-ARRAY and VECTOR in addition to ARRAY. What about
COMPLEX?
I didn't think that explicit mention of SIMPLE-ARRAY and VECTOR was
necessary, as they are subtypes of ARRAY. However, it can't hurt to
put in the one sentence clarification. I did not mean COMPLEX; I only
meant to cover arrays. Perhaps COMPLEX could be "swept under the same
rug"; do you think it is a good idea to do so?
re: Your proposal assumes without stating it explicitly that
(array-element-type (make-array dimensions :element-type element-type
options...))
is independent of the values of dimensions and options. I believe this
to be true of most implementations, but see nothing in CLtL that requires
it. . . . This could seriously impact the adoption cost. I think I
have mentioned this before; do I have to drag out all the other comments
I made last time this issue came up?
Yes, I think this assumption about independence is right. I don't remember
your bringing out any such discussion on cl-cleanup before; the only note
I can find is just a statement of this same assumption sent out to the
common-lisp mailing list:
Date: Fri, 11 Mar 88 16:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: the array type mess....
To: Ram@C.CS.CMU.EDU
Cc: Jon L White <edsel!jonl@LABREA.STANFORD.EDU>,
common-lisp@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
In-Reply-To: <RAM.12365298662.BABYL@>
. . .
An interesting comment on all this is that we are implicitly assuming
that an implementation's spectrum of specialized array types is independent
of the size, number of dimensions, indirectness, or adjustability of the
array. This seems unlikely to be true of all implementations. I don't
know how to fix this deficiency.
Someone should write this up in Cleanup form and thus give us all
a chance to think about it more deeply.
But the grim file reaper seems to have put on temporarily inaccessible
back-up tape my cl-cleanp archives prior to Mar 4, 1988. So I may have
just missed all the commentary about it before.
On the other hand, if this assumption is violated, the I'd be curious
to know how an implementation can do, say, displacement of a vector to
a multi-dimensional array with conformal element type, and vice-versa.
I've heard that Symbolics users frequently do this in order to run
sequence-like functions over 2-dimensional arrays.
re: The proposal is much too long and contains too many digressions.
There are two proposals here, you know; the verbal discussion in Palo Alto
on March 13 suggested we would need two (and maybe this was a first?). I
have had commentary on it from folks at Lucid, but I note that CL-CLEANUP
has been effectively moribund for the six weeks prior to the submission of
this proposal. So I don't think the lack of other public replies means it
is any more difficult to comprehend than the other long proposals (such as,
"setf-function-vs-macro").
On the other hand, I agree that is is unfortunately long; I don't easily see
what can be deleted without opening up loopholes for someone to argue against.
Do you have some specific suggestions as to what could be elided without
inviting more criticism?
-- JonL --
∂23-May-88 0828 CL-Cleanup-mailer HASH-TABLE-PRINTED-REPRESENTATION
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 08:28:27 PDT
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 23 May 88 11:28:12 EDT
To: cl-cleanup@sail.stanford.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: HASH-TABLE-PRINTED-REPRESENTATION
Date: Mon, 23 May 88 11:27:58 EDT
Message-ID: <361.580404478@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU
Here's the draft of my hash table proposal.
Issue: HASH-TABLE-PRINTED-PREPRESENTATION
Category: ENHANCEMENT
Edit history: 23-May-88, Version 1 by Touretzky
Description:
Hash tables are currently second-class data structures when compared to
lists, vectors, and structures, because they have no READable printed
representation. This proposal introduces a #H reader syntax for hash
tables and a switch to control when hash tables will be printed this way.
Proposal (HASH-TABLES-PRINTED-REPRESENTATION:#H-NOTATION) :
1) Introduce the following reader notation for hash tables:
#nH(type (k1 v1) (k2 v2) ...)
"n" is the size of the table; it is analagous to the :size argument to
MAKE-HASH-TABLE. If omitted, the system picks some reasonable size.
"type" is one of EQ, EQL, or EQUAL. If omitted it defaults to EQL.
The (ki vi) pairs consist of a key and a value. There may be any number of
such pairs, including zero. Order is not significant. It is an error for
two keys to be identical (using the EQ, EQL, or EQUAL test, as
appropriate.)
2) Introduce a switch called *PRINT-HASH* whose initial value is
implementation-dependent. If *PRINT-HASH* is T, hash tables are printed
using the #H syntax (with all optional components supplied), subject to the
usual limits imposed by *PRINT-LEVEL* and *PRINT-LENGTH*. If *PRINT-HASH*
is NIL, hash tables are printed using the current #<HASH-TABLE ...> syntax.
Rationale: this is a useful upward compatible extension (except in
implementations that have usurped #H for other purposes), with very
low adoption cost.
Adoption Cost: A simple change to PRIN1 and the pretty printer. Most of
the code will be similar to existing routines for printing vectors in #()
notation and arrays in #nA() notation.
Benefits: this proposal makes hash tables first class objects. If
*PRINT-HASH* is T, their contents become visible in all the normal ways,
e.g., if FOO is bound to a hash table object, then typing FOO to a
read-eval-print loop will display the contents of the hash table. Hash
table contents may also be displayed by TRACE if the table is passed as an
argument; they may also be displayed by the debugger. Finally, hash tables
may be appear as literal objects in programs and be read or written to files.
Current practice: we know of no current implementations of this proposal.
Although some implementations allow the user to see hash table contents
with DESCRIBE or INSPECT, not all do. CMU Common Lisp's DESCRIBE, for
example, does not show hash table contents. This reinforces the need for
a standard #H notation to guarantee that users can manipulate a hash table
as easily as a vector, array, or structure.
Discussion:
Several alternatives have been suggested for the syntax of #H.
- preferred notation: #H(EQL (FOO 37) (BAR 42))
- dotted pair notation: #H(EQL (FOO . 37) (BAR . 42))
- property list: #H(EQL FOO 37 BAR 42)
- pseudo-structure: #S(HASH-TABLE TYPE EQL SIZE 20 INITIAL-CONTENTS ((FOO 37) (BAR 42)))
One problem with the currently proposed #H notation is that it provides no
way to specify a rehash-size or rehash-threshold. This should not be a
fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is also
shared by #nA notation.
-- Dave
∂23-May-88 1306 CL-Cleanup-mailer Re: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 13:05:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 13:04:54 PDT
Date: 23 May 88 13:04 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
In-reply-to: Jon L White <edsel!jonl@labrea.Stanford.EDU>'s message of Tue, 29
Mar 88 21:32:59 PST
To: edsel!jonl@labrea.Stanford.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880523-130454-5166@Xerox>
Two nits:
Aesthetics:
This is a bit silly, but I'm wondering if you are reconstructing QUUX's quote
accurately. The quote I can find (from format-colon-uparrow-scope), is
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr. In
any case, the proposal is to change WITH-OPEN-STRING, not FORMAT. I'd be happier
if it said that this was a minor improvement to the aesthetics of the language
because it made it more consistent.
Proposal format:
The preferred format is to use "Cost to Users" and "Cost to Implementors" rather
than "Adoption Cost" and "Implementation Cost" because people were confused by
them.
Thanks,
Larry
∂23-May-88 1329 CL-Cleanup-mailer Re: issue FUNCTION-TYPE
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 May 88 13:29:22 PDT
Date: 23 May 88 16:09:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Re: issue FUNCTION-TYPE
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
A couple of concerns:
It seems to me that the combination of #2e:
... the functions FUNCALL and APPLY ... will accept any object that
can be coerced to a FUNCTION ...
and #6a:
(COERCE symbol 'FUNCTION) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
requires implementations to signal errors for any undefined symbol.
I don't think the standard should require such error checking, for
reasons of efficiency in some implementations. (Of course it should
be encouraged.)
Perhaps the reason for this language is that COERCE is expected to
signal an error. That may be another issue; but for this issue I
don't think we should imply COERCE is actually used for every FUNCALL
or APPLY.
The other concern I had was that unlike the earlier FUNCTION-TYPE:
STRICT-REDEFINITION proposal, both symbols and lambda-expressions
(i.e., lists whose car is LAMBDA and whose cadr is a list) are
assumed to be acceptable to FUNCALL or APPLY. I had thought that
at the meeting we had agreed that #2e should refer to whatever
coerceable to a FUNCTION, but that what was coerceable was still
an issue.
In particular, I'd very much like to see lists not be FUNCALLable or
APPLYable. I think there are too many aesthetic and efficiency
reasons against continuing to allow lambda-expressions be treated as
"functions".
So far I haven't seen some of those reasons written down.
Here's an aesthetic/counter-intuitive-to-the-novice one:
Lambda-expressions don't obey the normal, apparent scoping rules because
free variables can't refer to lexical bindings. This is because
coercing a list to a function means (EVAL `(FUNCTION ,list)).
The following code does -not- count the number of nodes in a graph:
...
(let ((counter 0))
(traverse-thing '(lambda (node) (incf counter))
(thing-root)))
...
since it is not the same as
...
(let ((counter 0))
(traverse-thing #'(lambda (node) (incf counter))
(thing-root)))
...
which does pass around a closure incrementing the LET variable.
(This assumes COUNTER wasn't DEFVAR'd.)
Here's an efficiency reason:
At run-time FUNCALL or APPLY must check to see if its first argument
is a list, so that it can decide to call EVAL (or internal-equivalent).
In some implementations, this is deemed to be too expensive.
Of course some implementations may decide to handle lists for
compatibility reasons.
Anyway, these kinds of arguments really ought to be in this proposal
so everyone is aware of the issues. I'd rather make sure this proposal
resolves the question than postpone it with yet another proposal,
especially since that was what the original proposal was about.
---Walter
------
∂23-May-88 1340 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 13:39:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 13:35:28 PDT
Date: 23 May 88 13:35 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <880523-133528-5237@Xerox>
My notes from the subcommittee meeting that I broadcast 21 March were that
"JonL and Moon have comments. Moon has a description of stack model and unwind
as atomic." Through the fuzz of time I'm no longer sure what I meant by that
(much less what David meant.)
I'd like to get this one out of committee, in whatever form is necessary.
!
Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
References: UNWIND-PROTECT (p140, p142, p39)
Issue IGNORE-ERRORS, Draft error proposal.
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 27-Feb-87
Version 2 by Masinter 24-Oct-87
Version 3 by Masinter 27-Oct-87
Version 4 by Masinter 13-Feb-88
Version 5 by Masinter 23-May-88
Problem Description:
If a non-local return is done while in the cleanup form of an UNWIND-PROTECT,
the behavior is not always well-defined.
There are three basic cases:
Situation 0. Transfer to another point within the cleanup form.
(UNWIND-PROTECT 3 (BLOCK NIL (RETURN 4)) (PRINT 'XXX))
There is no ambiguity about how this form is to be interpreted.
Effectively:
. 3 evaluates to itself, which is queued for return
from the UNWIND-PROTECT.
. The BLOCK expression is entered, 4 is returned to
it and discarded because this is a not-for-value
situation.
. XXX is printed, XXX is returned by the PRINT and
that value is discarded because this is a not-for-value
situation.
. The 3 which was yielded earlier is retrieved and
returned as the value of the UNWIND-PROTECT.
Situation 1. Transfer to a point inside the point to which control
would have transferred.
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
This is a subject of controversy because:
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. Disagreement exists as to whether it is an error if the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found within the scope of the target of the
pending THROW (to FOO).
Situation 2. Transfer to a point outside the point to which return would
already have been. For example:
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
This is a subject of controversy because:
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. Disagreement exists as to whether it is an error if the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found outside the scope of the target of the
pending THROW (to FOO).
What is the appropriate behavior for situation 1 and situation 2 and similar
ones? For example, suppose that when WITH-OPEN-FILE tries to close the file upon
unwinding, it signals an error, and the condition handler also attempts to
throw? The question applies to all non-local transfers, whether performed by
THROW, RETURN-FROM, RETURN, GO.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:CONTINUATION-MODEL):
In all cases, a transfer of control within an UNWIND-PROTECT cleanup form to a
point outside of the UNWIND-PROTECT causes the original control transfer which
initiated the execution of the cleanup forms to be abandonded.
During the execution of the cleanup forms of an UNWIND-PROTECT a non-local exit
to a point outside of the scope of the UNWIND-PROTECT, but still within the
dynamic scope of of the target of the original non-local exit succeeds, and the
original pending exit is discarded. For example, in Situation 1, the pending
seek for tag FOO is discarded by the second THROW to BAR and the value 4 is
transfered to (CATCH 'BAR ...), which returns 4. The (CATCH 'FOO ...) then
returns the 4 because its first argument has returned normally. XXX is not
printed.
Where an UNWIND-PROTECT cleanup form attempts a non-local exit to a point
outside the original non-local exit, control is passed to the outer exit (and
the pending original non-local exit is discarded.) For example, in Situation 2,
the value 4 is returned from the (CATCH 'BAR ...); XXX is not printed.
In no case will UNWIND-PROTECT cleanup forms ever be attempted more than once.
Rationale:
The primary issues have to do with the safety of the language vs. the uniformity
of the model behind non-local transfer of control.
Current Practice:
Some implementations generate garbage code in situations 1 and 2. Some have
differing behavior compiled and interpreted.
Most that have implementations seem to implement the proposed semantics for
situation 2, but there is some divergence in Situation 1. For example, Spice
Lisp and Xerox implement the proposed semantics, while Symbolics Common Lisp
signals an error.
Cost to Implementors:
While require some compiler modifications in some implementations, in most
cases, that work was in order anyway since compilers may currently be doing
nothing particularly useful or defensible with the code in question.
Cost to Users:
Most user programs don't do this so the cost of converting existing code is
probably minimal. (There is some evidence that there are programs that expect
this behavior, so there is no conversion cost for those programs.)
Benefits:
Having this situation uniformly treated seems critical:
Programs that do this accidentally should behave the same on all systems so that
bugs can be detected and fixed very early rather than being found later on a
system which disagrees.
Programs that do this on purpose generally are trying to do something fairly
intricate and really need to be able to depend on it being uniformly treated. A
portable error/signal system and debugger may be among these. For example, one
programmer created his own "top level", to which the system "abort" character
would return, by doing:
(DEFUN MY-TOPLEVEL ()
(TAGBODY LOOP (UNWIND-PROTECT (REALLY-MY-TOPLEVEL)
(GO LOOP))))
Aesthetics:
This proposal is more intuitive to programmers who reason about programs in
terms of continuation passing. It falls out of the normal scoping rules as a
consequence of the fact that the cleaup code is evaluated in the lexical and
dynamic environment in which the UNWIND-PROTECT form appears. The action of
THROW is usefully described by saying that it is just like any other function.
It happens to discard the current continuation, run some cleanup things (like
variable unbindings and UNWIND-PROTECT actions), and transfer control elsewhere
in the program. In doing so, the function uses data structure primitives not
generally available to other programs, but it is not linguistically different
and receives no special exemption with regard to THROWs or other non-local
transfers of control done within its execution. A THROW from within an
UNWIND-PROTECT cleanup is not different than one in any other code; it discards
the ongoing action (stack unwinding) and replaces it by another action (as it
happens, another stack unwinding). The previous unwind is never resumed.
Discussion:
This issue is controversial. While the proposal included here had
a number of strong endorsements, there were also some strenuous
objections.
Two alternatives for situation 2 were seriously considered: that it should
signal an error, and that it the second non-local exit instead continues the
original (more extensive) one; e.g., in Situation 1, the second THROW to BAR
would be discarded in lieu of continuing the THROW to FOO.
Either of these alternatives would help prevent users from (either intentionally
or unintentionally) creating situations where it is impossible to abort a
computation with a THROW or other non-local return (e.g., an interrupt
implemented via THROW.)
For example, given
(LOOP
(CATCH 'FOO
(UNWIND-PROTECT (LOOP ... )
(THROW 'FOO T))))
With this proposal there is no way of exiting such a form. Signalling an error
would prevent programmers from getting into this unfortunate situation.
However, similar "unstoppable" loops can be created, without resorting to
non-nested non-local transfers within UNWIND-PROTECT clauses; for example:
(LABELS ((HA () (UNWIND-PROTECT (LOOP) (HA)))) (HA))
While it would be unfortunate for a programmer to accidentally create such an
unstoppable loop, the user has pretty clearly asked to have a loop that cannot
be exited and deserves to have that request carried out.
One implication is that it is likely that programming environments need to
provide some mechanism other than THROW to stop a truly run-away computation.
An interesting example which supports this proposal is one where there are two
BLOCKs
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated interchangably,
signalling an error in this situation would be inappropriate.
Guy Steele:
"We have here a classic case of the irresistible force (QUIT, dammit!)
versus the immovable mountain (UNWIND-PROTECT). I find that the
suggestion that situation 1 produce an error, but one that IGNORE-ERRORS
won't ignore, to be at least one level of epicycle too many.
Which mechanism are to we regard as primitive: the error system or the
catch/throw system? Or are they disjoint? I prefer, for simplicity, a
model in which the error system can be explained. as much as possible, as a
complex thing built on top of catch, throw, and unwind-protect."
David Moon:
"Of the several alternative proposals for this issue, the only one
that seemed appropriate to me has been removed. After re-reading the
12 messages on the topic that I thought were worth saving, I get the
feeling that the issues have not really been clarified and that the
discussion is largely dealing with strawmen. It seems like the
cleanup committee is heading towards making a serious mistake here.
Consider the form
(loop
(catch 'foo
(unwind-protect (loop)
(throw 'foo t))))
With the proposed semantics, it is impossible to stop this program
except by hitting it with two throws in rapid succession, with exactly
the right amount of delay between them so that the catch and
unwind-protect have not yet been re-established when the second throw
strikes. Consider any program-stopping operation that aborts execution
by throwing to a catch in the top-level read-eval-print loop (control-G
in Maclisp or c-Abort in Genera; most other systems have their own
equivalent of this). With the proposed semantics, when this throw
executes the unwind-protect cleanup handler, as it must, the throw will
be abandoned and execution will resume looping.
To me, the inability to stop a program is a much worse problem than
providing so-called correct semantics for a contrived program that
doesn't correspond to any real application. It was suggested that the
error system might depend on the ability to abort throws like this. If
that were demonstrated, I would change my tune, but until it's
demonstrated I am completely skeptical of the notion that any error
system would do this."
∂23-May-88 1346 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 13:46:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 13:43:39 PDT
Date: 23 May 88 13:43 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: TRACE-FUNCTION-ONLY
to: CL-CLEANUP@Sail.stanford.edu
cc: Kempf@sun.com
Message-ID: <880523-134339-5261@Xerox>
My notes from our subcommittee meeting was that we wanted to handle this issue
as a "make it undefined". However, in re-reading CLtL, I find that the language
there is perfectly adequate for handling the situation ("trace and untrace may
also accept additional implementation-dependent argument formats. The format of
the trace output is implementation-dependent.")
I no longer have any enthusiasm for pushing on this issue.
If anyone wants to pursue the issue in its current form, I would like to see a
discussion section saying that I think it is unnecessary.
∂23-May-88 1500 CL-Cleanup-mailer Issue: TAILP-NIL
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 15:00:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 14:57:52 PDT
Date: 23 May 88 14:55 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: TAILP-NIL
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <880523-145752-5438@Xerox>
I had promised and neglected to mail out this issue again. This is it. I've
asked ALarson@src.honeywell.com to write it up again (under the theory that
Hadden@HI-Multics.ARPA had volunteered once before.)
----- Begin Forwarded Messages -----
Date: 20 Nov 87 14:30 PST
From: Masinter.pa
Subject: Issue: TAILP-NIL
To: Hadden@HI-Multics.ARPA
cc: Masinter
line-fold: NO
My notes say that you volunteered to write this issue up. The
proposal format required is documented at the end.
!
Issue: TAILP-NIL
Reference: Steele p.275
Category: clarification
Description:
The description of tailp in Steele differs from current implementations
in the case where the first argument is NIL. In particular, the second
sentence "Another way to look at this is tailp is true if (nthcdr n
list) is sublist, for some value of n." does not accurately describe
current practice for the case where sublist is nil.
The behavior of TAILP on circular structures is also unspecified, e.g.,
is (tailp '() '#0=(x . #0#)) meaningful?
Proposal: TAILP-NIL:RETURN-NIL
Clarify that (TAILP NIL X) returns NIL for all lists X, and that tailp
must be true-false-indeterminate equivalent to
(defun tailp (x y)
(and x y (or (eq x y) (tailp x (cdr y)))))
i.e., if the second argument is circular and the first argument is not a
"tail" of the non-circular part of it, tailp may loop indefinitely.
----- Next Message -----
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 01 JUN 87 20:42:51 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87
20:41:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 161243; Mon 1-Jun-87 23:36:32 EDT
Date: Mon, 1 Jun 87 23:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL
To: CL-cleanup@Sail.stanford.edu
In-Reply-To: <870529-223659-1341@Xerox>
Message-ID: <870601233632.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I vote against releasing this issue until its writeup is in proper format.
When you write the current practice section, mention that Symbolics
follows the second of the two contradictory sentences in the tailp
writeup, hence (tailp nil <anything>) => t. This may mean that current
practice is not uniform.
For history, you can mention that the unambiguous definition in the
MIT Lisp Machine Manual (I consulted the fourth edition) would require
(tailp nil <anything>) => nil.
I personally don't care which disambiguation is adopted. If the writeup
includes a proposal to eliminate the function, I will vote for that, since
I've never understood what use tailp is.
----- End Forwarded Messages -----
∂23-May-88 1512 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 May 88 15:10:25 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA11531; Mon, 23 May 88 15:09:31 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA01843; Mon, 23 May 88 15:06:55 PDT
Received: from localhost by suntana.sun.com (3.2/SMI-3.2)
id AA05142; Mon, 23 May 88 15:01:31 PDT
Message-Id: <8805232201.AA05142@suntana.sun.com>
To: masinter.pa@Xerox.COM
Cc: CL-CLEANUP@Sail.stanford.edu
Subject: Re: Issue: TRACE-FUNCTION-ONLY
In-Reply-To: Your message of 23 May 88 13:43:00 -0700.
<880523-134339-5261@Xerox>
Date: Mon, 23 May 88 15:01:29 -0700
From: kempf@Sun.COM
I agree. Let's drop it.
jak
∂23-May-88 1525 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 23 May 88 15:24:58 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA08740; Mon, 23 May 88 18:23:43 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA13364; Mon, 23 May 88 18:26:48 EDT
Message-Id: <8805232226.AA13364@mist.UUCP>
To: Jon L White <edsel!jonl%labrea.stanford.edu@multimax>
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
In-Reply-To: Your message of Fri, 13 May 88 02:18:34 -0700.
<8805130918.AA25649@bhopal.lucid.com>
Date: Mon, 23 May 88 18:26:41 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Either I oppose both options or an additional proposal is needed. The
problem is that I want the following code to "work".
(DEFVAR MY-ARRAY (MAKE-ARRAY 20 :ELEMENT-TYPE '(SIGNED-BYTE 5)))
;;; Upgrade the storage of the above any way you want
...
(LET ((MY-ARRAY MY-ARRAY))
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5)) MY-ARRAY))
(SETF (AREF MY-ARRAY 10) 127)) ; This is an error. In fact it
; signals an error with the right
; optimization flags.
The SETF obviously conflicts with the local declaration and there is
no reason that even a fairly dumb compiler can't give an error without
reference to the type information that is associated with the global
definition of MY-ARRAY.
I don't think that this is covered by either "for declaration" or "for
discrimination" of the array. It is a local declaration covering
references to elements of the array; unfortunately our current
declaration terminology doesn't handle this distinction.
∂23-May-88 1539 CL-Cleanup-mailer Re: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 May 88 15:37:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 409029; Mon 23-May-88 18:35:47 EDT
Date: Mon, 23 May 88 18:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
To: masinter.pa@Xerox.COM, edsel!jonl@labrea.Stanford.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880523-130454-5166@Xerox>
Message-ID: <19880523223541.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 23 May 88 13:04 PDT
From: masinter.pa@Xerox.COM
Two nits:
A more serious nit is that the issue is misnamed since there is
no Common Lisp facility named "with-open-string". The intended
name was probably "with-output-to-string-append-style".
Aesthetics:
This is a bit silly, but I'm wondering if you are reconstructing QUUX's quote
accurately. The quote I can find (from format-colon-uparrow-scope), is
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr. In
any case, the proposal is to change WITH-OPEN-STRING, not FORMAT. I'd be happier
if it said that this was a minor improvement to the aesthetics of the language
because it made it more consistent.
I agree with your last sentence, also I think the Steele quotation was never
relevant to this issue.
Proposal format:
The preferred format is to use "Cost to Users" and "Cost to Implementors" rather
than "Adoption Cost" and "Implementation Cost" because people were confused by
them.
Agreed.
∂23-May-88 1544 CL-Cleanup-mailer HASH-TABLE-PRINTED-REPRESENTATION
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88 15:44:34 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 15:44:46 PDT
Received: from bhopal.lucid.com by edsel id AA02008g; Mon, 23 May 88 15:33:56 PDT
Received: by bhopal id AA01719g; Mon, 23 May 88 15:37:48 PDT
Date: Mon, 23 May 88 15:37:48 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805232237.AA01719@bhopal.lucid.com>
To: labrea!Dave.Touretzky@CS.CMU.EDU
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Mon, 23 May 88 11:27:58 EDT <361.580404478@DST.BOLTZ.CS.CMU.EDU>
Subject: HASH-TABLE-PRINTED-REPRESENTATION
re: One problem with the currently proposed #H notation is that it provides no
way to specify a rehash-size or rehash-threshold. This should not be a
fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is also
shared by #nA notation.
I think this is a fatal flaw. The fact that *some* complex classes of
arrays also share this fatal flaw is no argument for retaining it. It
is still the case that simple arrays of the more common element types
do not have the flaw; and several years ago there was some discussion
on how to fix other manifestations of the flaw on multi-dimensional arrays.
-- JonL --
∂23-May-88 1605 CL-Cleanup-mailer Re: New issue: STEP-ENVIRONMENT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 16:05:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 16:02:52 PDT
Date: 23 May 88 16:02 PDT
From: masinter.pa@Xerox.COM
Subject: Re: New issue: STEP-ENVIRONMENT
In-reply-to: Eric Benson <edsel!eb@labrea.Stanford.EDU>'s message of Mon, 14 Mar
88 01:06:06 PST
To: edsel!eb@labrea.Stanford.EDU
cc: Moon@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
Message-ID: <880523-160252-5606@Xerox>
While I believe it makes sense for TIME to be a macro, it makes less sense for
STEP to do so.
My notes say that "Moon will separate this out into STEP-ENVIRONMENT and
TIME-ENVIRONMENT", but it seems like make-work to me. I like the proposal
basically in the form that David submitted it.
If we want to add to the Current Practice, you might want to mention that both
STEP and TIME are macros in Lucid Common Lisp (although the macro definition for
STEP baffles me), and that in Xerox Common Lisp, STEP is a special form and TIME
is a macro.
∂23-May-88 1613 CL-Cleanup-mailer Re: HASH-TABLE-PRINTED-REPRESENTATION
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 16:13:19 PDT
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 23 May 88 19:13:00 EDT
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: cl-cleanup@sail.stanford.edu
Subject: Re: HASH-TABLE-PRINTED-REPRESENTATION
In-reply-to: Your message of Mon, 23 May 88 15:37:48 -0700.
<8805232237.AA01719@bhopal.lucid.com>
Date: Mon, 23 May 88 19:12:54 EDT
Message-ID: <602.580432374@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU
Okay, here's a fix for the "fatal flaw" JonL objects to.
The full syntax for #H could be:
#nH(type s t (ki vi)*)
where
"n" is the current size of the hash table, and is optional
"type" is one of EQ, EQL, or EQUAL, and defaults to EQL
"s" is the rehash-size, and is optional
"t" is the rehash-threshold, and is optional
Since this hairs up the printed representation quite a bit,
which interferes with my pedagogical objective for making
hash tables visible objects, I also suggest the following
change:
*PRINT-HASH* may take one of three values:
NIL means use #<HASH-TABLE...> notation
T means use the full #nH syntax; useful for file i/o
:BRIEF means use an abbreviated syntax
The abbreviated syntax leaves out the "n", "s" and "t"
components, and leaves out the type as well if it is EQL.
So in CMU Common Lisp the object #H((FOO 37) (BAR 42))
would print as either
#65H(EQL 101 65 (FOO 37) (BAR 42))
with *PRINT-HASH* set to T, or as
#H((FOO 37) (BAR 42))
with *PRINT-HASH* set to :BRIEF.
The keyword :BRIEF might not be exactly the right one to use, but I'll
leave that for others to decide. I think there was some discussion about
making *PRINT-STRUCTURE* take one of three values, to control when
user-supplied print functions were invoked or not. Does anyone remember
what the third value was supposed to be?
One more clarification:
- even with *PRINT-HASH* set to T, an implementation is free to
not print "n", "s", and "t" components if it chooses. It may
omit "type" as well if the type is EQL. But it must accept
all these components when reading #H expressions.
-- Dave
∂23-May-88 1613 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 23 May 88 16:13:31 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA09358; Mon, 23 May 88 19:12:05 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA13961; Mon, 23 May 88 19:15:06 EDT
Message-Id: <8805232315.AA13961@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
Date: Mon, 23 May 88 19:15:04 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by Pierson 5/23/88, per comments by Moon
Status: For Internal Discussion
The primitive streams have been removed.
Problem description:
CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*. This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.
For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*. A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.
Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as defined
in CLtL.
*STANDARD-INPUT*
This stream is bound to the primary default input of the Lisp
system (e.g. standard input on Unix, SYS$INPUT on VMS). While
this will probably be an interactive terminal or window during
program development, it may well be a data file for a
non-interactive application.
*STANDARD-OUTPUT*
This stream is bound to the primary default output of the Lisp
system (e.g. standard output on Unix, SYS$OUTPUT on VMS). While
this will probably be an interactive terminal or window during
program development, it may well be a data file for a
non-interactive application.
*QUERY-INPUT*
Whenever possible, this stream is bound to an interactive
input source. This may be the same as *initial-input* in a
development environment, or it may be a separate window, or
terminal. If the Lisp system is running under an operating
system such as Aegis which provides a separate error input
source, this stream should probably be bound to that source.
In a non-interactive environment for which no interactive input
is available, reading this stream will always result in EOF.
*ERROR-OUTPUT*
If *initial-query-input* is bound to an interactive input source,
this stream should be bound to the cooresponding interactive output
destination such that *query-io* will work in the expected way if
bound to a two-way stream between these two streams. If the Lisp
system is running under an operating system such as Aegis, Unix,
or VMS which provides a separate error output destination, this
stream should be bound to that destination. In a non-interactive
environment without a separate error destination, this stream should
be bound to the same destination as *initial-output*.
*TRACE-OUTPUT*
The initial binding of *trace-output* is *initial-error-output*
in a non-windowed environment. In a windowed environment,
*trace-output* may start out bound in some other way (e.g. to
a non-existant trace output window which will be automagically
created when output is first done to *trace-output*).
*QUERY-IO*
In a non-windowed environment, the initial binding of
*query-io* is a stream that reads from *initial-query-input*
and writes to *initial-error-output*.
*TERMINAL-IO*
The initial binding of *terminal-io* is the same as *query-io*
in a non-windowed environment. In a windowed environment,
*terminal-io* may refer to a different window than *query-io*
as long as all of these streams refer to windows.
*DEBUG-IO*
The initial binding of *debug-io* is the same as *query-io* in
a non-windowed environment. In a windowed environment,
*debug-io* may refer to a different window than *query-io*
as long as all of these streams refer to windows.
Test Cases/Examples:
(PROGN
(PRINT "Output" *STANDARD-OUTPUT*)
(PRINT "Error" *STANDARD-ERROR*))
In current Common Lisp will write:
------
Output
Error
------
With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.
Rationale:
This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.
Cost to Implementors:
All implementations will have to change to some degree but the changes
will probably be simple and localized.
Cost to Users:
User code which depends on the strict binding hierarchy in CLtL may
have to change.
Cost of non-Adoption:
It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations.
Aesthetics:
Slightly improved because this area becomes better defined.
Discussion:
The repeated mention of windowing environments above seems to be
getting dangerously close to the environmental issues this standard is
supposed to avoid, but Pierson feels that if we have to do more than
leave these areas undefined, we also have to give advanced
environments official permission to do their thing.
Pitman was concerned that the initial version of this proposal didn't
provide a guaranteed way to get back the initial streams after
rebinding, e.g. *standard-io*. The second version of this proposal
offered a solution to that problem which was generally considered too
complex.
∂23-May-88 1646 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88 16:46:13 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 16:46:35 PDT
Received: from bhopal.lucid.com by edsel id AA02280g; Mon, 23 May 88 16:36:48 PDT
Received: by bhopal id AA01992g; Mon, 23 May 88 16:40:40 PDT
Date: Mon, 23 May 88 16:40:40 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805232340.AA01992@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 23 May 88 13:04 PDT <880523-130454-5166@Xerox>
Subject: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
re: nits
Sure, flush any item under "Aesthetics:" -- I don't see it as being important
on this issue.
As to "Adoption Cost" versus "Cost to Users" - I have been following a
hardcopy you passed out some time ago at one of the X3J13 meetings, titled
"Format for proposals to 'clean up' Common Lisp". Since this is now outdated,
perhaps you want to pass out new hardcopies at the next meeting
-- JonL --
∂23-May-88 1723 CL-Cleanup-mailer Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 17:23:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 17:21:56 PDT
Date: 23 May 88 17:21 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
In-reply-to: Dan L. Pierson <pierson%mist@multimax.ARPA>'s message of Mon, 23
May 88 19:15:04 EDT
To: pierson%mist@multimax.ARPA
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880523-172156-5777@Xerox>
Wow. I was about to button "Deliver" on a message poking you on this one...
I must admit that I didn't read earlier versions with much attention. I am
uncomfortable with the imperative style of this proposal (and of CLtL). I can
easily imagine implimentations conforming to the spirit but not conforming to
the letter of this proposal. Suppose, for example, I have a program that records
user input and is able to duplicate it later. The second time I run it, it isn't
an "interactive" input stream, but does this mean I can't legally attach it to
*QUERY-INPUT* because reading from *QUERY-INPUT* must result in end-of-file?
In many multi-processing multi-window environments, the "initial binding" for
*STANDARD-INPUT*, *QUERY-INPUT* differs for each process.
Your latest VERSION makes reference to *INITIAL-INPUT* and *INITIAL-OUTPUT*
still, even though you removed those items from the definition.
*ERROR-OUTPUT*
If *initial-query-input* is bound to an interactive input source,
this stream should be bound to the cooresponding interactive output
destination such that *query-io* will work in the expected way if
bound to a two-way stream between these two streams. If the Lisp
system is running under an operating system such as Aegis, Unix,
or VMS which provides a separate error output destination, this
stream should be bound to that destination. In a non-interactive
environment without a separate error destination, this stream should
be bound to the same destination as *initial-output*.
a) what is *initial-query-input*?
b) what is "the expected way"?
c) what if "*initial-query-input* is bound to an interactive input source" and
also "If the Lisp
system is running under an operating system such as Aegis, Unix,
or VMS which provides a separate error output destination"?
This section gives conflicting requirements, does it not? If you are running
with an operating system that has error output streams but the initial query
input stream isn't it?
*TRACE-OUTPUT*
The initial binding of *trace-output* is *initial-error-output*
what is *initial-error-output*?
what is "automagically"?
etc. etc.
I don't know how to say it more kindly, but I think this is a step backward from
version 2.
∂23-May-88 1727 CL-Cleanup-mailer Re: Issue: SPECIAL-VARIABLE-TEST (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 17:27:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 17:27:34 PDT
Date: 23 May 88 17:27 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SPECIAL-VARIABLE-TEST (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Mon, 7 Mar 88 15:53 EST
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880523-172734-5781@Xerox>
I like this proposal too, and I think it just needs a few edits before it is
ready for release. Wanna make 'em?
∂23-May-88 1741 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 17:41:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 17:38:49 PDT
Date: 23 May 88 17:38 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
line-fold: no
Message-ID: <880523-173849-5795@Xerox>
My notes from the last meeting were "Codify current practice: allowed, read in base 10."
Here 'tis. If it hasn't aged, maybe we have.
!
Issue: SHARPSIGN-PLUS-MINUS-NUMBER
References: #+ (p358), #- (p359), *features* (p448),
Parsing of Numbers and Symbols (p339-342)
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 03/01/87,
Revision 2 by KMP 03/09/87 (address potential numbers)
Version 3 by Masinter 23-May-88, revive
Problem Description:
Features which are not symbols are currently not allowed.
Unfortunately, machine names are desirable as features. Since
some machines are named only by a number (eg, 360, 3600, 8600,
8080, ...) there is no way to use these names as features.
Alternate, less mnemonic feature names, must be contrived.
`Potential numbers' (as described on p341) should be addressed
specifically if only to say that they are still illegal. There
should be no ambiguity about what is legal and what is not.
An example of such a symbol is 68020A .
Proposal (SHARPSIGN-PLUS-MINUS-NUMBER:OK)
Extend the definition of #+ and #- on pp358-359 to say that
integers are allowable as features. Define that the feature-spec
reader binds base to 10 so that people don't have to do #+7020 to
find the 3600 feature in base 8.
In the case of `potential numbers' (as per p341) in a feature
spec, say that they are allowed for use in this context. If the
implementation does not support the syntax in question, it is
permitted to treat the syntax as if it denoted a feature which
was known not to be present. That is, in any implementation where
a potential number which is denoted by a character sequence <X> can
be parsed by the reader as either a number or a symbol, then
#+<X> will skip the next form iff the expression
(MEMBER (LET ((*READ-BASE* 10.)
(*PACKAGE* (FIND-PACKAGE "KEYWORD")))
(READ-FROM-STRING "<X>"))
*FEATURES*)
yields false, without prejudice to decision about whether <X>
denotes a number or a symbol. If <X> cannot be read by the reader
because it is a potential number, then #+<X> will skip the next
form as if any feature <X> might have been intended to denote was
not present.
[We also need to nail down the rules for what package is used in
the feature-spec reader. I've put that in a separate proposal.]
Extend the definition of *features* on p448 to say that it is a
"list of symbols and/or numbers".
Rationale:
There is no deep-rooted reason why numbers shouldn't work.
The current restrictions are somewhat arbitrary. This would
allow arbitrary alphanumeric strings (subject to restrictions
about potential numbers) to be used as identifiers in a
well-defined way.
Current Practice:
Some implementations already allow this (though most probably
do not bind base to 10 -- I've seen some octal feature names).
Other implementations signal an error if they see what they
believe to be an invalid feature name (such as a number).
Cost to implementors:
Changes to implementations not already supporting this feature
would probably be very minor.
Cost to Users:
Some users would view this as an enhancement; others as a bug fix.
I don't think it would be seen in a negative light.
Benefits:
A restriction which seems arbitrary to some people would be removed.
Aesthetics:
No issues not already addressed above.
Discussion:
KMP initiated this proposal and thinks that it would be a
worthwhile extension.
Steele asks about treatment of potential numbers, such as #+68020a .
Revision 2 of this proposal addresses that issue, by explicitly
stating that this is allowed.
Fahlman reluctantly supported version 1 of this proposal since
some implementations support numbers here and since the purpose of
this feature is to allow selection of such implementations. He
wishes people would write Symbolics-3600 rather than 3600 since it
isn't clear that 3600 is meaningful in the abstract. He wants to
see the potential number issue treated, however.
KMP thinks that the problem of meaningfulness is not unique
to numbers. Many feature names with only alphabetic characters
could be likewise criticized. In practice, brevity is important
because AND and OR will greatly increase horizontal size of
feature-spec expressions and often it's desirable to still have
enough room to the right to grind the conditionalized expression.
Dick Gabriel opposed this proposal: "unless there is a compelling
reason to do otherwise, it is best to have as few different rules and
concepts in a language as possible.
Let `#+' represent either `#+' or `#-'. Currently #+<object> can be such
that <object> is a symbol or a boolean expression. I don't see any gain in
expressive power if we extend this to include numbers, yet we've extended
the complexity of the language a little bit.
Furthermore, the examples given are not compelling at all - someday soon
some people will not know what I mean when I say I mailed this message
from a 10.
Symbolics-3600, IBM-360, MC68020A - these are proper machine names and
hence proper feature names.
Finally, an expression like #-3600 looks like an arithmetic expression
or a slip of the TIP for simply -3600."
∂23-May-88 1801 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 18:01:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 17:56:58 PDT
Date: 23 May 88 17:56 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-SUB-METHODS
In-reply-to: Jon L White <edsel!jonl@labrea.Stanford.EDU>'s message of Fri, 12
Feb 88 23:31:35 PST
To: edsel!jonl@labrea.Stanford.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880523-175658-5823@Xerox>
The issue SETF-METHOD-FOR-SYMBOLS is withdrawn, and it is probably confusing to
leave it in the references section. PUSH-EVALUATION-ORDER, however, is relevant
and in fact addresses many of the same issues; however PUSH-EVALUATION-ORDER
does not put any constraints on the GET-SETF-METHOD for functions like LDB and
GETF.
My notes from the last meeting was that this was "in discussion", but no
subsequent discussion has been held. I'd like to see this updated if only to
make it clear that the issues, while related, are not the same as
PUSH-EVALUATION-ORDER.
Nit: spell out names in Edit History, e.g.,
Edit history: Version 1 JonL White & Ken Olum 12-Feb-88
(based on SETF-METHOD-FOR-SYMBOLS)
∂23-May-88 1819 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88 18:18:57 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 18:19:21 PDT
Received: from bhopal.lucid.com by edsel id AA02526g; Mon, 23 May 88 17:10:53 PDT
Received: by bhopal id AA02281g; Mon, 23 May 88 17:14:44 PDT
Date: Mon, 23 May 88 17:14:44 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805240014.AA02281@bhopal.lucid.com>
To: pierson%mist@multimax.arpa
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dan L. Pierson's message of Mon, 23 May 88 18:26:41 EDT <8805232226.AA13364@mist.UUCP>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
re: The SETF obviously conflicts with the local declaration and there is
no reason that even a fairly dumb compiler can't give an error without
reference to the type information that is associated with the global
definition of MY-ARRAY.
I sympathize with your viewpoint entirely, but it is out of the domain of
this proposal. My comments on ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
suggested something similar; but compielr treatment of "declarations" isn't
part of the topic of ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS.
-- JonL --
∂23-May-88 1819 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88 18:19:44 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 18:20:06 PDT
Received: from bhopal.lucid.com by edsel id AA02589g; Mon, 23 May 88 17:27:44 PDT
Received: by bhopal id AA02354g; Mon, 23 May 88 17:31:34 PDT
Date: Mon, 23 May 88 17:31:34 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805240031.AA02354@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 23 May 88 18:35 EDT <19880523223541.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
re: A more serious nit is that the issue is misnamed since there is
no Common Lisp facility named "with-open-string". The intended
name was probably "with-output-to-string-append-style".
No. This issue isn't just about with-output-to-string, but is an attempt
to unify FORMAT and WITH-OUTPUT-TO-STRING. The fact that there is only
one proposal -- to alter with-output-to-string -- doesn't change that,
since I anticipated the possibility of a proposal to change format instead.
re: [Aesthetics:] ... also I think the Steele quotation [about FORMAT] was
never relevant to this issue.
Maybe you missed the humor in Guy's original quote?
-- JonL --
∂23-May-88 1845 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88 18:44:57 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 18:45:21 PDT
Received: from bhopal.lucid.com by edsel id AA02644g; Mon, 23 May 88 17:37:03 PDT
Received: by bhopal id AA02408g; Mon, 23 May 88 17:40:54 PDT
Date: Mon, 23 May 88 17:40:54 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805240040.AA02408@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
Issue: WITH-OPEN-STRING-APPEND-STYLE
References: CLtL, pages 331, 386
Category: CLARIFICATION
Edit history: Version 1, 25-Mar-88 JonL
Version 2, 29-Mar-88 JonL (fix typos; comments by Daniels)
Version 3, 23-May-88 JonL (fix nits raised by Masinter)
Problem description:
CLtL p386 says that FORMATting to a fill-pointer'd string should add
characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that
WITH-OUTPUT-TO-STRING will work "as if using VECTOR-PUSH-EXTEND if the
string is adjustable, and otherwise as if using VECTOR-PUSH". It's very
unlikely that the original authors of these parts intended differing
semantics for these two cases. Furthermore, the semantics for
WITH-OUTPUT-TO-STRING permit the inconspicuous loss of characters
written to the string, since VECTOR-PUSH will just "drop on the floor"
any characters that would go beyond the end.
Proposal (WITH-OPEN-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND):
Change the documentation of WITH-OUTPUT-TO-STRING to be like that under
FORMAT. That is, replace the first sentence of the next-to-last paragraph
on CLtL p331 by:
"If *string* is specified, it must be a string with a fill pointer;
the output is incrementally appended to the string (as if by use of
VECTOR-PUSH-EXTEND)."
Test Case:
(let ((str (make-array 4 :element-type 'string-char :fill-pointer 0)))
(with-output-to-string (s str) (princ "You Luz, Bunkie!" s))
str)
CLtL behaviour will return "You "; proposed behaviour will signal an error.
Rationale:
It's unlikely that the mention of VECTOR-PUSH in CLtL p331 was intended
to suggest that characters could be quietly "dropped on the floor". In
any case, there is no practical or theoretical reason to make FORMAT and
WITH-OUTPUT-TO-STRING act differently on non-adjustable strings.
Current Practice:
VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier
versions implement CLtL. For WITH-OUTPUT-TO-STRING, Xerox Common Lisp
implements CLtL. The question is entirely moot for Symbolics since
it is impossible to create a non-adjustable string, even upon demand.
Cost to Implementors:
Very small.
Cost to Users:
Virtually none.
Benefits:
Less special-casing in the semantics of "printing" to strings.
More conformity with naive expectations about printing to strings.
Aesthetics:
Discussion:
Implementations may want to actually call VECTOR-PUSH, rather than
VECTOR-PUSH-EXTEND, on non-adjustable string in order to test the
result -- nil means an overflow of the total length of the string;
thus they may signal an error more directly related to the problem,
rather than permitting VECTOR-PUSH-EXTEND to complain about a non-
adjustable array. But either way, the semantics is still that of
VECTOR-PUSH-EXTEND: when you get to the end of the string, adjustable
strings are extended, and non-adjustable strings cause error signals.
The proposal is supported by by Andy Daniels of Xerox; and by JonL and
other senior staff at Lucid.
∂23-May-88 2212 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88 22:08:09 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 22:08:34 PDT
Received: from bhopal.lucid.com by edsel id AA03676g; Mon, 23 May 88 21:58:27 PDT
Received: by bhopal id AA04386g; Mon, 23 May 88 22:02:19 PDT
Date: Mon, 23 May 88 22:02:19 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805240502.AA04386@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE
References: CLtL, pages 331, 386
Category: CLARIFICATION
Edit history: Version 1, 25-Mar-88 JonL
Version 2, 29-Mar-88 JonL (fix typos; comments by Daniels)
Version 3, 23-May-88 JonL (fix nits raised by Masinter)
Version 4, 23-May-88 JonL (change issue name -- only 1 proposal)
Problem description:
CLtL p386 says that FORMATting to a fill-pointer'd string should add
characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that
WITH-OUTPUT-TO-STRING will work "as if using VECTOR-PUSH-EXTEND if the
string is adjustable, and otherwise as if using VECTOR-PUSH". It's very
unlikely that the original authors of these parts intended differing
semantics for these two cases. Furthermore, the semantics for
WITH-OUTPUT-TO-STRING permit the inconspicuous loss of characters
written to the string, since VECTOR-PUSH will just "drop on the floor"
any characters that would go beyond the end.
Proposal (WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND):
Change the documentation of WITH-OUTPUT-TO-STRING to be like that under
FORMAT. That is, replace the first sentence of the next-to-last paragraph
on CLtL p331 by:
"If *string* is specified, it must be a string with a fill pointer;
the output is incrementally appended to the string (as if by use of
VECTOR-PUSH-EXTEND)."
Test Case:
(let ((str (make-array 4 :element-type 'string-char :fill-pointer 0)))
(with-output-to-string (s str) (princ "You Luz, Bunkie!" s))
str)
CLtL behaviour will return "You "; proposed behaviour will signal an error.
Rationale:
It's unlikely that the mention of VECTOR-PUSH in CLtL p331 was intended
to suggest that characters could be quietly "dropped on the floor". In
any case, there is no practical or theoretical reason to make FORMAT and
WITH-OUTPUT-TO-STRING act differently on non-adjustable strings.
Current Practice:
VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier
versions implement CLtL. For WITH-OUTPUT-TO-STRING, Xerox Common Lisp
implements CLtL. The question is entirely moot for Symbolics since
it is impossible to create a non-adjustable string, even upon demand.
Cost to Implementors:
Very small.
Cost to Users:
Virtually none.
Benefits:
Less special-casing in the semantics of "printing" to strings.
More conformity with naive expectations about printing to strings.
Aesthetics:
Discussion:
Implementations may want to actually call VECTOR-PUSH, rather than
VECTOR-PUSH-EXTEND, on non-adjustable string in order to test the
result -- nil means an overflow of the total length of the string;
thus they may signal an error more directly related to the problem,
rather than permitting VECTOR-PUSH-EXTEND to complain about a non-
adjustable array. But either way, the semantics is still that of
VECTOR-PUSH-EXTEND: when you get to the end of the string, adjustable
strings are extended, and non-adjustable strings cause error signals.
The proposal is supported by by Andy Daniels of Xerox; and by JonL and
other senior staff at Lucid.
-------------------------------------------------------------------------------
∂24-May-88 0122 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 24 May 88 01:22:16 PDT
Received: by labrea.stanford.edu; Tue, 24 May 88 01:22:41 PDT
Received: from bhopal.lucid.com by edsel id AA04507g; Tue, 24 May 88 01:10:17 PDT
Received: by bhopal id AA04704g; Tue, 24 May 88 01:14:08 PDT
Date: Tue, 24 May 88 01:14:08 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805240814.AA04704@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS
Issue: HASH-TABLE-PACKAGE-GENERATORS
References:
Category: ADDITION
Edit history: Version 1, 23-May-88 JonL
Problem description:
The Iteration subcommittee would like the several iteration proposals to be
writeable in portable Common Lisp code. Unfortunately, the only access to
hash-tables and packages is through MAPHASH and DO-SYMBOLS, neither of which
is satisfactory for building complex iteration clauses.
Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-CREATOR-FUNCTIONS):
Add two new functions as follows, which will create upon demand a
"generator" for the table in question:
MAKE-HASH-TABLE-ITERATION-GENERATOR (hash-table) [Function]
;; Returns a function of no arguments, which iterates over
;; the entries of the argument 'hash-table' and returns three
;; values at each at each iteration:
;; 1. a boolean to indicate no more entries (T says "there are more")
;; 2. the value item (of a <key, value> pair)
;; 3. the key item (of a <key, value> pair)
;; If there are no more entries in the hash-table, then only one value
;; is returned, namely NIL.
MAKE-PACKAGE-ITERATION-GENERATOR (package iteration-type) [Function]
;; First argument is a package (or, a string or symbol
;; coercible to a package); second argument is a symbol among:
;; do-symbols
;; do-all-symbols
;; do-external-symbols
;; do-internal-symbols
;; do-present-symbols {either :internal or :external}
;; Returns a function of no arguments, which iterates over the symbols
;; in the argument 'package' and returns three values at each iteration:
;; 1. a boolean to indicate no more entries (T says "there are more")
;; 2. a symbol (available in the indicated package)
;; 3. the availability type for that symbol, (i.e. one of
;; :internal, :external, or :inherited).
;; If there are no more symbols available from the package, then only one
;; value is returned, namely NIL.
Test Case:
The following function should return T on any hash-table:
(defun test-ht-generator-test (hash-table)
(let ((all-entries '())
(generated-entries '())
(generator-fn (make-hash-table-iteration-generator hash-table))
(unique (list nil)))
(maphash #'(lambda (key value) (push (list key value) all-entries))
hash-table)
(loop ;note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? value key) (funcall generator-fn)
(unless more? (return))
(unless (eql value (gethash key hash-table unique))
(error "Key ~S not found for value ~S" key value))
(push (list key value) generated-entries)))
(unless (= (length all-entries)
(length generated-entries)
(length (union all-entries generated-entries :test #'equal)))
(error "Generated entries and Maphash entries don't correspond"))
t))
The following function should return T on any package:
(defun test-pk-generator-test (package)
(unless (packagep package)
(setq package (find-package package)))
(let ((all-entries '())
(generated-entries '())
(generator-fn (make-package-iteration-generator package 'do-symbols)))
(do-symbols (x package)
(multiple-value-bind (symbol accessibility)
(find-symbol (symbol-name x) package)
(push (list symbol accessibility) all-entries)))
(loop ;note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol accessibility) (funcall generator-fn)
(unless more? (return))
(let ((l (multiple-value-list (find-symbol (symbol-name symbol)
package))))
(unless (equal l (list symbol accessibility))
(error "Symbol ~S not found as ~S in package ~A [~S]"
symbol accessibility (package-name package) l))
(push l generated-entries))))
(unless (and (null (set-difference all-entries generated-entries
:test #'equal))
(null (set-difference generated-entries all-entries
:test #'equal)))
(error "Generated entries and Do-Symbols entries don't correspond"))
t))
Rationale:
The particular way in which hash-tables and packages are represented
need not standardized, or even exposed to the user. Yet a simpler handle
on them is needed for the various iteration paradigms to be written in
portable code. In fact, after these generator-creator functions are put
into an implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial
usages of them; but no _efficient_ use of these current primitives will
provide generator functions.
Current Practice:
Both Symbolics and Lucid already have similar generators in their
own implementations of LOOP.
Cost to Implementors:
Moderate. Possibly a couple days work for an implementation that
has to start completely afresh.
Cost to Users:
None.
Benefits:
Will provide a more primitive root for iterating over hash-tables and
packages; will permit new iteration paradigms to be written in portable code.
Aesthetics:
All other things being equal, it is better to have more general primitives
than less general ones.
Discussion:
This proposal was initiated by Dick Waters, who has ported his OSS iteration
scheme to many Common Lisps; it was who noted that only the lack of reasonable
generator functions prevented all three of the currently discussed iteration
schemes from being truly portable extensions.
The Iteration Subcommittee supports this proposal.
∂24-May-88 0145 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 24 May 88 01:45:20 PDT
Received: by labrea.stanford.edu; Tue, 24 May 88 01:45:34 PDT
Received: from bhopal.lucid.com by edsel id AA04591g; Tue, 24 May 88 01:32:20 PDT
Received: by bhopal id AA04754g; Tue, 24 May 88 01:36:12 PDT
Date: Tue, 24 May 88 01:36:12 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805240836.AA04754@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 23 May 88 17:56 PDT <880523-175658-5823@Xerox>
Subject: Issue: SETF-SUB-METHODS (Version 2)
--text follows this line--
Issue: SETF-SUB-METHODS
References: CLtL pp. 95-96, 99, 105-106, 166
Issue: PUSH-EVALUATION-ORDER
Category: Clarification
Edit history: Version 1 JonL White & Ken Olum 12-Feb-88
(based on problem originally called SETF-METHOD-FOR-SYMBOLS)
Version 2 JonL White 23-May-88 (fix references and spellings).
Problem description:
Tim Daly of IBM noticed that several implementations do not observe
left-to-right order of evaluation in the following form:
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
In these implementations, the side-effect of the setq happens before the
evaluation of the "subforms" necessary to fetch the list being updated.
A typical result is that 'r' = (B 6), 's' = (A 1 B 2 C 3) after the
operation. Surely, it should at least be the case that 's' = (A 1 B 6 C 3),
since the expectation is that the B property in this list is being
(destructively) changed.
Similar problems exist with LDB and CHAR-BIT.
It is not necessary to clarify that left-to-right order of evaluation
semantics should be observed; CLtL p99 is quite explicit about that.
Rather, a distinction needs to be made between the computations involved
in "evaluation" of the subforms, and other computations that are implicit
in the notion of "doing an access" or "doing a store".
The issue PUSH-EVALUATION-ORDER is a clarification about just the point
of the evaluation order for the various subforms to a PUSH; thus there
is a similarity to this issue, but the current one has a much deeper
problem because of the need to call GET-SETF-METHOD during setf macro
expansion.
Proposal: SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Elaborate the documentation of SETF, especially in the case of access
forms whose sub-forms are permitted to be generalized variable references
[and thus which need to call GET-SETF-METHOD during setf macro expansion].
We remember that GET-SETF-METHOD returns the following:
Some temporary variables
A list of value-producing forms
A list of store-variables (normally one).
A storing form.
An accessing form.
Then we want to say that:
Code generated using GET-SETF-METHOD does 2 or 3 of the following
things:
It evaluates the value-producting forms, and binds the temporary
variables to them. This will be called "binding the temporaries."
It evaluates the accessing form to get the old value of the place.
This will be called "doing the access."
It binds the store-variable to a new value and calls the storing form
to install it in the place. This will be called "doing the store."
The forms listed at the top of CLtL p96 permit recursive <place>
specifiers; for each one, we will describe how the sub-recursive
information from GET-SETF-METHOD is used.
LDB:
In a form such as
(SETF (LDB <byte-spec> <place-form>) <value-form>)
the place referred to by the <place-form> must always be both
accessed and updated. Even if the <place-form> refers to a
bignum, the bignum itself will not be modified but rather a new
bignum stored in the <place-form>. Thus this SETF should generate
code to do the following:
1. Evaluate <byte-spec>
2. Bind the temporaries for <place-form>
3. Evaluate <value-form>
4. Do the access to <place-form>
5. Do the store into <place-form> with the given bit-field
replaced with the value from step 3.
If the evaluation of <value-form> in step 3 sets a different
bit-field in the given place then since the access is done later
at step 4 this change will be preserved. See ROTATEF example in
discussion below. Nevertheless the evaluations required for
binding the temporaries are done in step 2, and thus the expected
left-to-right evaluation order is seen.
GETF:
The case of GETF is complicated by the fact that two different
"place" locators are involved: one to use if the specified
indicator is present in the property list, and another if not.
For example, in (SETF (GETF (AREF ... I) 'B) 6), if the I'th slot
of the array is NIL, then that slot must be changed, but if it
contains a list with the property B then only the cons cell with
that property value needs to be changed. This decision cannot be
made at macro-expansion time. It depends entirely on the contents
of the list in question, and so must be delayed until the last
possible moment.
In the first place, GETF should be listed among the other place
forms that admit place forms as one of their arguments. See CLtL
at the bottom of p95 and the top of p96.
More specifically, the expansion of
(SETF (GETF <place-form> <ind-form>) <value-form>)
should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Do the access to <place-form>
[Binding the temporaries and then doing the access is equivalent to
evaluating the <place-form>.]
3. Evaluate <ind-form> [and save the result in a temporary variable].
4. Check whether the value from 2 has the indicator from 3.
If so:
5A. Find cons-cell after indicator from above
6A. Evaluate <value-form>
7A. RPLACA cons-cell from 5A with value from 6A
[In this case, we do not do a store into <place-form>. When
the indicator is already present then the location specifed
by <place-form> doesn't need a new value.]
If not:
5B. Evaluate <value-form>
6B. Do the access to <place-form>, using the temporaries saved from
step 1 [this is not another evaluation -- but it may involve
some non trivial computation, depending on how complex the
access method really is.].
7B. Do the store into <place-form>, again using the temporaries saved
from step 1, setting it to a list with indicator from 3, new value
from 5B, and old list from 6B.
Test Cases:
(setq integer #x69)
(rotatef (ldb (byte 4 4) integer) (ldb (byte 4 0) integer))
Rationale:
As a principle,
(setf (foo-a x) (setf (foo-b x) ...))
should always set both of the "slots" of X, even if these slots are
implemented as bit-fields, getf-properties, and so on.
However,
(setf (foo-a x) (setf (foo-a x) ...))
is an error [that is, what happens is undefined.]
Current Practice:
-- Xerox and Franz already operate on GETF according to this perscription.
-- Symbolics and Lucid differ by always doing a setf on the variable
rather than updating the appropriate cons cell of the property list;
additionally, they fail to connect the new value put into 'r' to the
original property list which was 'r's value initially.
-- HP and VAX Common Lisps update the cons cell, but then set the variable
'r' again, nullifying the effect of the "(setq r nil)" in the <value-form>
computation.
Adoption cost:
Several implementations would require several hours of programmer and
documentation time.
Cost of non-adoption:
Users will think SETF is unnatural in that left-to-right order of
evaluation isn't always observed.
Benefits:
Uniform semantics and portability in the face of recursive "place specifiers"
for SETF. Setf of (LDB ... <place>) and of (GETF <place> ...) will behave
uniformly no matter the nature of the <place>.
Anyone who has copied examples from p105 and p106 will continue to
be able to use them.
Conversion Cost:
This is a clarification of a point not sufficiently elaborated in CLtL.
Symbolics and Lucid are already modifying their interpretation of this
code -- in some way or other.
Esthetics:
See "Cost of non-adoption"
Discussion:
In the case that spurred this discussion,
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
the consequent update is a RPLACA to some list cell -- not a setf of
the variable 'r' -- and thus 'r' should be NIL and 's' should now be
(A 1 B 6 C 3).
There is an interesting parallel between this case for GETF and the
very common mistake made by Lisp programmers with respect to the
function DELETE. How often the complaint is filed that DELETE didn't
do anything when it should have; but in fact the filer simply forgot
that delete can either update some CAR slot of the list originally
given it, or return some tail of the list originally give it, but
not both! E.g.
(setq l '(a a b c d)) ==> (a a b c d)
(delete 'a l) ==> (b c d)
l ==> (a a b c d)
The unwary user thinks that because 'l' is still eq to the original
value that "DELETE didn't do anything". The variability of action
at runtime here parallels the variable choice of location specifier
for (SETF (GETF ...) ...)
A previous proposal to fix this problem was misdirected. It was
phrased as follows:
Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE
Change the result of (get-setf-method 'foo) from
NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO
to
(#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175
The problem with this is that it breaks a relatively simple client of
setf technology:
(setq integer #x69)
(rotatef (ldb (byte 4 4) integer) (ldb (byte 4 0) integer))
no longer does the "right thing". Using the prescription for setf
methods on symbols from CLtL p105, the result of this 'rotatef' is
that integer = #x96; using that given by the TEMPORARY-VARIABLE
proposal leads to either #x99 [or #x66 depending on which order
the implementation chooses to do the actual stores in].
In addition, if 'integer' is replaced by '(car x)' here, then the
behavior is different under the TEMPORARY-VARIABLE proposal because
that only applies to symbols.
Implicitly, two "places" are being specified here to be updated; but
in fact the two places are not independent -- they both involve setq'ing
the variable 'integer'. Furthermore, each store operation implicitly
requires fetching the value from that place in order to combine it
with DPB. It is necessary to delay the accesses until the last moment
before combining with DPB in order to see the side-effects of the
earlier store operations.
∂24-May-88 0204 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 24 May 88 02:04:00 PDT
Received: by labrea.stanford.edu; Tue, 24 May 88 02:04:19 PDT
Received: from bhopal.lucid.com by edsel id AA04640g; Tue, 24 May 88 01:52:43 PDT
Received: by bhopal id AA04794g; Tue, 24 May 88 01:56:36 PDT
Date: Tue, 24 May 88 01:56:36 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805240856.AA04794@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 23 May 88 17:38 PDT <880523-173849-5795@Xerox>
Subject: Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
Nit: the Category: should be ADDITION rather than ENHANCEMENT
The References: section should mention Issue: SHARPSIGN-PLUS-MINUS-PACKAGE.
Between these two issues -- SHARPSIGN-PLUS-MINUS-PACKAGE and this one --
somewhere it should be mentioned that comparison is performed by EQL. Then
the Rationale: section of this issue can be expanded to note that it simply
makes available to the #+ syntax a means of using "features" that would
otherwise not be denotable. More complex "features", such as strings or
cons's still wouldn't be supported in the #+ syntax.
You can also add under the Current Practice: section that Lucid and Symbolics
both implement the proposed behaviour.
-- JonL --
∂24-May-88 0313 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 24 May 88 03:13:48 PDT
Received: by labrea.stanford.edu; Tue, 24 May 88 03:13:52 PDT
Received: from bhopal.lucid.com by edsel id AA04759g; Tue, 24 May 88 02:57:06 PDT
Received: by bhopal id AA04953g; Tue, 24 May 88 03:00:59 PDT
Date: Tue, 24 May 88 03:00:59 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805241000.AA04953@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 23 May 88 13:35 PDT <880523-133528-5237@Xerox>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
I'm sorry I haven't had time to relay the commentary that we've come up
with here at Lucid. Mostly we want to specify that the following situation
is an error; and in fact I think it is reasonable to signal an error:
During the execution of the cleanup forms of an UNWIND-PROTECT a non-local
exit to a point outside of the [dynamic] scope of the UNWIND-PROTECT, but
still within the dynamic scope of of the target of the original non-local
exit succeeds, and the original pending exit is discarded. For example, in
Situation 1, the pending seek for tag FOO is discarded by the second THROW
to BAR and the value 4 is transfered to (CATCH 'BAR ...), which returns 4.
The (CATCH 'FOO ...) then returns the 4 because its first argument has
returned normally. XXX is not printed.
That is, we don't want this case to "succeed", but rather to signal an error.
When we had the discussion at Fort Collins, it was just this point that I
knew moon and I agreed on, and everyone else present disagreed. In fact,
now, there is some more argumentation based on our QLISP implementation that
almost requires this to be "an error" at least.
The operative phrase we have come up with is that
THROW "commits"
That is, when a THROW decides that there is a catch-tag somewhere up there
to catch it, then no intervening UNWIND-PROTECT can function like a
catch barrier. That THROW is "committed" to unwinding the stack at least
up to the tagged point. I think VAX/NIL or MacLisp had such a primitive
called CATCH-BARRIER, or CATCHALL, that would stop any THROW of any tag name
whatsoever; this was considered and rejected for Common Lisp, and for
good reason.
Thus is is OK to "extend the THROW"; meaning that when a THROW to a tag HIGH
is executing, and some unwind-protect cleanup form executes a THROW to tag
HIGHER that is outside the dynamic scope of the catch on tag HIGH, then
that cleanup form code will:
(1) abort it's own local processing
(2) indicate that the throw to tag HIGH will now be extended to HIGHER
(3) continue with the unwinding, up to the next unwind-protect cleanup
or to the final destination HIGHER.
What's not OK is to block a "committed" THROW. Without this restriction,
for example, an "abort" to top-level while runnining the application evaluator
noted below would never succeed; the THROW to FOO from within the cleanup
form would serve as an effect barrier such that no throw can go past it.
(loop
(catch 'foo
(unwind-protect
(Run-application-evaluator)
(throw 'foo t))))
We have actually programmed this up, but it is not in Lucid's current
product.
-- JonL --
∂24-May-88 0602 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 24 May 88 06:02:20 PDT
Received: by labrea.stanford.edu; Tue, 24 May 88 06:02:41 PDT
Received: from bhopal.lucid.com by edsel id AA05174g; Tue, 24 May 88 05:38:48 PDT
Received: by bhopal id AA05224g; Tue, 24 May 88 05:42:41 PDT
Date: Tue, 24 May 88 05:42:41 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805241242.AA05224@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 2)
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Problem description:
CLtL draws a distinction between type-specifiers "for declaration" and
"for discrimination" in the case of array type specifiers -- i.e., those
that are subtypes of ARRAY [this implicitly includes SIMPLE-ARRAY and
VECTOR]. Many people are confused by this situation, which may be one of
the more insidious flaws in the current CL design.
To get a sense of how the community is confused, see the arpanet mailing
list for Common Lisp, in a series of exchanges started on Thu,
17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
under the subject line of "Types in CL". Also see the exchange started
Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
under the subject line of "TYPEP warp implications"
A consequence of this "flaw" is that a variable declared to be of type
<certain-type>
and all of whose assigned objects are created in accord with that type,
still may have *none* of its values ever satisfied by the TYPEP predicate
with that type-specifier. One type-specifier with this property in most
implementations of CL is <certain-type> = (ARRAY (SIGNED-BYTE 5)).
An array created with this type specifier will, depending on the vendor,
either be of typep (ARRAY (SIGNED-BYTE 8)) or (ARRAY T); but (almost)
never of typep (ARRAY (SIGNED-BYTE 5)).
A common feeling among Common Lisp users is that the set of type-specifiers
forms a mathematical language, and the SUBTYPEP relation is generated by some
basic, generating set of relations between these names. People want to see
this language actually describing the implementation in which it is running
-- that the objects of the implementation are a model for that language --
rather than seeing it be limited to some theoretical model which no vendor
bothers to implement. Hence, typep and subtypep should be changed to
reflect what kinds of arrays get built; alternatively, make-array should
be changed to exhibit the distinctions that typep makes.
No one seems to remember just exactly why this "warp" was put into Common
Lisp in the first place; possibly it was added in a mistaken belief that
it would promote portability. ["Mistaken", because the source of non-
portability is the permission to upgrade; if two different implementations
do any upgrading differently, then the effect will be the same kind of
non-portability that results when two different implementations set the
boundary between fixnums and bignums differently.] However, many now feel
it would be much simpler if the real source of the problem that led to
this split up could be resolved. Two proposals will be offered, each
rejecting this odd distinction, but in different ways.
[Notation: because of the inability to show meta- or linguistic variables
in a different typeface, some code examples will use a backquote format;
a form like ",x" will simply mean "substitute the value of x here".
and a form like `(...) will simply mean "evaluate this first, doing
the indicated comma substitutions." Also, the term "type-equivalent"
will be used to denote two types which are each subtypes of the other;
this relation establishes a partition on the set of type-specifiers
into disjoint sets, and members of the same equivalence class are
simply different names for the same type.]
One interesting krinkle in this issue is the question as to whether two
non-EQ but type-equivalent type-specifiers ,aet-x and ,aet-y could give
rise to different array types. Remember that `(array ,aet-x) and
`(array ,aet-y) are type-equivalent only if ,aet-x is type-equivalent
to ,aet-y. But this doesn't say anything about the reverse implication:
does ,aet-x being type-equivalent to ,aet-y necessarily imply that
`(array ,aet-x) is type-equivalent to `(array ,aet-y)? For example,
consider SHORT-FLOAT and SINGLE-FLOAT in an implementation where these
are type-equivalent (because only one internal float type is provided for
Lisp objects -- see CLtL section 2.1.3). One may desire to implement
(ARRAY SHORT-FLOAT) and (ARRAY SINGLE-FLOAT) differently; say, for example
that the former is packed into 16-bit half-words, whereas the latter is
packed into 32-bit words. But for either kind of packing, the result of
AREF is an ordinary "single-float"; the whole point is merely to specify
a packing technique for "packed float" arrays. This "krinkle", however,
will not be addressed by the proposals herein; it should simply be
remembered that the implication goes only one way:
`(array ,aet-x) is-type-equivalent-to `(array ,aet-y)
==>
,aet-x is-type-equivalent-to ,aet-y
Test case:
Let aet-x and aet-y be two distinct type specifiers that are definitely
not type-equivalent in a given implementation, but for which make-array
will return an object of the same primitive type; let this primitive
type be described by `(array ,aet-y). This will be an implementation
dependent search, but in every implementation that the present writer
(JonL) has tested, there will be some such types; often, (signed-byte 5)
and (signed-byte 8) will work. Thus in each case, it should be true that:
(array-element-type (make-array 0 :element-type ',aet-x)) ==> ,aet-y
(array-element-type (make-array 0 :element-type ',aet-y)) ==> ,aet-y
and if such a function exists, then:
(upgrade-array-element-type ',aet-x) ==> ,aet-y
(upgrade-array-element-type ',aet-y) ==> ,aet-y
Now for a first set of tests; to eliminate the distinction between "for
declaration" and "for discrimination" both of the following should be true:
[A]
`(typep (make-array 0 :element-type ',aet-x)
'(array ,aet-x))
`(typep (make-array 0 :element-type ',aet-y)
'(array ,aet-y))
Since `(array ,aet-x) and `(array ,aet-y) are different names for exactly
the same set of objects -- those arrays specialized to hold elements of
type aet-y -- then if the correlation between type-names and sets of objects
is being observed, these names should be type-equivalent. That means that
both of the following tests should be true:
[B]
`(subtypep '(array ,aet-x) '(array ,aet-y))
`(subtypep '(array ,aet-y) '(array ,aet-x))
Additionally, to show that un-equivalent type-specifiers that are upgraded
to the same "element type" should be equivalent as element-type specifiers,
then both the following type tests should be true:
[C]
`(typep (make-array 0 :element-type ',aet-y)
'(array ,aet-x))
`(typep (make-array 0 :element-type ',aet-x)
'(array ,aet-y))
Proposal (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
-- Delete all the documentation that suggests the :element-type argument
to make-array might not be a satisfactory element-type in the type
specifier for the kind of array produced. Particularly, delete the
documentation that permits a difference between type-specifiers "for
declaration" and "for discrimination; primarily this means parts
of the discussion in CLtL, section 4.5, p. 45 and 46. Include a
statement that `(array ,aet) is a suitable type-specifier for the
array made by `(make-array <dims> :element-type ',aet ...).
-- Change the documentation of ARRAY-ELEMENT-TYPE, CLtL p. 291 by deleting
the sentence begining "This set may be larger than the set requested
when the array was created; for example . . ."
-- Add documentation assuring that the resultant array-element-type
from a call to make-array is independent of any argument to make-array
except for the :element-type argument.
-- Introduce a function UPGRADE-ARRAY-ELEMENT-TYPE, which will reveal how
a particular :element-type argument to make-array will be treated.
Semantically, this would be equivalent to:
(defun upgrade-array-element-type (element-type)
(array-element-type (make-array 0 :element-type element-type)))
but it wouldn't have to cons up the 0-element array first. Also,
the presence of this name, as a documented function in the language,
would serve notice that "upgrading" is an important aspect of any real
implementation of CL arrays.
-- Change TYPEP (and SUBTYPEP) so that `(typep x '(array ,aet)) is true
if and only if `(typep x '(array ,(upgrade-array-element-type aet)))
is true.
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and "for
discrimination".
Current Practice:
Every vendor's implementation that the present writer has queried does
some amount of non-trivial "upgrading" [generally, using (signed-byte 5)
as an :element-type argument to make-array will show it]; this includes
LUCID, VAXLISP, SYMBOLICS, FRANZ, and XEROX. Most implementations fail
tests [A] and [C] part 1, but pass tests [A] and [C] part 2; this is a
consequence of implementing the distinction between "for declaration" and
"for discrimination". Lucid and Xerox both pass test [B], and the other
vendors fail it [it may be that these two vendors have implemented a
partial solution for subtypep, with a view to future extensions.]
Cost to Implementors:
Typically, a small amount of work will be required in every vendor's
implementation of TYPEP and SUBTYPEP; some vendors may have already
done the work, but not fully integrated it.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely that
any user code will have to be changed. In fact, it is more likely that some
of the vendors will cease to get bug reports about make-array returning a
result that isn't of "the obvious type".
Cost of non-adoption:
See Benefits.
Benefits:
It will greatly reduce confusion in the user community; the fact that
(make-array <n> :element-type '<aet>) frequently is not of type (array <aet>)
has been very confusing to almost everyone. That is, in practice,
the distinction between "for declaration" and "for discrimination" has
been a disaster.
Esthetics:
Discussion:
Many persons are in favor of the permission to upgrade; but they would not
like to see CL become a language like C where there are a prescribed set of
kinds of arrays that must be implemented (e.g, "int", "long int", "single",
"double" etc), and no others can exist. In short, no one would want to gain
portability at the expense of limiting the language to the architectural
features of the hardware on which it was first implemented.
Many senior implementors at Lucid favor this proposal. In network mail
"Date: Sat, 9 Jan 1988 15:54 EST" Rob McLaughlin favored the gist of this
proposal -- namely that upgrading should be continued, and that TYPEP should
be fixed. Here is an excerpt of his words:
There are two obvious solutions, one of which has already been proposed:
-- Make the mapping more direct. Eliminating "array element type
upgrading" would be an instance of this.
-- Make the mapping explicitly ill-defined in a more useful way.
I think we need to do the latter because the former won't work. I don't
see how to eliminate "array element type upgrading" without creating
more problems [than] we solve. . . .
My conclusion is that it isn't array types that are wrong, it is the
understanding of the meaning of TYPEP that is wrong.
One possible criticism of this proposal is that it hinders portability by
exposing an implementation dependent facet, namely the "upgrading" function.
But the kind of portabililty achieved by a programmer ignorant of the
realities of array implementations -- that only a finite number of array
type classes are really implemented efficiently in any particular CL
implementation -- would be a very pyrrhic victory to say the least. The
kinds of attention a programmer would have to pay to these array type
boundaries is the same kind of attention he now has to pay to the
fixnum/bignum boundary (i.e., arithmetic that is doable in unit time, and
that which requires tens to hundreds of units of time).
This proposal arises from focusing on type specifiers as names for
collections of objects, and on SUBTYPEP as being "subsetp" on collections
of objects.
-- The second paragraph of CLtL p11 makes it clear that "data types" are
just sets of objects; subsequent discussion makes it clear that the
second argument to TYPEP (a type specifier) is a name for some such
set, and that there may be several distinct names specifying the same
set (or type). The first paragraph of section 6.2.1 on page 72 says
that TYPEP is a set membership test, and SUBTYPEP is a subset test.
-- The first two paragraphs of section 4.5, on page 45, describe a
permission for what may be called "element-type upgrading" on arrays;
the documentation for ARRAY-ELEMENT-TYPE on page 291 also makes it
clear that a conforming implementation is permitted to "collapse"
array element types into some more limited set of types, providing
that the array returned by make-array is at most an "upgrade". The
array types STRING and BIT-ARRAY are excluded from upgrading.
For example, depending on how primitive arrays are actually implemented,
(make-array <dims> :element-type '(signed-byte 5))
and
(make-array <dims> :element-type '(signed-byte 8))
might legitimately create arrays specialized to hold exactly the same set of
objects. The only constraint seems to be that that (array (signed-byte 8))
be the most specific type *** in that implementation *** which can hold
all the arrays made by (make-array <dims> :element-type '(signed-byte 5) ...).
In this case, we say that the array element type has been upgraded from
(signed-byte 5) to (signed-byte 8), and we imply that there is no particular
special provisions for arrays of element type, say, (signed-byte 6).
By the bulletted paragraphs above, (array (signed-byte 5)) and
(array (signed-byte 8)) are in fact names for exactly the same
set of objects.
However pages 45 and 46 go at length to specify that these two different
names for the same set of objects must be treated differently by TYPEP
and SUBTYPEP. This seems to "warp" the utility of TYPEP since it puts
it at variance with the fundamental principle: "SUBTYPEP means subsetp".
Proposal (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:FLUSH-UPGRADING)
-- Delete all the documentation that suggests the :element-type argument
to make-array might not be a satisfactory element-type in the type
specifier for the kind of array produced. Particularly, delete the
documentation that permits a difference between type-specifiers "for
declaration" and "for discrimination; primarily this means parts
of the discussion in CLtL, section 4.5, p. 45 and 46. Include a
statement that `(array ,aet) is a suitable type-specifier for the
array made by `(make-array <dims> :element-type ',aet ...). Include
also a statement that if `(array ,aet-x) and `(array ,aet-y) are
type-equivalent, then it must be the case that ,aet-x and ,aet-y are
also type-equivalent.
-- Change the documentation of ARRAY-ELEMENT-TYPE, CLtL p. 291 by deleting
the sentence begining "This set may be larger than the set requested
when the array was created; for example . . ."
-- Change the implementation of arrays so that a canonical member of
the equivalence class around the :element-type argument is always
remembered; ARRAY-ELEMENT-TYPE should return this canonical member.
Rationale:
This makes for maximum portability; type specifiers are "remembered"
exactly as the user typed them in (up to type-equivalence transformations).
Current Practice:
No vendor implements this.
Cost to Implementors:
Array implementations would have to be changed in every vendor; for some,
this could be an enormous amount of work. In some implementations, the
"cheapest" primitive arrays might become considerably more costly. Since
arrays seem to be at the base of every Common Lisp system, the effects of
this change could be widespread, and costly to fix.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely that
any user code will have to be changed. However, knowing what :element-type
specifiers are implemented efficiently will likely still be of concern to
most vendor's clients.
Benefits:
Being in love with portability means never having to say you're sorry
about TYPEP.
Esthetics:
Discussion:
The test case is, unfortunately, not relevant to this proposal, since it
presumes that some non-trivial upgrading is going on. In particular,
there will be no "two, distinct type specifiers ,aet-x and ,aet-x that are
definitely not type-equivalent, but for which
(array-element-type (make-array 0 :element-type ',aet-x)) ==> ,aet-y"
Many people are in favor of this proposal, at least initially. See the
arpanet interchanges mentioned above.
One senior implementor at Lucid has favored this proposal.
It may be desirable to introduce a new function CANONICAL-TYPE of one
argument, which takes a type-specifier into a canonical type-specifier
for that type-equivalence class.
∂24-May-88 0707 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 May 88 07:06:54 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Tue, 24 May 88 10:03:14 EDT
Received: by kali.think.com; Tue, 24 May 88 10:03:11 EDT
Date: Tue, 24 May 88 10:03:11 EDT
From: gls@Think.COM
Message-Id: <8805241403.AA10491@kali.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: masinter.pa@xerox.com, edsel!jonl@labrea.stanford.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 23 May 88 18:35 EDT <19880523223541.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
Date: Mon, 23 May 88 18:35 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
...
Date: 23 May 88 13:04 PDT
From: masinter.pa@Xerox.COM
...
This is a bit silly, but I'm wondering if you are reconstructing
QUUX's quote accurately. The quote I can find (from
format-colon-uparrow-scope), is ``Absolutely none. We're talking
about FORMAT here.'' -- Guy L. Steele Jr. In any case, the proposal
is to change WITH-OPEN-STRING, not FORMAT. I'd be happier if it said
that this was a minor improvement to the aesthetics of the language
because it made it more consistent.
I agree with your last sentence, also I think the Steele quotation was never
relevant to this issue.
...
"Relevance: Absolutely none. We're talking about Steele here."
--Quux
∂24-May-88 0746 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 May 88 07:45:51 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Tue, 24 May 88 10:43:38 EDT
Received: by kali.think.com; Tue, 24 May 88 10:43:34 EDT
Date: Tue, 24 May 88 10:43:34 EDT
From: gls@Think.COM
Message-Id: <8805241443.AA10546@kali.think.com>
To: edsel!jonl@labrea.stanford.edu
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Tue, 24 May 88 03:00:59 PDT <8805241000.AA04953@bhopal.lucid.com>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Date: Tue, 24 May 88 03:00:59 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
...
What's not OK is to block a "committed" THROW. Without this restriction,
for example, an "abort" to top-level while runnining the application evaluator
noted below would never succeed; the THROW to FOO from within the cleanup
form would serve as an effect barrier such that no throw can go past it.
(loop
(catch 'foo
(unwind-protect
(Run-application-evaluator)
(throw 'foo t))))
...
But the very fact that you can run an arbitrary computation implies that
you can effectively block a THROW. For example, I can rewrite the loop
shown above as:
(labels ((again () (unwind-protect
(Run-application-evaluator)
(again))))
(again))
Admittedly this is likely to cause net stack growth in any implementation
I can think of, but semantically it is equivalent.
Another point: what good is signalling an error? It will give handlers a
chance to run, but is the error allowed to break out without invoking the
cleanup forms anyway?
--Guy
∂24-May-88 0809 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 2)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 24 May 88 08:08:52 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 24 May 88 11:09:42 EDT
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 2)
In-reply-to: Your message of Tue, 24 May 88 05:42:41 -0700.
<8805241242.AA05224@bhopal.lucid.com>
Date: Tue, 24 May 88 11:09:29 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
One minor typographical correction: it's "Rob MacLachlan", not "Rob
McLaughlin".
I also favor the "Unify Upgrading" option.
-- Scott
∂24-May-88 0906 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 24 May 88 09:06:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191831; Tue 24-May-88 12:05:59 EDT
Date: Tue, 24 May 88 12:06 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8805240814.AA04704@bhopal.lucid.com>
Message-ID: <19880524160601.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 24 May 88 01:14:08 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Problem description:
The Iteration subcommittee would like the several iteration proposals to be
writeable in portable Common Lisp code. Unfortunately, the only access to
hash-tables and packages is through MAPHASH and DO-SYMBOLS, neither of which
is satisfactory for building complex iteration clauses.
A laudable goal, but...
Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-CREATOR-FUNCTIONS):
Add two new functions as follows, which will create upon demand a
"generator" for the table in question....
...this technique "can't" work, because of locking issues, especially in
systems that have a garbage collector that can change the hash codes of
objects. You need to be able to wrap something around the whole iteration,
not merely have a function that performs the next step in the iteration.
....
Rationale:
The particular way in which hash-tables and packages are represented
need not standardized, or even exposed to the user. Yet a simpler handle
on them is needed for the various iteration paradigms to be written in
portable code. In fact, after these generator-creator functions are put
into an implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial
usages of them; but no _efficient_ use of these current primitives will
provide generator functions.
You haven't brought out the major reason for using a generator function,
which is so that multiple iterations can be performed in parallel. Many
of the iteration proposals, including LOOP and OSS, allow a programmer to
specify an iteration that iterates simultaneously over the elements of
a hash table and a range of integers, or even over the elements of two
hash tables. Making the advance-to-next-state primitive available is
necessary in order to be able to call this primitive twice on two different
hash tables; no nesting of calls to MAPHASH can perform such a simultaneous
iteration.
Current Practice:
Both Symbolics and Lucid already have similar generators in their
own implementations of LOOP.
I don't think you've looked at Symbolics' LOOP in a couple years. It
used to work the way you describe, but the way it works now is
different. It does have a generator function, but it also wraps the
whole thing in a macro, which expands into a generic function invocation
with two arguments: the hash table, and a closure of the body of the
iteration. There is no need for a standard function to create the
generator, since it is simply passed to the body as an argument. Note:
the body closure is called once, and iterates inside itself; it is not
called repeatedly, the way the functional argument to maphash is.
This is for hash-tables, but packages can be treated similarly.
Here's a relevant code extract:
;;; table must be a hash table.
;;; generator-var is bound to a generator function, which takes no arguments.
;;; Each time the generator function is called, it returns the next entry of the
;;; hash table, expressed as three values: the value, the key, and a flag.
;;; The flag is nil if the table has been exhausted, otherwise it is the
;;; next generator function to use (in all implemented cases, the generator
;;; function remains constant, but this provides the flexibility to let it change).
;;; When the flag is nil, the first two values are meaningless.
;;; The values returned by with-table-elements are the values returned by the body.
(defmacro with-table-elements ((table generator-var) &body body)
`(with-table-elements-1 ,table #'(lambda (,generator-var) ,@body)))
(defgeneric with-table-elements-1 (table function)
(declare (downward-funarg function)))
I have no objection to sending you more of the code if you want to see it,
but I doubt that it would be illuminating.
∂24-May-88 1021 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 24 May 88 10:20:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191842; Tue 24-May-88 13:20:07 EDT
Date: Tue, 24 May 88 13:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8805240502.AA04386@bhopal.lucid.com>
Message-ID: <19880524172010.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve of WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND.
One comment:
Current Practice:
VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier
versions implement CLtL. For WITH-OUTPUT-TO-STRING, Xerox Common Lisp
implements CLtL. The question is entirely moot for Symbolics since
it is impossible to create a non-adjustable string, even upon demand.
The last sentence is not really true. For example, the following
signals an error, rather than inconspicuously dropping characters:
(setq s1 (make-string 10))
(setq s2 (make-array 10 :displaced-to s1 :element-type 'string-char))
(adjustable-array-p s2) => nil
(with-output-to-string (s s2 :index i)
(loop repeat 20 do (write-char #\c s)))
I would change the current practice to say Symbolics Genera 7.2
implements the proposal (I did not check Symbolics CLOE).
∂24-May-88 1201 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 2)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 24 May 88 12:01:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191861; Tue 24-May-88 15:01:03 EDT
Date: Tue, 24 May 88 15:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-SUB-METHODS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8805240836.AA04754@bhopal.lucid.com>
Message-ID: <19880524190108.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 24 May 88 01:36:12 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
I have read this proposal carefully and I generally approve the approach
of SETF-SUB-METHODS:DELAYED-ACCESS-STORES, however it needs some more work.
The test cases are inadequate (easily corrected), and the proposal is
incoherent in the sense that what it proposes for LDB and what it
proposes for GETF are not consistent, I think. Also modify-macros
such as INCF are involved with this issue as well. Comments follow.
The forms listed at the top of CLtL p96 permit recursive <place>
specifiers; for each one, we will describe how the sub-recursive
information from GET-SETF-METHOD is used.
You left out MASK-FIELD and CHAR-BIT. I assume you mean for MASK-FIELD
to do the same as LDB; you should say so explicitly. The steps for
CHAR-BIT should be written out explicitly since the arguments are not
the same as for LDB.
In a form such as
(SETF (LDB <byte-spec> <place-form>) <value-form>)
the place referred to by the <place-form> must always be both
accessed and updated.
This assumes that zero-bit bytes may not be optimized out. We could
either say that, or say that it is unspecified whether the <place-form>
is updated if the value is not changed. The value could be unchanged
because the byte has zero width or because the value being stored is
equal to the current value. I mildly prefer the former (see analogous
issue with GETF below).
I agree with your step by step explication of SETF of LDB (omitted
from this reply).
The case of GETF is complicated by the fact that two different
"place" locators are involved: one to use if the specified
indicator is present in the property list, and another if not.
For example, in (SETF (GETF (AREF ... I) 'B) 6), if the I'th slot
of the array is NIL, then that slot must be changed, but if it
contains a list with the property B then only the cons cell with
that property value needs to be changed.
I strongly disagree with this. I think it's wrong to specify that
SETF of GETF does not store into the <place> if the value that would
be stored there happens to be EQ to what is already there. Common Lisp
should either leave it unspecified, or require that the store always
take place (I prefer the latter). Some might argue that requiring the
store always to take place eliminates a potential performance optimization,
but I suspect that it is more efficient to do the store than to check
whether it needs to be done.
The reasons it matters whether the store happens when the value isn't
changing are twofold. First, there is the example in the problem statement
for this issue, which leaves a different value in the variable R if
the store is optimized out when the property is already present. Second,
the store can involve calling a user-defined function which might have
other side-effects. This can happen with DEFSETF and is even more likely
with CLOS use of SETF that invokes methods. I think it's better to say
that a SETF always stores into <place>, even if the value being stored is
EQ to what is already there, and even if SETF also does other side-effects.
The general rules that I would propose to appear in the documentation
for SETF of a function whose argument is a <place> would be either:
Evaluations are performed left to right.
The <place> is not read until all evaluations have been performed.
The <place> is always written.
or:
Evaluations are performed left to right.
The <place> is read at the time it would be read if
the <place-form> were evaluated.
The <place> is always written.
For choosing between these two possible sets of rules, see discussion below.
More specifically, the expansion of
(SETF (GETF <place-form> <ind-form>) <value-form>)
should generate code....
Instead of what JonL proposed, I prefer the following:
1. Bind the temporaries for <place-form>
2. Evaluate <ind-form>
3. Evaluate <value-form>
4. Do the access to <place-form>
5. Use the results from 2, 3, and 4 to modify the property list
6. Do the store into <place-form> of the updated property list
Deferring the access to <place-form> until after all the evaluations is
consistent with what JonL proposed for LDB. So is only accessing
<place-form> once. However, is the behavior this produces intuitive?
See test case below.
Test Cases:
(setq integer #x69)
(rotatef (ldb (byte 4 4) integer) (ldb (byte 4 0) integer))
This test case is inadequate, since it does not specify what the
intended result is. May I suggest adding:
integer => #x96
assuming that that is the result you intend to propose as correct.
This test case is also inadequate since no test cases for the other
affected functions were included. May I suggest:
(setq integer #x69)
(setf (mask-field (byte 4 4) integer) (incf integer)) => #x6A
integer => #x6A
(setf (mask-field (byte 4 4) integer) (ash (incf integer) 4)) => #x6B0
integer => #xBB
(setq l (list #x69))
(rotatef (ldb (byte 4 4) (car l)) (ldb (byte 4 0) (car l)))
l => (#x96))
(setq char (make-char #\A 1)) => #\c-A
(rotatef (char-bit char :control) (char-bit char :meta))
char => #\m-A
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6)) => 6
r => (b 6) ;result from what I proposed above
s => (a 1 b 2 c 3)
r => nil ;JonL's result
s => (a 1 b 6 c 3)
r => (a 1 b 6 c 3) ;result from always storing, but doing
s => (a 1 b 6 c 3) ;the access in the usual order
(setq a (vector 1))
(incf (aref a 0) (incf (aref a 0)))
(aref a 0) => 4 ;result if access happens after eval
(aref a 0) => 3 ;result if access happens in usual order
I guess the char-bit test case won't run in implementations that don't
have both of those char bits.
For the getf test case I have shown three possible results, and for
the incf test case I have shown two. We have to decide which we want.
Current Practice:
-- Xerox and Franz already operate on GETF according to this perscription.
-- Symbolics and Lucid differ by always doing a setf on the variable
rather than updating the appropriate cons cell of the property list;
additionally, they fail to connect the new value put into 'r' to the
original property list which was 'r's value initially.
I can't figure out what you mean by the above. Symbolics Genera 7.2
certainly does update the appropriate cons cell of the property list and
certainly does modify s's value; it produces the third of the three
results I've listed for the test case.
-- HP and VAX Common Lisps update the cons cell, but then set the variable
'r' again, nullifying the effect of the "(setq r nil)" in the <value-form>
computation.
Discussion:
There is an interesting parallel between this case for GETF and the
very common mistake made by Lisp programmers with respect to the
function DELETE. How often the complaint is filed that DELETE didn't
do anything when it should have; but in fact the filer simply forgot
that delete can either update some CAR slot of the list originally
given it, or return some tail of the list originally give it, but
not both!
Not true. For example, (delete 'a '(a a b a d)) does both (assuming
I correctly understand what you meant by the typo "update some CAR slot").
I agree that there is a parallel.
A previous proposal to fix this problem was misdirected. It was
phrased as follows:
Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE
Agreed.
Implicitly, two "places" are being specified here to be updated; but
in fact the two places are not independent -- they both involve setq'ing
the variable 'integer'. Furthermore, each store operation implicitly
requires fetching the value from that place in order to combine it
with DPB. It is necessary to delay the accesses until the last moment
before combining with DPB in order to see the side-effects of the
earlier store operations.
Agreed, except that the test cases above show that it's not so clear-cut
that we want to delay the accesses.
Anyone have any ideas of the direction out of this morass?
∂24-May-88 1210 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 24 May 88 12:10:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191865; Tue 24-May-88 15:09:54 EDT
Date: Tue, 24 May 88 15:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880523-173849-5795@Xerox>
Message-ID: <19880524191004.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve SHARPSIGN-PLUS-MINUS-NUMBER:OK. By the way, I think
it simplifies the language, rather than complicating it.
∂24-May-88 1339 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 24 May 88 13:39:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191912; Tue 24-May-88 16:39:26 EDT
Date: Tue, 24 May 88 16:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8805211305.AA08320@bhopal.lucid.com>
Message-ID: <19880524203927.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 21 May 88 06:05:42 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
re: I don't understand the justification for introducing the function
UPGRADE-ARRAY-ELEMENT-TYPE. There are plenty of other type operators
missing from Common Lisp, why put in just this one?
Because of the prevalence of user confusion about "upgrading" in arrays;
this gives him a reasonable query mechanism for a very common problem. It
also, quite likely, reflects a functionality that each implementation will
have to provide for itself anyway.
I don't buy either of those arguments. That's just my personal opinion.
re: You don't list what type specifiers it applies to. I assume you mean
to include SIMPLE-ARRAY and VECTOR in addition to ARRAY. What about
COMPLEX?
I didn't think that explicit mention of SIMPLE-ARRAY and VECTOR was
necessary, as they are subtypes of ARRAY. However, it can't hurt to
put in the one sentence clarification. I did not mean COMPLEX; I only
meant to cover arrays. Perhaps COMPLEX could be "swept under the same
rug"; do you think it is a good idea to do so?
I'd like to see COMPLEX included, too. I think it would be a mistake to
fix only half the problem, especially if later someone fixes the rest of
the problem in an incompatible way. Are you going to introduce
UPGRADE-COMPLEX-ELEMENT-TYPE?
re: Your proposal assumes without stating it explicitly that
(array-element-type (make-array dimensions :element-type element-type
options...))
is independent of the values of dimensions and options. I believe this
to be true of most implementations, but see nothing in CLtL that requires
it.
Yes, I think this assumption about independence is right.
....I'd be curious
to know how an implementation can do, say, displacement of a vector to
a multi-dimensional array with conformal element type, and vice-versa.
There could be more element types for displaced arrays than for simple
arrays. I am not going to argue that it's important that Common Lisp
continue to allow that, especially if no implementations depending on it
are discovered. I'm reasonably sure that all Symbolics implementations
have the same menu of element types for all kinds of arrays, but I don't
know that much about any other implementations.
In any case, assumptions like this must be stated explicitly, especially
for their effect on the cost of adopting the proposal.
re: The proposal is much too long and contains too many digressions.
There are two proposals here, you know; the verbal discussion in Palo Alto
on March 13 suggested we would need two (and maybe this was a first?). I
have had commentary on it from folks at Lucid, but I note that CL-CLEANUP
has been effectively moribund for the six weeks prior to the submission of
this proposal. So I don't think the lack of other public replies means it
is any more difficult to comprehend than the other long proposals (such as,
"setf-function-vs-macro").
On the other hand, I agree that is is unfortunately long; I don't easily see
what can be deleted without opening up loopholes for someone to argue against.
Do you have some specific suggestions as to what could be elided without
inviting more criticism?
I think the second proposal should be deleted before it leaves the Cleanup
committee. It probably makes sense to leave it in for now. I think some of
the digressions about interesting krinkles and so forth aren't needed even now,
but certainly should be deleted before it leaves the Cleanup committee. I
think all but the first paragraph of the problem description could be deleted
or moved into the discussion section at the end.
∂24-May-88 1342 CL-Cleanup-mailer Re: Issue: STEP-ENVIRONMENT
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 24 May 88 13:42:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191914; Tue 24-May-88 16:42:31 EDT
Date: Tue, 24 May 88 16:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: STEP-ENVIRONMENT
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880523-160252-5606@Xerox>
Message-ID: <19880524204240.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 23 May 88 16:02 PDT
From: masinter.pa@Xerox.COM
While I believe it makes sense for TIME to be a macro, it makes less sense for
STEP to do so.
My notes say that "Moon will separate this out into STEP-ENVIRONMENT and
TIME-ENVIRONMENT", but it seems like make-work to me. I like the proposal
basically in the form that David submitted it.
If we want to add to the Current Practice, you might want to mention that both
STEP and TIME are macros in Lucid Common Lisp (although the macro definition for
STEP baffles me), and that in Xerox Common Lisp, STEP is a special form and TIME
is a macro.
I don't think I can find the time to do any more work on this one.
If someone else would like to, I certainly won't complain.
∂24-May-88 1356 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 24 May 88 13:55:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191919; Tue 24-May-88 16:55:27 EDT
Date: Tue, 24 May 88 16:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8805211213.AA08230@bhopal.lucid.com>
Message-ID: <19880524205536.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 21 May 88 05:13:49 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
re: Well, wait a minute. Either :IMPORT-FROM does exactly the same thing as
:IMPORT in terms of creating symbols that did not already exist, in
which case removing :IMPORT doesn't solve anything, . . .
That isn't quite right. :IMPORT explicitly requires you to put symbols
in the source code, and it is the reading in of that code (with its
liklihood of having bogon-producing :: syntax) that causes the lossage.
For example, if your file had in it:
(defpackage my-package (:import 'uluz::bunkie))
then the damage to the ULUZ package is done by the reader long before
defpackage or :import ever has a chance to muck things up.
I suggest removing :IMPORT because the :IMPORT-FROM format can be made
to work given only the symbol-name (not the symbol itself, with it's home
package known); there would be no other way to indicate the package
information for :IMPORT if you used only symbol-names as arguments.
None of this addresses my comment. If the user insists on referencing a
non-exported symbol of the ULUZ package, what is the difference between
referencing (and hence creating) that symbol while reading an argument
to the :IMPORT option, and referencing (and hence creating) that symbol
while obeying the :IMPORT-FROM option?
Oddly enough, looking back over the mail on this issue, it seems as though
KMP wanted to suggest exactly the same thing, in a messaged dated
Sat, 12 Mar 88 19:14 EST. Your disagreement with him was phrased as
follows:
I disagree because of alphabetic case issues in strings. Note that in
these symbol/string arguments, the symbol is being used only for its
name, so there are never any package issues. . . .
Oh, yes, I had forgotten the argument for allowing symbols as arguments
when strings would do, so people can write their code in lower case
even though Common Lisp is an upper case language. Good point.
but this argument fails to account for the fact that the damage is done
by the reader, when it is required to read in symbols, rather than by
any action of defpackage itself.
See above.
re: Do you think :IMPORT-FROM should be changed
to be like single-colon package prefix?
Well, only in that it not create an entry *** in some other package *** where
one doesn't already exist; I wouldn't necessarily want it to require the
symbol to be external. Yes, I think it would be a tremendous step forward
in helping to prevent one of the most obscure nits that even an experienced
package user can fall into.
Okay, you're proposing that :IMPORT-FROM be changed to do something
different from any of the previous proposals, namely to call
FIND-SYMBOL instead of INTERN or the secret version of INTERN that
single-colon uses. I wish you had come right out and said so.
The problem I see with this is that if the user hasn't already done
something to create the symbol, he gets an error. Thus the problem
we were trying to address with DEFPACKAGE, of having to load everything
in a certain order or it doesn't work, wouldn't be completely solved.
It might be worth it.
Then again, maybe this whole problem is a non-problem. Maybe anybody
who uses the double-colon package prefix is just asking to lose and
nothing we do can change that.
∂24-May-88 1400 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 24 May 88 14:00:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191920; Tue 24-May-88 17:00:11 EDT
Date: Tue, 24 May 88 17:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 19 May 88 14:18 EDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <19880524210021.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with both DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER:ALLOW-ZERO
and DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR.
∂24-May-88 1402 CL-Cleanup-mailer ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 24 May 88 14:02:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191921; Tue 24-May-88 17:02:01 EDT
Date: Tue, 24 May 88 17:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 19 May 88 14:20 EDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <19880524210207.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED.
∂24-May-88 1425 CL-Cleanup-mailer issue: FUNCTION-TYPE (version 11)
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 24 May 88 14:25:24 PDT
Date: 24 May 88 17:20:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: issue: FUNCTION-TYPE (version 11)
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
19-May-88, Version 10 by Masinter, (modify as per X3J13)
24-May-88, Version 11 by van Roggen
(don't coerce lists, relax SYMBOL-FUNCTION reqs)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
Proposal FUNCTION-TYPE:X3J13-MARCH-88
This proposal is basically the STRICT-REDEFINITION proposal of version 9
of this issue, correcting a few typos, changing section 2E as
agreed upon at X3J13 March 1988, allowing symbols but not lists to
be FUNCALLed or APPLYed, and relaxing some SYMBOL-FUNCTION/FBOUNDP
requirements.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any FUNCTION subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
whose CAR is LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Clarify FUNCALL and APPLY and all Common Lisp functions that
take functional arguments such that they accept objects that
are coerceable to a FUNCTION as the functional argument. It
is an error if the functional argument is not coerceable to a
FUNCTION.
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that FBOUNDP must return true for a symbol naming a macro or
a special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. SETF of SYMBOL-FUNCTION requires a FUNCTION as the new value.
It is an error to set the SYMBOL-FUNCTION of a symbol to a
symbol or a list or the value returned by SYMBOL-FUNCTION on
the name of a macro or a special form.
5c. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type FUNCTION.
6a. (COERCE symbol 'FUNCTION) extracts the SYMBOL-FUNCTION of the
given symbol, signalling an error if the symbol is not FBOUNDP or
if the symbol names a macro or a special-form.
6b. Implementations are free to extend the set of objects which
are coerceable to a FUNCTION, particularly lambda-expressions
for compatibility. However, such extensions will not be portable.
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the expansion interface hook by
MACROEXPAND-1.
Rationale:
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
This proposal is a compromise between a CONSERVATIVE proposal (which left
FUNCTION alone and introduced a new type), and a STRICT-REDEFINITION proposal,
which incompatibly changed not only the FUNCTION type and SYMBOL-FUNCTION,
but also the behavior of FUNCALL, APPLY and functions with functional
arguments.
For compatibility reasons symbols are still acceptable to FUNCALL et al.,
but for aesthetic reasons lambda-expressions (lists whose CAR is LAMBDA
and whose CADR is a list) are no longer acceptable.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is true for values
returned by FUNCTION, symbols that are FBOUNDP, and lambda expressions.
In some implementations, (TYPEP x 'FUNCTION) is true only for values
returned by FUNCTION.
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations have exactly the
semantics described in this proposal.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or as some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The changes to FUNCTIONP and the FUNCTION type declaration are relatively easy
to deal with.
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell, or expected lists back, will
have to change. Such code was already not portable, however, since some
implementations signal an error when this is done.
The original STRICT-REDEFINITION proposal required users to deal with
the use of symbols and lambda-expressions as functional arguments. However
this proposal is compatible with current CLtL definition in the use of
symbols, which would be the hardest change to make. There are probably
relatively few uses of lambda-expressions as ``functions'', which can
be dealt with by (EVAL `(FUNCTION ,lambda-expresssion)).
Benefits:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
The type hierarchy would be simplified.
This proposal brings Common Lisp slightly closer to Scheme and the
work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with the FUNCTION type.
Aesthetics:
This proposal improves the aesthetics of the language.
Lambda-expressions do not obey the normal, apparent scoping rules because
free variables cannot refer to lexical bindings. This is because
coercing a list to a function would mean (EVAL `(FUNCTION ,list)).
The following code does -not- count the number of nodes in a graph:
(LET ((COUNTER 0))
(TRAVERSE-THING '(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
since it is not the same as
(LET ((COUNTER 0))
(TRAVERSE-THING #'(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
which does pass around a closure incrementing the LET variable.
(These examples assume COUNTER wasn't PROCLAIMed SPECIAL.)
Making the coercion of lambda-expressions to functions explicit with
the use of EVAL will encourage less confusing code and also highlight
that use of EVAL.
Discussion:
This issue has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. Two proposals were circulated at the March 1988 meeting of X3J13;
this version is the result of discussions at that meeting. It is a compromise
between the conflicting goals of backward compatibility, flexibility in the
language, and simple semantics.
This proposal does not address the issue of when coercion to functions occur.
For example, it is allowed to write
(MAPCAR 'FROB my-list)
It is not specified when the coercion of FROB to its SYMBOL-FUNCTION
occurs. For example,
(DEFUN FROB (X)
(WHEN (> X 0) (SETF (SYMBOL-FUNCTION 'FROB) #'(LAMBDA (X) NIL)))
T)
(MAPCAR 'FROB '(-1 -1 1 1))
may return different results if MAPCAR coerces its functional argument
once rather than for each element. This may require a separate
cleanup issue.
------
∂24-May-88 1436 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 1)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 24 May 88 14:36:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191931; Tue 24-May-88 17:35:14 EDT
Date: Tue, 24 May 88 17:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-PRETTY-PRINT (version 1)
To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8804132032.AA00868@mist.UUCP>
Message-ID: <19880524213523.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with FORMAT-PRINT-PRETTY:YES
[I assume this name is a typo and FORMAT-PRETTY-PRINT:YES
was the intended proposal name]
∂25-May-88 0726 CL-Cleanup-mailer Re: issue: FORMAT-PRETTY-PRINT (version 1)
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 25 May 88 07:25:55 PDT
Date: 25 May 88 10:07:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Re: issue: FORMAT-PRETTY-PRINT (version 1)
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Does this propose that ~D (for instance) binds *PRINT-ESCAPE* to NIL or
to T? VAX LISP currently binds *PRINT-ESCAPE* to NIL for ~D et al.
[Of course it also binds *PRINT-RADIX* and *PRINT-BASE*.]
---Walter
------
∂25-May-88 0747 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 25 May 88 07:47:36 PDT
Date: 25 May 88 10:45:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
I'm in favor of the proposal.
I don't understand these arguments about "unstoppable" loops. Since
Common Lisp doesn't address asynchronous operations, it seems to me
just plain (LOOP) is an "unstoppable" loop. Let each implementation
have additional means of handling these cases; they would want to be
implementation-dependent anyway, since I don't think anyone is about
to agree on any particular set of "debugging" primitives.
Another thing that bothers me about trying to declare either situations
1 or 2 as errors is that whether or not "it is an error" depends on
whether there was a THROW in progress from the protected-form of the
UNWIND-PROTECT. Unless there's a way for the clean-up code to tell
if it is being executed due to a THROW rather than a return, I don't
see how reliable code can be written.
---Walter
------
∂25-May-88 1202 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 25 May 88 12:02:34 PDT
Received: by labrea.stanford.edu; Wed, 25 May 88 12:02:54 PDT
Received: from bhopal.lucid.com by edsel id AA11835g; Wed, 25 May 88 11:50:03 PDT
Received: by bhopal id AA01088g; Wed, 25 May 88 11:54:01 PDT
Date: Wed, 25 May 88 11:54:01 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805251854.AA01088@bhopal.lucid.com>
To: gls@think.com
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: gls@Think.COM's message of Tue, 24 May 88 10:43:34 EDT <8805241443.AA10546@kali.think.com>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
re: re: But the very fact that you can run an arbitrary computation implies
that you can effectively block a THROW. For example, I can rewrite the
loop shown above as:
(labels ((again () (unwind-protect
(Run-application-evaluator)
(again))))
(again))
No, this isn't true. If you interrupt out of AGAIN and "abort" to toplevel,
the the barrier is broken. The part of my emmendation to the proposal that
makes this clear is:
". . . that cleanup form code will:
(1) abort it's own local processing
. . ."
As a previous example on this topic showed, unless an implementation just
happened to have an "interrupt exposed" critical section, it would be
possible that every attempt to interupt the computation and "abort" to
a higher level would be blocked and cause re-entry into the cleanup
form again.
As someone has said previously, this proposal isn't about proscriptions
against writing looping code -- e.g., (prog () A (go A)) -- but about the
dynamic scoping relations between THROW and UNWIND-PROTECT cleanups. [Well,
if they didn't say exactly that, they should have!]
re: Another point: what good is signalling an error? It will give handlers a
chance to run, but is the error allowed to break out without invoking the
cleanup forms anyway?
The main reason for signalling an error is to help the luser find a possibly
very obscure error that isn't syntatically visible. The presentations of
sample losing code have all been lexically in the same scope; but the error
is one of poor intermixture of dynamic components.
But back to your point: "... but is the error allowed to break out without
invoking the cleanup forms anyway?". Yes, most certainly. This suggests
an implementation technique, which I would have described in more detail
had there been time (and space!). That is, an "unwind-protect frame,
on a stack" is converted into a "cleanup-form frame" during the execution
of its cleanup forms; if that execution completes normally, then the
"cleanup-form frame" is simply popped off the stack, and the next unwind-
protect frame is found and "serviced"; but an attempt to throw through
that "cleanup-form frame" [a non-local exit, in the original terminology
of this proposal] will either (1) simply flush the frame, thereby effecting
a "break out" of the "cleanup-form frame", because the throw target is merely
extending a previously "committed" throw, or (2) signal an error because the
throw target is scoped erroneously as described in my addendum.
-- JonL --
∂25-May-88 1321 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 25 May 88 13:19:58 PDT
Received: by labrea.stanford.edu; Wed, 25 May 88 13:20:19 PDT
Received: from bhopal.lucid.com by edsel id AA12174g; Wed, 25 May 88 13:08:49 PDT
Received: by bhopal id AA01499g; Wed, 25 May 88 13:12:47 PDT
Date: Wed, 25 May 88 13:12:47 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805252012.AA01499@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 24 May 88 12:06 EDT <19880524160601.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS
re: Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-CREATOR-FUNCTIONS):
Add two new functions as follows, which will create upon demand a
"generator" for the table in question....
...this technique "can't" work, because of locking issues, especially in
systems that have a garbage collector that can change the hash codes of
objects. You need to be able to wrap something around the whole iteration,
not merely have a function that performs the next step in the iteration.
You are probably thinking of only one of the several ways to implement
EQ-type hash-tables. Lucid has a technique that guarantees iteration over
the contents which the table had at the time the iteration function is
created [this is almost always acceptable, since even maphash calls it "an
error" to alter the table while the iteration is in progress (except for
the trivial exception, which works in both cases)]. At worst, this technique
causes a copying of the hash-table upon a relocating garbage collection,
or when first making an entry that would otherwise be "locked-out". [Just
to clear up a point: Lucid's implementation will normally re-order "in place"
when necessary due to changing hash-codes, and do that only "lazily".]
Thus there is no absolute need to provide locking for iteration.
On the other hand, locking of global databases, for whatever purposes, is
a laudable goal. I still don't think it is required for iteration to work
in the same cases that it works in for MAPHASH. But if you think that
Symbolics' system will be compromised unless explicit interlocking is done
during hash-table or package iteration, then perhaps the necessary thing to
do is to provide context-independent locking mechanisms. Something like
the dynamically-scoped macro 'with-table-elements', but perhaps with a
broader utility?
re: You haven't brought out the major reason for using a generator function,
which is so that multiple iterations can be performed in parallel.
Well, I tried to say so in the following words:
Unfortunately, the only access to hash-tables and packages is through
MAPHASH and DO-SYMBOLS, neither of which is satisfactory for building
complex iteration clauses.
but it you'd like to see "complex iteration clauses" fleshed out in more
detail, then just adding the paragraph of your note would be fine, don't
you think?
re: I don't think you've looked at Symbolics' LOOP in a couple years. It
used to work the way you describe, but the way it works now is
different. It does have a generator function, but it also wraps the ...
Right, I had looked at version 6+ some time ago.
Incidentally, Lucid's implementation of packages uses the same hash-table
mechanism given to the Common-Lisp user, but with a private, undocumented
:type argument. At one time, SpiceLisp had a totally independent version
of hash-tables built into their package code. The locking issue on packages
is, to my way of thinking, much more critical than that for hash-tables in
general. But the more general solution is, of course, to provide locking
mechanisms for the hash-table implementation and let the package code use
those mechanisms where appropriate.
-- JonL --
∂25-May-88 1618 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 25 May 88 16:18:40 PDT
Received: by labrea.stanford.edu; Wed, 25 May 88 16:19:04 PDT
Received: from bhopal.lucid.com by edsel id AA13379g; Wed, 25 May 88 16:01:32 PDT
Received: by bhopal id AA02123g; Wed, 25 May 88 16:05:30 PDT
Date: Wed, 25 May 88 16:05:30 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805252305.AA02123@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 24 May 88 15:01 EDT <19880524190108.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: SETF-SUB-METHODS (Version 2)
re: You left out MASK-FIELD and CHAR-BIT.
We certainly didn't mean to. We intended to cover these cases with the words:
Elaborate the documentation of SETF, especially in the case of access
forms whose sub-forms are permitted to be generalized variable references
[and thus which need to call GET-SETF-METHOD during setf macro expansion].
as indicated in the preamble:
"... when the accessing technique isn't fully specified just by looking at
the get-setf-method of <access-fun>. The class of such <access-fun>'s
is enumerated in CLtL, at the top of p96, except that GETF is missing
from that list [we propose that it be added there in the next manual].
but, yes, it looks like they need to be mentioned explicitly.
re: ... test cases ...
Glaaag, I can't believe we left out the result value of the LDB test case!
(maybe it just looked so obvious!). All of your additions to the test
case part for LDB, MASK-FIELD and CHAR-BITS seem ok to me.
re: The case of GETF is complicated by the fact that two different
"place" locators are involved: one to use if the specified
indicator is present in the property list, and another if not.
For example, in (SETF (GETF (AREF ... I) 'B) 6), if the I'th slot
of the array is NIL, then that slot must be changed, but if it
contains a list with the property B then only the cons cell with
that property value needs to be changed.
I strongly disagree with this. I think it's wrong to specify that
SETF of GETF does not store into the <place> if the value that would
be stored there happens to be EQ to what is already there. Common Lisp
should either leave it unspecified, or require that the store always
take place (I prefer the latter).
It doesn't specify that the store into <place> *can't* take place; rather
it only specifies which steps *must* happen, and it purposesly omits saying
anything about the situation where stores aren't required to maintain
the property-list semantics. However, your objection:
"[disagree about] not store into the <place> if the value that would
be stored there happens to be EQ to what is already there ..."
isn't an interesting one; rather the crux of the matter is, I believe, the
one you imply about always storing into the <place> form regardless of
whether or not the indicator is found on the property list. I hope I'm
not mis-paraphrasing your objections, but I think "... EQ to what is already
there..." is a red herring and the relevant issue is "regardless of whether
or not the indicator is found on the property list."
What you want is for the <place-form> to be updated as the ultimate and last
step in a setf-of-getf, precisely because the evaluation of <value-form>
may itself have altered <place-form> during the in-between steps. This
suggestion would permit setf-of-getf to have side-effecting behaviour
parallel to setf-of-ldb; and based on that similarity as a simplification,
then we agree with your change to the proposal [after all, we can't find
anyone who really cares what the test case values for setf-of-getf return
-- only that all CL implementations present the same order of evaluation].
In fact, that is how Lucid's implementation currently works, so we also have
some selfish motivation in altering the proposal accordingly.
re: ... DELETE ...
Not true. For example, (delete 'a '(a a b a d)) does both (assuming
I correctly understand what you meant by the typo "update some CAR slot").
I agree that there is a parallel.
I see. We'll try fix the wording so as not to be misleading.
Version 3 of this proposal will be forthcoming, but I fear that we've
missed the USMailing-out deadline. It'll be up to Larry.
-- JonL --
∂25-May-88 1634 CL-Cleanup-mailer mail deadline
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 May 88 16:34:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 25 MAY 88 16:29:25 PDT
Date: 25 May 88 16:28 PDT
From: masinter.pa@Xerox.COM
Subject: mail deadline
To: CL-Cleanup@sail.stanford.edu
Message-ID: <880525-162925-1261@Xerox>
I'm afraid the US mail deadline is hopeless; its my fault for not getting to
CLeanup work for two months. My tentative plan is to mail out electronic copies
by the end of next week, and bring hardcopy with me. Votes may not be
"official", but I think we will make as much progress.
∂26-May-88 1146 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 2)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 26 May 88 11:46:01 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA01475; Thu, 26 May 88 14:44:34 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA18531; Thu, 26 May 88 11:56:21 EDT
Message-Id: <8805261556.AA18531@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: FORMAT-PRETTY-PRINT (version 2)
Date: Thu, 26 May 88 11:56:20 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: FORMAT-PRETTY-PRINT
References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 3/4/88
Version 2 by Pierson 5/24/88 (fix name typo)
Status: For Internal Discussion
Problem description:
The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively. The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.
Proposal (FORMAT-PRETTY-PRINT:YES):
The ~A and ~S FORMAT operators (and the ~B, ~D, ~E, ~F, ~G, ~$, ~O,
~R, and ~X FORMAT operators when they encounter a non-numeric value)
are required to treat all *PRINT-foo* variables the same as PRINC and
PRIN1 respectively. [[ Yes, this is a bit broader than the title, but
if we're going to clarify this we might as well do the whole job. I
don't think any of the other variables are likely to be controversial.]]
Test Cases/Examples:
(LET ((TEST '(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL TEST TEST))
This should print four copies of the above lambda expression. The
first pair should appear identical and the second pair should appear
identical. The only difference between the two pairs should be the
absence of string quotes in the second pair. Note that this example
won't work as written if the proposal FUNCTION-TYPE:STRICT-REDEFINITION
is accepted.
Rationale:
FORMAT should interact with the *PRINT-foo* variables in a predictable
way. This proposal is one of the two simplest possible definitions
and provides the most flexibility to the user.
Current practice:
Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.
Cost to Implementors:
While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications. How does a pretty-printing ~A
interact with MINCOL, etc? How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?
Cost to Users:
Truely portable code shouldn't be affected because existing
implementations are inconsistent. Despite this, there are probably a
number of user programs in non-complying which will have to change
whichever way this is decided.
Cost of non-Adoption:
The interaction of FORMAT and the *PRINT-foo* variables (especially
pretty printing) will remain undefined. This will continue to make
portable Common Lisp programming harder than it need be.
Benefits:
Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.
Aesthetics:
The interaction between two related parts of output will be clarified
in a simple way.
Discussion:
Pierson feels that this is important because the ease of implementing
major system interfaces with FORMAT can unintentionally lead to less
flexibility for the user compared to an old-style PRIN1/PRINC/TERPRI
implementation. This clarification would generate some up front work
but would make it harder for people to accidentally create restrictive
interfaces.
∂26-May-88 1146 CL-Cleanup-mailer Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 26 May 88 11:46:29 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA01485; Thu, 26 May 88 14:44:59 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA18493; Thu, 26 May 88 11:40:05 EDT
Message-Id: <8805261540.AA18493@mist.UUCP>
To: masinter.pa%Xerox.COM@multimax
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
In-Reply-To: Your message of 23 May 88 17:21:00 -0700.
Date: Thu, 26 May 88 11:40:03 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Wow. I was about to button "Deliver" on a message poking you on this one...
Yes, well, there seem to be a lot of holes around nowdays...
I must admit that I didn't read earlier versions with much attention.
I am uncomfortable with the imperative style of this proposal (and of
CLtL). I can easily imagine implimentations conforming to the spirit
but not conforming to the letter of this proposal. Suppose, for
example, I have a program that records user input and is able to
duplicate it later. The second time I run it, it isn't an
"interactive" input stream, but does this mean I can't legally attach
it to *QUERY-INPUT* because reading from *QUERY-INPUT* must result in
end-of-file?
This seems to be what Moon wanted at the March meeting. I sort of
doubt that it will meet universal acceptance, but promised to move
back in this direction for the third draft.
In many multi-processing multi-window environments, the "initial
binding" for *STANDARD-INPUT*, *QUERY-INPUT* differs for each
process.
This is not specifically addressed, though you could stretch a point and
claim that all of the window loopholes cover it. I'll think about
adding something, but probably not to today's draft. The problem is
that the original goal of supporting the "standard streams" of the
underlying environment breaks down completely in a multi-window,
multi-process Lisp, if only because you don't bring up all that hair
just to run a shell-level batch job.
Your latest VERSION makes reference to *INITIAL-INPUT* and *INITIAL-OUTPUT*
still, even though you removed those items from the definition.
...
etc. etc.
Sorry about all that, it'll teach me to re-edit a proposal quickly. A
new version will be going out today with all of that garbage fixed up.
I don't know how to say it more kindly, but I think this is a step
backward from version 2.
The cleanliness of the proposal certainly was a step backward, sorry.
The content is harder. I've never expected this version to be
accepted unchanged, so I've saved a copy of version 2. Should I put
out a new draft with both versions as alternate proposals? I'm really
reluctant to cop out that way without a very good reason.
It sounds to me like you would be happier with the original "specify
as little as possible" approach which was rejected in the first
proposal.
∂26-May-88 1146 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 26 May 88 11:46:33 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA01497; Thu, 26 May 88 14:45:19 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA18524; Thu, 26 May 88 11:55:13 EDT
Message-Id: <8805261555.AA18524@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
Date: Thu, 26 May 88 11:55:11 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by Pierson 5/23/88, per comments by Moon
Version 4 by Pierson 5/26/88, clean up
Status: For Internal Discussion
The primitive streams have been removed, completely this time.
Problem description:
CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*. This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.
For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*. A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.
Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as defined
in CLtL.
*STANDARD-INPUT*
This stream is bound to the primary default input of the Lisp
process (e.g. standard input on Unix, SYS$INPUT on VMS). While
this will probably be an interactive terminal or window during
program development, it may well be a data file for a
non-interactive application.
*STANDARD-OUTPUT*
This stream is bound to the primary default output of the Lisp
process (e.g. standard output on Unix, SYS$OUTPUT on VMS). While
this will probably be an interactive terminal or window during
program development, it may well be a data file for a
non-interactive application.
*QUERY-INPUT*
Whenever possible, this stream is bound to an interactive
input source. This may be the same as *STANDARD-INPUT* in a
development environment, or it may be a separate window, or
terminal. If the Lisp system is running under an operating
system such as Aegis which provides a separate error input
source, this stream should probably be bound to that source.
In a non-interactive environment for which no interactive input
is available, reading this stream will always result in EOF.
*ERROR-OUTPUT*
If *QUERY-INPUT* is bound to an interactive input source, this
stream should be bound to the cooresponding interactive output
destination. If the Lisp system is running under an operating
system such as Aegis, Unix, or VMS which provides a separate
error output destination, this stream should be bound to that
destination. In a non-interactive environment without a
separate error destination, this stream should be bound to the
same destination as *STANDARD-OUTPUT*.
*TRACE-OUTPUT*
The initial binding of *TRACE-OUTPUT* is *ERROR-OUTPUT*
in a non-windowed environment. In a windowed environment,
*TRACE-OUTPUT* may start out bound in some other way (e.g. to
a non-existant trace output window which will be automatically
created when output is first done to *TRACE-OUTPUT*).
*QUERY-IO*
In a non-windowed environment, the initial binding of
*QUERY-IO* is a stream that reads from *QUERY-INPUT*
and writes to *ERROR-OUTPUT*.
*TERMINAL-IO*
The initial binding of *TERMINAL-IO* is the same as *QUERY-IO*
in a non-windowed environment. In a windowed environment,
*TERMINAL-IO* may refer to a different window than *QUERY-IO*
as long as all of these streams refer to windows.
*DEBUG-IO*
The initial binding of *DEBUG-IO* is the same as *QUERY-IO* in
a non-windowed environment. In a windowed environment,
*DEBUG-IO* may refer to a different window than *QUERY-IO*
as long as all of these streams refer to windows.
Test Cases/Examples:
(PROGN
(PRINT "Output" *STANDARD-OUTPUT*)
(PRINT "Error" *STANDARD-ERROR*))
In current Common Lisp will write:
------
Output
Error
------
With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.
Rationale:
This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.
Cost to Implementors:
All implementations will have to change to some degree but the changes
will probably be simple and localized.
Cost to Users:
User code which depends on the strict binding hierarchy in CLtL may
have to change.
Cost of non-Adoption:
It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations.
Aesthetics:
Slightly improved because this area becomes better defined.
Discussion:
The repeated mention of windowing environments above seems to be
getting dangerously close to the environmental issues this standard is
supposed to avoid, but Pierson feels that if we have to do more than
leave these areas undefined, we also have to give advanced
environments official permission to do their thing.
Pitman was concerned that the initial version of this proposal didn't
provide a guaranteed way to get back the initial streams after
rebinding, e.g. *standard-io*. The second version of this proposal
offered a solution to that problem which was generally considered too
complex.
Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists. While this version partially
implements Moon's view by expressing all of these in terms of
*QUERY-INPUT* and *ERROR-OUTPUT* and requiring *QUERY-INPUT* to return
EOF in a non-interactive environment, this view is controversial.
Pierson is currently neutral on this question.
Masinter notes that:
``In many multi-processing multi-window environments,
the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
differs for each process.''
This proposal provides very weak support for such environments by
refering to "the Lisp process" rather than "the Lisp system" when
defining *STANDARD-OUTPUT* and *STANDARD-INPUT*. Some additional
verbiage may be needed to cover this case.
∂26-May-88 1647 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 26 May 88 16:47:20 PDT
Received: by labrea.stanford.edu; Thu, 26 May 88 16:47:37 PDT
Received: from bhopal.lucid.com by edsel id AA19011g; Thu, 26 May 88 16:06:03 PDT
Received: by bhopal id AA06041g; Thu, 26 May 88 16:10:07 PDT
Date: Thu, 26 May 88 16:10:07 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
Message-Id: <8805262310.AA06041@bhopal.lucid.com>
To: pierson@multimax.arpa
In-Reply-To: Dan L. Pierson's message of Thu, 26 May 88 11:55:11 EDT <8805261555.AA18524@mist.UUCP>
Cc: cl-cleanup@sail.stanford.edu
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
> Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
> *DEBUG-IO*) should fail to work in a non-interactive environment where
> nothing like a terminal exists.
That seems like a needless restriction that could be rather painful
in particular instances.
What if I'm running a test suite that is trying to verify the
behavior of the debugger?
What if I want to redirect *termainal-io* through files to evade
limitations imposed by a given environment? (E.g., simulating TENEX
detach/attach in Unix, or running on a box with NFS but no terminal.)
What if I have a complex applications that started life being highly
interactive via *query-io*, and now has stabilized to the point where
people want to invoke it via canned scripts?
I'm having trouble imagining a situation where I would want
*terminal-io* to fail simply because Lisp was guessing that the
environment wasn't interactive.
jlm
∂26-May-88 1939 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 4)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 26 May 88 19:39:32 PDT
Received: by labrea.stanford.edu; Thu, 26 May 88 19:39:48 PDT
Received: from bhopal.lucid.com by edsel id AA19962g; Thu, 26 May 88 19:25:45 PDT
Received: by bhopal id AA06629g; Thu, 26 May 88 19:29:49 PDT
Date: Thu, 26 May 88 19:29:49 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805270229.AA06629@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: SETF-SUB-METHODS (Version 4)
Issue: SETF-SUB-METHODS
References: CLtL pp. 95-96, 99, 105-106, 166
Issue: PUSH-EVALUATION-ORDER
Category: CLARIFICATION
Edit history: Version 1: JonL White & Ken D. Olum 12-Feb-88
(based on problem originally called SETF-METHOD-FOR-SYMBOLS)
Version 2: JonL White 23-May-88 (fix references and spellings).
Version 3: JonL White 25-May-88
(Incorporate suggestions of moon:
Add explicit details for CHAR-BIT and MASK-FIELD.
Alter proposed semantics for setf-of-getf to accord with
current practice, rather than as suggested by original
correspondent; add defense for this interpretaton.
Delete references to the misleading, retracted proposal
[SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE]
Retracted misleading references about DELETE.
Clarify and unify overall presentation.)
Version 4: JonL White & Ken D. Olum 26-May-88 (final insights!)
Problem description:
Tim Daly of IBM noticed an anomaly in that several implementations do not
appear to observe left-to-right order of evaluation in the following form:
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
In these implementations, the side-effect of the setq appears to happen before
the evaluation of the place form (getf r 'b) which is necessary to fetch the
list being updated. A typical result is 'r' = (B 6), 's' = (A 1 B 2 C 3)
after the operation.
There is a similar problem with SETF's over LDB, MASK-FIELD, and CHAR-BIT.
It is not necessary to clarify that left-to-right order of evaluation
semantics should be observed; CLtL p99 is quite explicit about that.
Rather, a distinction needs to be made between the computations involved
in "evaluation" of the subforms, and other computations that are implicit
in the notion of "doing an access" or "doing a store".
There are implications in this issue for the "read-modify-write" macros
such as INCF, DECF, PUSH, POP, and REMF, as well as for PSETF, SHIFTF, and
ROTATEF. However, a good underpinning for SETF over the basic accessors
is all that is necessary in order to assure correct treatement for the
more compound forms.
The issue PUSH-EVALUATION-ORDER is a clarification about just the point
of the evaluation order for the various subforms to a PUSH; thus there
is a similarity to this issue, but the present issue has a much deeper
problem because of the need to call GET-SETF-METHOD during setf macro
expansion.
Proposal: SETF-SUB-METHODS:DELAYED-ACCESS-STORES
We propose to elaborate the documentation of SETF, specifically in the case
of access forms whose sub-forms are permitted to be generalized variable
references [and which thus need to call GET-SETF-METHOD during setf macro
expansion] in the ways described below.
Here are the specific steps for interpreting a SETF of an access function
which itself admits a generalized variable as an argument. Remember, first,
that GET-SETF-METHOD returns the following:
-- Some temporary variables
-- A list of value-producing forms
-- A list of store-variables (normally one).
-- A storing form.
-- An accessing form.
The code produced as the macro expansion of such a SETF form must essentially
do the following major steps:
** It evaluates the value-producing sub-forms, in left-to-right order, and
binds the temporary variables to them. This will be called "binding the
temporaries."
** It "reads the value" from the generalized variable using the supplied
accessing form, to get the "old value"; this will be called "doing the
access." [Note that this is done after all the evaluations of the
preceeding step, including any side-effects they may have.]
** It binds the store-variable to a new value, and then installs this
new value into the generalized variable using the supplied "storing
form". This will be called "doing the store."
In particular, we must emphasize the fact that "reading the value" of a
generalized variable reference is not part of the series of evaluations
that must be done in left-to-right order. Compare this with the statement
of CLtL p99, third from last paragraph, "... the generalized variables are
both read and written in the same reference. Preserving the source
program order of evaluation and the number of evaluations is equally
important."
Note carefully that in the (degenerate?) case when a generalized variable
is in fact simply a program variable, then there are no sub-forms to be
considered "value-producing" forms; in fact, "doing the access" for such
a generalized variable (i.e. a program variable) is functionally the
same as evaluating it. This explains why the behaviour that Tim Daly
observed is at first perplexing -- the "do the access" step has the same
semantics as an evaluation step, even though it is done after all the
prescribed evaluations.
The place-specifier forms listed at the top of CLtL p96 permit admit (other)
place-specifiers as arguments; during the SETF expansion of these forms, it
is necessary to call GET-SETF-METHOD in order to figure out how the inner,
nested generalized variable must be treated. We require that GETF be
listed among these forms, since it must have a sub-recursive <place> specifier
[however, there is no Common Lisp function serving as a pseudo-update function
for it, the way DPB serves for LDB]. See CLtL at the bottom of p95 and the
top of p96.
For each place-specifier form with a sub-recursive place specifier, we will
now describe how the information from GET-SETF-METHOD is used.
CHAR-BIT:
In a form such as:
(SETF (CHAR-BIT <place-form> <bit-name>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not to a character object itself.
Thus this SETF should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Evaluate <bit-name> (and bind into a temporary)
3. Evaluate <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form>, with the given bit-name of the
character fetched in step 4 changed to reflect the value from step 3.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different "bit" of the character --
then the change of the bit denoted by <bit-name> will be to that altered
character, because the "access" step is done after the <value-form>
evaluation. See example 1 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
LDB:
In a form such as:
(SETF (LDB <byte-spec> <place-form>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not to any object of type integer.
Thus this SETF should generate code to do the following:
1. Evaluate <byte-spec> (and bind into a temporary)
2. Bind the temporaries for <place-form>
3. Evaluate <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form> with the given bit-field of the integer
fetched in step 4 replaced with the value from step 3.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different bit-field of the integer --
then the change of the bit-field denoted by <byte-spec> will be to that
altered integer, because the "access" step is done after the <value-form>
evaluation. See example 2 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
MASK-FIELD:
This case is the same as LDB in all essential aspects.
GETF:
In a form such as:
(SETF (GETF <place-form> <ind-form>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not necessarily to the particular list
which is the property list in question.
Thus this SETF should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Evaluate <ind-form> (and bind into a temporary)
3. Evaluate the <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form> with a possibly-new property list
obtained by combining the values from steps 2, 3, and 4.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different named property in the list,
then the change of the property denoted by <ind-form> will be to that
altered list, because the "access" step is done after the <value-form>
evaluation. See example 7 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
Note that this phrase "possibly-new property list" treats the
implementation of property lists as a "black box" -- it can mean that
the former property list is somehow destructively re-used, or it can
mean partial or full copying of it. This is like the question of REMOVE
or DELETE -- do you copy or do you destructively alter. Since the answer
could go either way, the treatment of the resultant value for the
"possibly-new property list" must proceed as if it were a different copy
needing to be stored back into the generalized variable.
Test Cases:
1. (setq char (make-char #\A 1)) ==> #\Control-A
(rotatef (char-bit char :control)
(char-bit char :meta)) ==> <dont care>
char ==> #\Meta-A
;; It's as if you start with #\Control-A, and then first turn the
;; :control bit off, because the :meta bit was originally off; and
;; then to the resulting #\A, you add the :meta bit since the
;; :control bit was originally on.
Note, however, that if an implementation doesn't support both of these
character 'bits', then this test case would have to be re-written to
reference two independent bits actually supported. If an implementation
supports fewer than two independent character bits, then this test case
is entirely moot.
2. (setq integer #x69) ==> #x69
(rotatef (ldb (byte 4 4) integer)
(ldb (byte 4 0) integer)) ==> <dont care>
integer ==> #x96
;; This very-realistic example is simply trying to swap two
;; independent bit fields in an integer. Note that the generalized
;; variable of interest here is just the (possibly local) program
;; variable 'integer'.
3a.(setq l1 (setq l2 (list #x69))) ==> (#x69)
(setf (ldb (byte 4 4) (car l1))
(ldb (byte 4 0) (car (prog1 l1
(setq l1 nil))))) ==> <dont care>
l1 ==> nil
l2 ==> (#x99)
;; Note that the (setq l1 nil) didn't affect the actions of the setf
;; at all, since l1 was evaluated and its value was saved away in a
;; temporary variable as part of the step "2. Bind the temporaries
;; for <place-form>", and this was done before the evaluation of the
;; <value-form> which contains the (setq l1 nil). Note also that the
;; step "4. Do the access to <place-form>" means fetching the CAR of
;; the saved (temporary) value of 'l1'; it does not mean doing a LDB
;; on anything like that.
3b.(setq l1 (setq l2 (list #x69))) ==> (#x69)
(setf (ldb (byte 4 4) (car l1))
(ldb (byte 4 0) (car (rplaca l1 #x17)))) ==> <dont care>
l1 ==> (#x77)
l2 ==> (#x77)
;; Note that the (rplaca l1 #x17) altered the contents of what l1
;; was pointing to. Thus even though l1 was evaluated and its
;; value was saved away in a temporary variable as part of the step
;; "2. Bind the temporaries for <place-form>", and even though this
;; was done before the evaluation of the <value-form> which contains
;; the rplaca, still the side-effect changes things because it alters
;; what will be fetched during the "do the access" step.
4. (setq integer #x69)
(setf (mask-field (byte 4 4) integer) (incf integer)) => #x6A
integer ==> #x6A
5. (setq integer #x6A)
(setf (mask-field (byte 4 4) integer) (ash (incf integer) 4)) => #x6B0
integer => #xBB
6. (setq s (setq r (list 'a 1 'b 2 'c 3))) ==> (a 1 b 2 c 3)
(setf (getf r 'b)
(progn (setq r nil) 6)) ==> 6
r ==> (b 6)
s ==> (a 1 b 2 c 3)
;; Note that the generalized variable of concern here is the (degenerate?)
;; one of simply the program variable 'r'; it is not a property-list
;; slot denoted by (getf r 'b). At the time the step "4. Do the access
;; to <place-form>" is performed, the evaluation of the <value-form>
;; has already altered the generalized variable 'r', and thus a nil is
;; returned for this access; that is why a fresh property-list (B 6) is
;; created an stored back into 'r'.
7. (setq s (setq r (list (list 'a 1 'b 2 'c 3)))) ==> ((a 1 b 2 c 3))
(setf (getf (car r) 'b)
(progn (setq r nil) 6)) ==> 6
r ==> nil
s ==> ((A 1 B 6 C 3))
;; Note that the (setq r nil) does not affect the actions of the setf
;; because the value of R had already been saved in a temporary variable
;; as part of the step "1. Bind the temporaries for <place-form>". Only
;; the CAR of this value will be accessed, and subsequently modified
;; after the value computation.
Rationale:
As a principle,
(setf (foo-a x) (progn (setf (foo-b x) ...)
new-a-value))
should always set both of the "slots" of 'x', even if these slots are
implemented as bit-fields, getf-properties, and so on. Only by separating
out evaluation from "generalized variable access", and by specifying that
the access is done after all the evaluations, can this correctly be done.
Current Practice:
Symbolics and Lucid already operate pretty much according to this proposal.
Cost to Implementors:
Several implementations would require several hours of programmer and
documentation time.
Cost to Users:
None; this is a clarification of a point not sufficiently elaborated in CLtL.
Cost of non-adoption:
Users will think SETF is unnatural in that left-to-right order of
evaluation isn't well specified.
Benefits:
Uniform semantics and portability in the face of recursive "place specifiers"
for SETF. Setf of (LDB ... <place>) and of (GETF <place> ...) will behave
uniformly no matter the nature of the <place>.
Anyone who has copied examples from p105 and p106 will continue to
be able to use them.
Esthetics:
See "Cost of non-adoption"
Discussion:
In the detailed descriptions for each access form, the phrase
"the place referred to by the <place-form> must always be both
accessed and updated; note that the update is to the generalized
variable specified by <place-form>"
is not intended to prevent optimizations that could occur when the
code "knows" that the new value will be EQ to the old one. The only
requirements is that the results be semantically equivalent.
There is an interesting parallel between this case for GETF and the
very common mistake made by Lisp programmers with respect to the
function DELETE. How often the complaint is filed that DELETE didn't
do anything when it should have; but in fact the filer simply forgot
that delete, although permitted to destructively modify the original
list, may also return some tail of the list originally give it,
whether or not an alteration occurs.
(setq l '(a a b c d)) ==> (a a b c d)
(delete 'a l) ==> (b c d)
l ==> (a a b c d)
The unwary user thinks that because 'l' is still EQ to the original value
that "DELETE didn't do anything". The temptation to ignore the resultant
value of DELETE parallels the temptation to forget about a need to perform
a final update to <place-form> in the setf-of-getf case.
∂26-May-88 1945 CL-Cleanup-mailer Issue: SETF-SUB-METHODS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 26 May 88 19:40:04 PDT
Received: by labrea.stanford.edu; Thu, 26 May 88 19:40:23 PDT
Received: from bhopal.lucid.com by edsel id AA19997g; Thu, 26 May 88 19:28:24 PDT
Received: by bhopal id AA06641g; Thu, 26 May 88 19:32:27 PDT
Date: Thu, 26 May 88 19:32:27 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805270232.AA06641@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 24 May 88 15:01 EDT <19880524190108.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: SETF-SUB-METHODS
I think Version 4 is finally worth reading. I'm not sure about the current
practice of Symbolics -- maybe you can comment upon it?
-- JonL --
∂26-May-88 2103 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 26 May 88 21:01:23 PDT
Received: by labrea.stanford.edu; Thu, 26 May 88 21:01:47 PDT
Received: from bhopal.lucid.com by edsel id AA20331g; Thu, 26 May 88 20:46:43 PDT
Received: by bhopal id AA06807g; Thu, 26 May 88 20:50:49 PDT
Date: Thu, 26 May 88 20:50:49 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805270350.AA06807@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 24 May 88 16:55 EDT <19880524205536.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)
re: None of this addresses my comment. If the user insists on referencing a
non-exported symbol of the ULUZ package, what is the difference between
referencing (and hence creating) that symbol while reading an argument
to the :IMPORT option, and referencing (and hence creating) that symbol
while obeying the :IMPORT-FROM option?
I think you must have made this comment before reading the rest of my note
that you are replying to.
re: Okay, you're proposing that :IMPORT-FROM be changed to do something
different from any of the previous proposals, namely to call
FIND-SYMBOL instead of INTERN or the secret version of INTERN that
single-colon uses. I wish you had come right out and said so.
The situation is not quite so simple as that. I do favor altering the action
of :IMPORT-FROM in the way you deduce, since that would afford a much greater
measure of package integrity than is now common practice. However, I
*strongly* favor removing the requirement for symbols, even if we can't
agree on the first alteration just mentioned. The reason why this latter
semi-proposal affords a difference over doing nothing is two-fold:
(1) Certain kinds of non-EVAL file processors may be able to read this
form without evaluating it (cross-reference programs come to mind);
thus reading in the form with symbols in it "damages" the ULUZ package
in a way that "processing" alone would not.
(2) Many more soure-file/compile-file incompatibilities can easily be
turned up when the source-file has double-colon qualifications in
it. Thus apart from any evaluaton action of the defpackage form,
there is a possibility that compiled form of the file has different,
and ocasionlly much worse, side effects than the source file.
For example:
Source file:
(DEFPACKAGE "FOO" (:IMPORT 'uluz::bunkie))
Compiled-file: [actions, more or less]
1. intern DEFPACKAGE in current package [probably inherit from CL]
2. make string "FOO"
3. intern BUNKIE in what package????? depends on how that symbol
was accessible at compile time. The fact that the user specified
it as uluz::bunkie is completely and totally lost after the source
code has been read-in!
4. intern IMPORT in the keyword package
5. call EVAL on cons'd-up form
In fact, the original motivation that caused me to start discussing a
defpackage months and months ago was the frequency at which "vanilla"
code can be read-in differently after being compiled [differently, because
of the information-losing property of double-colon format]. So even if
:IMPORT-FROM were to continue in its present (Symbolics) semantics, it would
still be of some benefit to use strings as args rather than symbols, in order
to prevent the occurance of obscure source/compiled-file differences.
-- JonL --
∂27-May-88 0814 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 27 May 88 08:14:08 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 27 May 88 11:11:35 EDT
Received: by kali.think.com; Fri, 27 May 88 11:11:31 EDT
Date: Fri, 27 May 88 11:11:31 EDT
From: gls@Think.COM
Message-Id: <8805271511.AA14847@kali.think.com>
To: edsel!jlm@labrea.stanford.edu
Cc: pierson@multimax.arpa, cl-cleanup@sail.stanford.edu
In-Reply-To: Jim McDonald's message of Thu, 26 May 88 16:10:07 PDT <8805262310.AA06041@bhopal.lucid.com>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
Date: Thu, 26 May 88 16:10:07 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
> Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
> *DEBUG-IO*) should fail to work in a non-interactive environment where
> nothing like a terminal exists.
That seems like a needless restriction that could be rather painful
in particular instances.
Suppose we define an "interactive environment" to be one in which
*TERMINAL-IO* works?
--Guy
∂27-May-88 1815 CL-Cleanup-mailer [More on] Issue: DEFPACKAGE
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 27 May 88 18:15:13 PDT
Received: by labrea.stanford.edu; Fri, 27 May 88 18:15:29 PDT
Received: from bhopal.lucid.com by edsel id AA25151g; Fri, 27 May 88 18:00:14 PDT
Received: by bhopal id AA09771g; Fri, 27 May 88 18:04:22 PDT
Date: Fri, 27 May 88 18:04:22 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805280104.AA09771@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 24 May 88 16:55 EDT <19880524205536.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [More on] Issue: DEFPACKAGE
There were two more points in your msg of above date that either forgot
something, or else are simply worded in a misleading way:
re: Oh, yes, I had forgotten the argument for allowing symbols as arguments
when strings would do, so people can write their code in lower case
even though Common Lisp is an upper case language. Good point.
My proposed change was not to prohibit symbols as arguments, but rather
to flush the options that _prohibited_ strings (and, of course, add advice
for users to switch to strings if "something seems to be going wrong" with
packages when symbols are being used as arguments).
re: Okay, you're proposing that :IMPORT-FROM be changed to do something
different from any of the previous proposals, namely to call
FIND-SYMBOL instead of INTERN or the secret version of INTERN that ...
This is wrong. Your message of "Wed, 23 Mar 88 14:49 EST", which was the
presentation of (Version 2), said the following about :IMPORT-FROM (and
:SHADOWING-IMPORT-FROM):
(:IMPORT-FROM {(package-name {symbol}*)}*)
(:IMPORT-FROM package-name {symbol}*)
Find the specified symbols in the specified packages and import
them into the package being defined. The second syntax is a
convenient abbreviation when only one package is specified.
Note that only the name of each argument symbol is used. The
actual symbol that gets imported is not necessarily the one
given as an argument; it's a symbol with that name accessible in
the named package.
"Find the specified symbols" -- not "INTERN". Maybe the Symbolics
implementation does call INTERN, and you were thinking of that rather
than the DEFPACKAGE proposal?
-- JonL --
∂28-May-88 0927 CL-Cleanup-mailer ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 May 88 09:27:19 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 411847; Sat 28-May-88 12:26:29 EDT
Date: Sat, 28 May 88 12:26 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
To: skona%csilvax@hub.ucsb.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: The message of 19 May 88 14:20 EDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <880528122617.9.KMP@PEWEE.SCRC.Symbolics.COM>
DEFSTRUCT-DEFAULT-VALUE-EVALUATION looks ok to me.
I support the IFF-NEEDED proposal.
∂28-May-88 1004 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 May 88 10:04:25 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 411855; Sat 28-May-88 13:03:47 EDT
Date: Sat, 28 May 88 13:03 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-PRETTY-PRINT (version 2)
To: pierson%mist@MULTIMAX.ARPA
cc: Cl-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8805261556.AA18531@mist.UUCP>
Message-ID: <880528130335.1.KMP@PEWEE.SCRC.Symbolics.COM>
I support the idea of this proposal and more or less support its stance
on the issue, but I have a few suggestions on presentation...
I think this proposal should have the same character as the one about
FORMAT-NEGATIVE-PARAMETERS -- it should define the default situation
(ie, the expository text which precedes the detail section of the FORMAT
chapter) and allow the description of any given parameter to override
what it says. That would address Walter's concern about ~D. We should not
make the wording fuzzy enough for any dialect to get something in that
people don't expect. Instead, we should consider Walter's suggestion
that ~D should bind *PRINT-ESCAPE* (btw, Symbolics Genera does this, too).
If we think it's a good suggestion, we should just override the default
rule which Dan's proposing with an explicit rule for how ~D behaves. But
in the absence of such a rule, I think that ~D should either not bind
*PRINT-ESCAPE* or be an error for anything for which the value of
*PRINT-ESCAPE* could make a difference. (And since we'll presumably be
able to customize the printing of integers once CLOS goes in, I think
we'd be best of just defining the value of *PRINT-ESCAPE* in this situation
just in case...)
I think the rationale should mention that the key advantage would be
that people can treat (FORMAT stream "~S" object) and (PRIN1 object)
as purely a stylistic difference and interchangeable at any time. If they
have to worry that one treats the control variables differently than the
other, then the language is complicated in a way that is not generally
useful to the garden-variety programmer...
∂28-May-88 1053 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 28 May 88 10:53:27 PDT
Received: from PEWEE.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 260679; Sat 28-May-88 13:13:35 EDT
Date: Sat, 28 May 88 13:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
To: edsel!jonl@LaBrea.Stanford.EDU
cc: Cl-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8805240502.AA04386@bhopal.lucid.com>
Message-ID: <880528131327.2.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Mon, 23 May 88 22:02:19 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
Proposal (WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND):
Change the documentation of WITH-OUTPUT-TO-STRING to be like that under
FORMAT. That is, replace the first sentence of the next-to-last paragraph
on CLtL p331 by:
"If *string* is specified, it must be a string with a fill pointer;
the output is incrementally appended to the string (as if by use of
VECTOR-PUSH-EXTEND)."
...
Maybe I'm just confused, but aren't the fill-pointer and adjustable features
orthogonal? It's my belief that you can create a non-adjustable array with a
fill-pointer. Don't you want to say that it must be an adjustable array rather
than (or perhaps in addition to) that it must be a fill pointer?
Aside from this (real or perceived) confusion over the wording, I have no
objection to this proposal.
∂28-May-88 1753 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 28 May 88 17:52:38 PDT
Received: by labrea.stanford.edu; Sat, 28 May 88 17:52:57 PDT
Received: from bhopal.lucid.com by edsel id AA29060g; Sat, 28 May 88 17:25:22 PDT
Received: by bhopal id AA12479g; Sat, 28 May 88 17:29:34 PDT
Date: Sat, 28 May 88 17:29:34 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805290029.AA12479@bhopal.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: Cl-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Sat, 28 May 88 13:13 EDT <880528131327.2.KMP@PEWEE.SCRC.Symbolics.COM>
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
re: Don't you want to say that it must be an adjustable array rather
than (or perhaps in addition to) that it must be a fill pointer?
No. It's perfectly acceptable to use VECTOR-PUSH-EXTEND with a non-adjustable
array. It's the error-signalling property of VECTOR-PUSH-EXTEND, as opposed
to the "dropping on the floor" of VECTOR-PUSH, that motivated this proposal.
-- JonL --
∂28-May-88 2039 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 28 May 88 20:39:08 PDT
Received: by labrea.stanford.edu; Sat, 28 May 88 20:39:35 PDT
Received: from bhopal.lucid.com by edsel id AA29682g; Sat, 28 May 88 20:27:12 PDT
Received: by bhopal id AA12869g; Sat, 28 May 88 20:31:24 PDT
Date: Sat, 28 May 88 20:31:24 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805290331.AA12869@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Is there anyone on this mailing list who would like to see the proposal
(ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:FLUSH-UPGRADING) continued? If not,
then perhaps we can delete it?
-- JonL --
∂31-May-88 0717 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 May 88 07:16:58 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 412314; Tue 31-May-88 10:17:04 EDT
Date: Tue, 31 May 88 10:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880523-173849-5795@Xerox>
Message-ID: <880531101652.5.KMP@PEWEE.SCRC.Symbolics.COM>
I support SHARPSIGN-PLUS-MINUS-NUMBER:OK, version 3.
Non-preemptive remarks:
I would mention the "codifying current practice" remark in the rationale.
I would also change "KMP" to "Pitman" where it occurs.
∂31-May-88 0814 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 2)
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 31 May 88 08:13:42 PDT
Received: from PEWEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297362; Tue 31-May-88 11:12:59 EDT
Date: Tue, 31 May 88 11:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880531111336.6.KMP@PEWEE.SCRC.Symbolics.COM>
The only mail that was generated on this issue on the last pass was a note
from myself pointing out a bug in the test case and a short dialog between
me and Moon about the distinction between binding and referencing a special
variable.
Two new paragraphs have been added to the end of the Proposal section to
accomodate Moon's observations, the Test Case has been fixed, and the
Discussion and Edit History sections have been modified slightly. The
rest of the proposal remains unchanged.
-----
Issue: SPECIAL-VARIABLE-TEST
References: Declaring Global Variables and Named Constants (pp68-69),
Declaration Specifiers (p157)
Category: ADDITION
Edit history: 07-Mar-88, Version 1 by Pitman
21-May-88, Version 2 by Pitman (correct test case, add discussion)
Status: For Internal Discussion
Problem Description:
CLtL does not define a way to test to see if a variable has been
proclaimed special (for the purposes of either binding or reference).
Programs such as macros, code-walkers, and program-generating programs
may need such information from time to time in order to do certain kinds
of reasoning about code-motion, unused variables, etc.
Proposal (SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P)
Add a function SPECIAL-VARIABLE-P by analogy with SPECIAL-FORM-P
which is defined as:
SPECIAL-VARIABLE-P symbol &optional environment [Function]
Returns T iff -symbol- names a variable which is SPECIAL in the
indicated lexical -environment-. Otherwise, it returns NIL.
It is an error if -symbol- is not a symbol. If not supplied, the
-environment- defaults to NIL, meaning the null lexical environment.
This function will be useful in determining whether a reference to
the variable named by SYMBOL in the indicated ENVIRONMENT will be
a special reference.
Note: Since special variable proclamations are pervasive and
declarations are not, the technique for determining whether binding
the variable named by SYMBOL is not dependent on the surrounding
lexical environment. It is instead dependent only on the global
environment and on the declarations of the form which would accomplish
the binding. Whether the variable has been globally proclaimed special
can be determined by doing (SPECIAL-VARIABLE-P 'symbol). Whether the
variable is locally declared SPECIAL can be checked only by parsing
the declarations looking for (DECLARE ... (SPECIAL ... symbol ...)).
Test Case:
(PROCLAIM '(SPECIAL SPECIAL-FOO))
(MACROLET ((TEST (NAME &ENVIRONMENT ENV)
`'(,NAME ,(SPECIAL-VARIABLE-P NAME ENV)) ))
(LIST* (TEST SPECIAL-FOO) ;0
(TEST FOO)
(LET ((SPECIAL-FOO 1) (FOO 1))
(LIST* (TEST SPECIAL-FOO) ;1
(TEST FOO)
(LET ((SPECIAL-FOO 2) (FOO 2))
(DECLARE (SPECIAL FOO))
(LIST* (TEST SPECIAL-FOO) ;2
(TEST FOO)
(LET ((SPECIAL-FOO 3) (FOO 3))
(LIST (TEST SPECIAL-FOO) ;3
(TEST FOO)))))))))
=> ((SPECIAL-FOO T) (FOO NIL) ;0
(SPECIAL-FOO T) (FOO NIL) ;1
(SPECIAL-FOO T) (FOO T) ;2
(SPECIAL-FOO T) (FOO NIL)) ;3
Rationale:
This would allow programs that reason about other programs to obtain
important information about SPECIAL declarations and proclamations.
Current Practice:
Interpreters and compilers must, of necessity, have a way to do this
internally.
In some implementations, information about special variable proclamations
is kept on a symbol's plist, and users eventually "figure out" how to take
advantage of that.
In most implementations, getting information about special declarations
is neither documented nor easy to "figure out".
Symbolics Genera has undocumented internal function which does this.
Cost to Implementors:
By necessity, compilers and interpreters must have a way to get the
information returned by this facility. In general, it should just be
a matter of providing a program interface to that facility.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
Some code-walkers, macros, etc. would continue be hard to write in a
portable way.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Although SPECIAL variables provide some benefit to Common Lisp, that
benefit has not been without price. It's difficult to do proper code
analysis if lexical and special variables look the same. The presence
of this operator makes it easier to write code which reasons clearly
and correctly about other programs, and so will probably tend to
improve the aesthetics of such programs.
Discussion:
This proposal came to the Cleanup committee from the Japanese community.
Pitman wrote it up formally.
Pitman and Moon support SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P.
∂31-May-88 0840 CL-Cleanup-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 May 88 08:38:34 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 412378; Tue 31-May-88 11:38:38 EDT
Date: Tue, 31 May 88 11:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
To: Dave.Touretzky@B.GP.CS.CMU.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <361.580404478@DST.BOLTZ.CS.CMU.EDU>
References: <602.580432374@DST.BOLTZ.CS.CMU.EDU>,
<8805232237.AA01719@bhopal.lucid.com>
Message-ID: <880531113823.7.KMP@PEWEE.SCRC.Symbolics.COM>
I liked version 1 of HASH-TABLES-PRINTED-REPRESENTATION. I thought
it was simple, useful, and stylistically in keeping with existing
techniques.
JonL's point about losing attributes is interesting, but I would not
want to see his comments either keep the simple and useful thing Dave
is proposing from going in. I would also not want to see him force
Dave into either hairing up the proposal in a way that either doesn't
pass at all, or that does pass and leaves us with a maintainability
problem.
In particular, the #nH(type s t ...) notation is cute, but has a
certain ``kneejerk reaction'' quality to it. I'm afraid that later we'll
find other attributes that need to be in there and some may not fit
so gracefully. For example, this notation exploits the fact that no
useful attribute of a hash table is a non-atom -- if we had such attributes
later, we might not trivially be able to extend it.
I might propose #nH({keyword value}* {entry}*) but it's even more verbose
than what Dave has already said is too verbose for his uses.
So I think we should go with pretty much what Dave proposed and then
in a separate proposal bring up the issue of losing information and address
#H, #A, strings, etc. at the same time.
Also, unrelated to any of this, I think the "Cost to Implementors" (called
"Adoption Cost" in Dave's writeup) needs to be ammended to talk about
modifying not only the printer but also the reader.
∂31-May-88 0856 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 May 88 08:56:06 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 412400; Tue 31-May-88 11:55:46 EDT
Date: Tue, 31 May 88 11:55 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
To: edsel!jonl@LaBrea.Stanford.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8805290029.AA12479@bhopal.lucid.com>
Message-ID: <880531115529.9.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Sat, 28 May 88 17:29:34 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
No. It's perfectly acceptable to use VECTOR-PUSH-EXTEND with a non-adjustable
array. It's the error-signalling property of VECTOR-PUSH-EXTEND, as opposed
to the "dropping on the floor" of VECTOR-PUSH, that motivated this proposal.
Ok. I'm sold.
∂31-May-88 1308 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 May 88 13:08:03 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 412646; Tue 31-May-88 16:07:50 EDT
Date: Tue, 31 May 88 16:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
To: edsel!jonl@LaBrea.Stanford.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8805241000.AA04953@bhopal.lucid.com>
References: The message of 25 May 88 10:45 EDT from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>,
<880523-133528-5237@Xerox>
Message-ID: <880531160736.4.KMP@PEWEE.SCRC.Symbolics.COM>
Ok, I've caught up on my reading on this one...
Date: Tue, 24 May 88 03:00:59 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
...
The operative phrase we have come up with is that
THROW "commits"
That is, when a THROW decides that there is a catch-tag somewhere up
there to catch it, then no intervening UNWIND-PROTECT can function like
a catch barrier.
...
I just don't believe any of this. You can say "THROW commits", I can say
it doesn't. You assert it as if it were true and then try to derive a
semantics based on that unsupported presupposition. We all agree that
THROW commits to the extent that it chooses where it wants to unwind to.
What we don't agree on is whether it is well-defined, is an error, or
signals an error if you try to keep THROW from doing what it had set out
to do.
On a recent invitation to a marriage ceremony, I was asked to say (in addition
to whether I'd be attending) what my definition of "commitment" was. I thought
about this a long while and finally decided that the word is misleading and
that I would attack its usage as an absolute. One does not commit in the absolute,
one commits relatively. It's meaningless to say "I'm absolutely committed to
this person" or "I'm absolutely committed to this project" because (as Steele
points out in the Discussion section for this issue) you immediately run into
problems of conflicting absolutes (irresistable forces and immovable mountains)
When making a statement of commitment, you must say what your priorities are,
relative to other things which might come into conflict.
Consider the case of
(DOTIMES (I (* A B)) ...)
Certainly we must say that this DOTIMES "commits" to doing some number of
iterations, but all that means is that it has decided it's going to do that
and no modification of A or B is going to change that. But it doesn't mean that
something can't come along to shake it free -- its level of commitment is low.
It should not be said that this loop is a "failure" if a RETURN is executed.
Rather, we should just identify that its initial level of commitment to executing
all A*B steps is lower than its commitment to stopping the loop if a RETURN is
executed.
Ditto for THROW. I'm happy to say "THROW commits". I'm just not happy to say that
there is nothing in the language which might not have higher priority. Further,
but independently, I personally wish that another THROW should have such higher
priority.
What's not OK is to block a "committed" THROW. Without this restriction,
for example, an "abort" to top-level while runnining the application
evaluator noted below would never succeed; the THROW to FOO from within
the cleanup form would serve as an effect barrier such that no throw can
go past it.
(loop
(catch 'foo
(unwind-protect
(Run-application-evaluator)
(throw 'foo t))))
That's right! It WOULD serve as a barrier that no one can go past. But
did it occur to you that someone might want that? People have pulled a
lot of wild cases out of the air, but the only non-contrived situation
we have in this entire conversation is the one that I brought in from
Macsyma when I introduced this situation. I wanted to make a new
toplevel on top of Lisp's so that I could not get back to Lisp. I wrote
just the piece of code that you see above (except
RUN-APPLICATION-EVALUATOR was called something like MACSYMA-TOPLEVEL)
with certain expectations that you are claiming would not be wanted, and
yet I know for a fact that they are exactly what are wanted. Can you
cite any other real world examples of anyone getting involved in this?
I agree with Walter that the issue of an "unstoppable" loop is so much
bigger than this problem that we just shouldn't get involved in that
here. Every implementation should provide a way to unwind the stack
without running the unwind protects and everyone's debugger should offer
an interactive entry point to that mechanism for cases where you get
wedged and need to stop a program. Beyond that, I don't see that more is
required.
I think GLS says it best in the discussion on the proposal as currently
written:
``Which mechanism are to we regard as primitive: the error system or the
catch/throw system? Or are they disjoint? I prefer, for simplicity, a
model in which the error system can be explained. as much as possible,
as a complex thing built on top of catch, throw, and unwind-protect.''
I shudder to think about a system whose control semantics must appeal to the
condition system. I side with GLS in preferring to think of the error
system as a user program layered atop a simple set of control primitives.
I [still] support UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:CONTINUATION-MODEL
(now version 4).
Having been the self-righteous underdog in some of these other battles,
I'm very concerned about not seeing legitimate points of views stifled.
Remarks by Moon and JonL should be duly noted at least in the discussion
and, if they desire, as a competing proposal. It's clear we're not going
to get closure within this group since we have no voting authority. Let's
take it to the full community.
∂31-May-88 1422 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 May 88 14:21:53 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 412704; Tue 31-May-88 17:21:28 EDT
Date: Tue, 31 May 88 17:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 4)
To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8805261555.AA18524@mist.UUCP>
Message-ID: <880531172117.5.KMP@PEWEE.SCRC.Symbolics.COM>
Well, I'm still sympathetic to somethinga along these lines, but I don't
find this current proposal to be "convincing" yet...
For one thing, I think it's essential that a proposal of this sort
insist on a FOLLOW-SYNONYM-STREAM primitive (or the equivalent
functionality). It's critical that issues of which variables
may/must/mustn't hold primitive streams and which may/must/mustn't hold
synonym streams be discussed clearly. Otherwise, the potential for
supposedly portable code to construct circular streams in some
implementations seems very high.
I don't think the implications of this proposal are adequately
expressed. There are massive volumes of code which make subtle
assumptions about the relationships between these streams which are
(justifiably or otherwise) supported in most current implementations and
which might be violated in the future. The potential cost to users is
therefore high.
A typical example is:
(WHEN (PROGN
(FORMAT T "~&There are too many frobs.~%")
(YES-OR-NO-P "~&Go ahead and lose? "))
(LOSE))
When users use functions such as YES-OR-NO-P which implicitly use
*QUERY-IO* or other streams, they do not see that they are doing stream
mismatches. Presumably they should sometimes be writing
(WHEN (PROGN
(FORMAT *QUERY-IO* "~&There are too many frobs.~%")
(YES-OR-NO-P "~&Go ahead and lose? "))
(LOSE))
In the current state of affairs, they tend to win because implementations
are encouraged to make *STANDARD-OUTPUT* and *QUERY-IO* defaultly go to the
same place, but in the proposed state of affairs, it's easier for these to
drift apart and the consequences of writing sloppy code such as the first
example above are more noticeable.
I basically agree with your claim that the new regime you're proposing might
be better defined, but I'm not yet comfortable with how that better-defined
universe feels. Not to put down your proposal, but there are many things I
could do to make the language simpler and better defined, yet not all of those
things would make the language better. Before doing any, I would like to
understand the consequences.
I see your proposal, but I do not have a definite sense of the consequences
of it, and I assert that they are quite sweeping. I would like to see some
examples of programs taking "proper advantage" of each of these streams so
that I could assure myself that I was happy writing code in that style. Could
you perhaps conjure some examples of code which takes advantage of each of
these variables in some way? The code can be sketchy -- I don't need to run it
-- I just want to understand what idioms arise, etc. I'd like examples which
showed how the code behaved when various different valid/expected combinations
of interactive and non-interactive initial streams became involved.
For example, questions I don't see obvious answers to are:
- what would be an appropriate way to print a message/warning/error
on a given stream, can/may/must i expect to have seen it already on
*query-io*? i don't want to have to type it twice thinking i'm going
to different streams only to find out i'm really not.
- Are any of these streams permitted to be bound to null streams in an
interactive environment? in a non-interactive one? (i.e., should we
assume that the information which comes out of them is always available
to the interactive user, or might he have to enable something
in some contexts to see what's going to certain streams?)
- What variable bindings might a debugger make? Would it bind *TERMINAL-IO*
to *DEBUG-IO*? Could/should it also bind *STANDARD-INPUT* and
*STANDARD-OUTPUT* to *DEBUG-IO* or to a syn stream to that or to something
else? What about *QUERY-IO*?
I'm afraid I don't have any sense that this list is exhaustive. I'm just trying
to sketch the nature of my concerns since in fact I can't be much more specific.
About the best I can say is that your proposal does not fill me with a sense of
trust that you have really got this issue under control. Instead, it sounds like
so much legalese aimed at making a few more implementations conform yet without
making portable programs much easier to write.
Also, on an unrelated matter, I'm not sure I see the motivation for having
*QUERY-IO* couple *QUERY-INPUT* with *ERROR-OUTPUT*. This seems like something
of a kludge. Can you motivate why *QUERY-OUTPUT* isn't a separate stream and
why *ERROR-OUTPUT* is not simply permitted to be directed to the same place as
*ERROR-OUTPUT*?
∂31-May-88 1438 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 31 May 88 14:38:05 PDT
Received: from PEWEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297532; Tue 31-May-88 17:36:36 EDT
Date: Tue, 31 May 88 17:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
To: pierson@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU, vanroggen%aitg.decnet@hudson.dec.com
In-Reply-To: <8801211611.AA26219@mist.UUCP>
References: The message of 17 Feb 88 14:58 EDT from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Message-ID: <880531173722.6.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Thu, 21 Jan 88 11:11:14 EST
From: Dan L. Pierson <pierson@mist>
Issue: DISASSEMBLE-SIDE-EFFECT
References: DISASSEMBLE (p. 439), COMPILE (p. 439)
Category: CLARIFICATION
Edit history: Version 2 by Pierson 12/30/87
Version 3 by Pierson 1/21/88
Status: Ready For Release?
Very close, but not quite. See below.
...
Current practice:
Allegro CL and Vax Lisp install the compiled definition. Lucid,
Symbolics, Xerox, and KCL don't install it.
...
--------
Date: 17 Feb 88 14:58:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
Subject: two minor comments: DISASSEMBLE-SIDE-EFFECT & DRIBBLE-TECHNIQUE
... The comment about what VAX LISP does for DISASSEMBLE-SIDE-EFFECT is
incorrect; we don't modify the function cell of the symbol if the
function is interpreted. I think we changed the behavior when the
mail about this issue first came up, which was several years ago. ...
This comment never made it into the current practice for some reason.
I'd like to see it there.
Other than that, I certainly DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL and think
it's ready to be seen by the full committee.
∂31-May-88 1451 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 May 88 14:51:46 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 412729; Tue 31-May-88 17:49:56 EDT
Date: Tue, 31 May 88 17:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
To: skona%csilvax@hub.ucsb.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 19 May 88 14:18 EDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <880531174945.7.KMP@PEWEE.SCRC.Symbolics.COM>
I support DEFSTRUCT-SLOTS-CONTRAINTS-NUMBER:ALLOW-ZERO.
Btw, the benefits of this are more than just aesthetic. In the sample
error system I distribute with my proposal, there are examples of valid
uses for zero-element structs. Since such are disallowed, I conjure
one-element structs with a slot called -DUMMY-SLOT-. This means that
there is a loss space in spaces that really need no slots but are forced
to use at least one.
I have sympathy with DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
but will not claim to support it. I think it should be stronger:
implementations should be required signal an error or some well-defined
behavior should be described which implementations are forced to adhere
to. This is because there are conflicting ways in which extension might
be done, and having different implementations interpret the same syntax
in different ways without any kind of warning is a real barrier to
portability: it might be that neither implementation complains and code
simply behaves oddly in one implementation or the other. Programmers are
frustrated by this because neither implementation can be said to be the
bad-guy and yet it's clear that the programmer is getting screwed. Hence,
I think it's our charter to protect him. Requiring implementations to
signal an error is probably the simplest and most consistent solution.
∂31-May-88 1759 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 31 May 88 17:59:51 PDT
Received: by labrea.stanford.edu; Tue, 31 May 88 18:00:07 PDT
Received: from bhopal.lucid.com by edsel id AA09393g; Tue, 31 May 88 17:47:29 PDT
Received: by bhopal id AA20825g; Tue, 31 May 88 17:51:51 PDT
Date: Tue, 31 May 88 17:51:51 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
Message-Id: <8806010051.AA20825@bhopal.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 31 May 88 16:07 EDT <880531160736.4.KMP@PEWEE.SCRC.Symbolics.COM>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
> (loop
> (catch 'foo
> (unwind-protect
> (Run-application-evaluator)
> (throw 'foo t))))
>
> That's right! It WOULD serve as a barrier that no one can go past. But
> did it occur to you that someone might want that?
Although the following isn't a general solution, in most such
instances you can identify the catch tags that concern you and put
explicit catch's in to intercept them. E.g., assuming you care about
LISP-TOP-LEVEL and EXIT-LISP, this works just about as effectively as
the loop above:
(loop
(catch 'EXIT-LISP
(catch 'LISP-TOP-LEVEL
(Run-application-evaluator))))
Given a primitive that returned the currently active catch tags, you
could dynamically create the proper set of nested catch forms to
intercept all of them, modulo the usual lossage due to precisely timed
interrupts.
Given primitives to modify active catch frames, even fancier games
would be possible, although I don't see any obvious realistic uses.
Regarding JonL's phrase that "THROW commits", I read it to mean people
at Lucid had chosen that option, not that it was accepted as revealed
truth. Also, I think naive English usage would expand "X commits to
Y" into something like "X will make whatever efforts of which it is
capable that are necessary to induce Y. Thus we should assume Y will
occur, even though there might be unanticipated (e.g., force majeure)
situations which would obviate X's efforts." In the context of this
discussion, unwind-protects are obviously anticipated and part of the
contract, as opposed to power failures, memory lossage, etc.
[I don't remember being part of the discussion JonL alluded to, so
this is also something of an "outsiders" view of his analysis.]
jlm
∂31-May-88 2211 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 May 88 22:11:28 PDT
Received: from Burger.ms by ArpaGateway.ms ; 31 MAY 88 22:10:36 PDT
From: masinter.pa@Xerox.COM
Date: 31 May 88 22:10:07 PDT
Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
In-reply-to: edsel!jlm@labrea.stanford.edu's message of Tue, 31 May 88 17:51:51
PDT, <8806010051.AA20825@bhopal.lucid.com>
To: Jim McDonald <edsel!jlm@labrea.stanford.edu>
cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
Message-ID: <880531-221036-4393@Xerox>
Its late enough in the game, and I'm enough behind in the mail, to want some
briefer summaries of positions on this issue. We've been round it lots. Are ye
fer it or agin it?
∂01-Jun-88 0120 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 1 Jun 88 01:20:18 PDT
Received: by labrea.stanford.edu; Wed, 1 Jun 88 01:20:44 PDT
Received: from blacksox.lucid.com by edsel id AA11274g; Wed, 1 Jun 88 01:08:44 PDT
Received: by blacksox id AA00363g; Wed, 1 Jun 88 01:13:01 pdt
Date: Wed, 1 Jun 88 01:13:01 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8806010813.AA00363@blacksox.lucid.com>
To: masinter.pa@xerox.com
Cc: edsel!jlm@labrea.stanford.edu, KMP@stony-brook.scrc.symbolics.com,
CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 31 May 88 22:10:07 PDT <880531-221036-4393@Xerox>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
From: masinter.pa@Xerox.COM
Date: 31 May 88 22:10:07 PDT
Its late enough in the game, and I'm enough behind in the mail, to want some
briefer summaries of positions on this issue. We've been round it lots. Are ye
fer it or agin it?
Along with KMP, I favor the continuation model.
∂01-Jun-88 0711 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Jun 88 07:11:46 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 1 Jun 88 10:11:57 EDT
To: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
In-reply-to: Your message of 31 May 88 22:10:07 -0700.
<880531-221036-4393@Xerox>
Date: Wed, 01 Jun 88 10:11:52 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
The continuation model still looks best to me. One can create screw cases
for either version, so I'm inclined to favor the solution that provides a
cleaner and more intuitive model of what is going on. For me,
continuation seems much simpler and clearer than "throw commits". Some
systems may choose to provide a way of breaking out of the kind of trap
that people have described here; I think that is an environment issue.
-- Scott
∂01-Jun-88 1014 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Jun 88 10:13:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 413221; Wed 1-Jun-88 13:13:56 EDT
Date: Wed, 1 Jun 88 13:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880523-133528-5237@Xerox>,
<8805241000.AA04953@bhopal.lucid.com>,
<8805241443.AA10546@kali.think.com>,
The message of 25 May 88 10:45 EDT from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>,
<8805251854.AA01088@bhopal.lucid.com>,
<880531160736.4.KMP@PEWEE.SCRC.Symbolics.COM>,
<8806010051.AA20825@bhopal.lucid.com>,
<880531-221036-4393@Xerox>,
<8806010813.AA00363@blacksox.lucid.com>
Message-ID: <19880601171408.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
The inclusion of situation 2 distracts from the issue, since as far as I
know there is no controversy over situation 2, only over situation 1. Also
there is at least one typo where the proposal says 2 where I think it means
1, which detracts from its understandability.
The attempt to explain UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:CONTINUATION-MODEL
in terms of continuations explains nothing, since Scheme's continuation
semantics says nothing about dynamic lifetime and indeed assumes indefinite
lifetime for continuations. Since the controversy revolves entirely around
precisely when the dynamic (as prescribed by Common Lisp) lifetime of a
continuation ends, appeals to a semantics with indefinite lifetimes cannot
shed any light on the issue.
In retrospect, all the stuff about looping and unstoppable programs was a
distraction from the real issue, which only enables people to flame instead
of thinking about the real issue. I'm sorry I brought it up, and I wish
it were removed from the proposal and people would stop talking about it.
The real issue is very simple: CLtL pages 120 and 139 say that blocks and
catches have dynamic lifetime and can only be exited once. When it is
exited, the dynamic lifetime of a block or catch ends. Furthermore,
although CLtL does not actually say so, it surely means to imply that
when a block or catch is exited, the dynamic lifetime of any blocks or
catches dynamically nested inside it also ends.
Here's the issue: can a portable program assume that the lifetime of a
block or catch ends at the last possible moment, when control reaches
the caller of the block or catch? Or must portable programs assume that
this lifetime ends at the first possible moment, when THROW has decided
not to signal the error mentioned in the last sentence (outside of
notes) on CLtL p.142? I maintain that the semantics should be defined
in the way which is most restrictive on portable programs and least
restrictive on implementations, that is, portable programs must assume
that the lifetime ends at the first possible moment that CLtL allows it
to end.
I suppose if I want anyone to listen to me, I have to find the time to
write up an alternative proposal. I will try to find that time in the
next couple of days, but can't promise anything. Fortunately, my
alternative proposal will be much shorter, as it will not be padded
out with things I consider digressions.
∂01-Jun-88 1037 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 1 Jun 88 10:37:03 PDT
Received: from PEWEE.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 261236; Wed 1-Jun-88 13:36:39 EDT
Date: Wed, 1 Jun 88 13:36 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880601171408.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880601133626.3.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Wed, 1 Jun 88 13:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
...
Here's the issue: can a portable program assume that the lifetime of a
block or catch ends at the last possible moment, when control reaches
the caller of the block or catch? Or must portable programs assume that
this lifetime ends at the first possible moment, when THROW has decided
not to signal the error mentioned in the last sentence (outside of
notes) on CLtL p.142? I maintain that the semantics should be defined
in the way which is most restrictive on portable programs and least
restrictive on implementations, that is, portable programs must assume
that the lifetime ends at the first possible moment that CLtL allows it
to end.
...
My "naive model" has always been that an unwind-protect happens "as" (not
"after") an unwind occurs. I believe that this model is consistent only with
the idea that the dynamic state is retained until the last possible moment,
not the first. A major driving force in my reasoning is the fact that special
variable bindings have been partly unwound at the time the cleanup form is
run -- I find it more consistent to have all dynamic state unwinding at the
same time than to have the hairy N-pass unwinding strategy which seems to result
from the model you're suggesting. I hope that your proposal will address this
issue.
∂01-Jun-88 1402 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Jun 88 14:01:26 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Wed, 1 Jun 88 16:58:04 EDT
Received: by kali.think.com; Wed, 1 Jun 88 16:57:58 EDT
Date: Wed, 1 Jun 88 16:57:58 EDT
From: gls@Think.COM
Message-Id: <8806012057.AA22284@kali.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 1 Jun 88 13:14 EDT <19880601171408.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
I think Moon has been put off by the word "continuation", and perhaps
rightly so. Let me appeal to yet another model.
Unwinding is not an atomic process, because UNWIND-PROTECT allows arbitrary
user code to step in and execute in the middle of an unwinding. How can we
characterize the state of the computation when that user code is running?
In what ways can the user code examine, or even alter, that state?
It may help to consider the PDP-10 instruction set. BLT is not an atomic
operation, but rather an interruptible one. Therefore its interface was
carefully arranged so that its intermediate state could be easily
summarized. This intermediate state was part of the advertised interface
to the user. While I think very few programs actually checked this
intermediate state, or tried to alter it in mid-BLT, in principle it
was possible.
Conversely, consider the INTPRO (interrupt protect) macros we used in the
source code of PDP-10 MacLisp. The problem here was that it was essential
that certain crucial instruction sequences be regarded as atomic (such as
the guts of CONS), and yet there was a provision for running arbitrary user
code during an interrupt. The game here was that the interrupt trap
handler checked the PC, and if the PC was in a crucial interval then some
cleanup routine was performed, and *the interrupt state was then modified
to return to a PC other than where the interrupt had occurred*. As I
recall, this was trivial under ITS, as the state was accessible to the user
program, but very difficult under TENEX, as the relevant state was not
accessible: the only way to get rid of the state "you're in an interrupt
handler" was to return to the very PC where you took the interrupt, and no
other, and this was a real pain. I think this situation is very similar to
an UNWIND-PROTECT taking a look at the state of a Lisp data structure,
discovering that it is inconsistent, and deciding to THROW elsewhere
instead. Now maybe a previous THROW should not be forgotten, but then
there must be some explanation of how that state information is remembered,
how it interacts with other control actions over time, and whether it
can be queried.
--Guy
∂02-Jun-88 2141 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Jun 88 21:40:46 PDT
Received: by labrea.stanford.edu; Thu, 2 Jun 88 21:41:08 PDT
Received: from bhopal.lucid.com by edsel id AA04051g; Thu, 2 Jun 88 20:01:29 PDT
Received: by bhopal id AA28862g; Thu, 2 Jun 88 19:59:29 PDT
Date: Thu, 2 Jun 88 19:59:29 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806030259.AA28862@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 1 Jun 88 13:14 EDT <19880601171408.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
re: Here's the issue: can a portable program assume that the lifetime of a
block or catch ends at the last possible moment, when control reaches
the caller of the block or catch? Or must portable programs assume that
this lifetime ends at the first possible moment, when THROW has decided
not to signal the error mentioned in the last sentence (outside of
notes) on CLtL p.142?
This is exactly what Ron Goldman (of Lucid's QLISP project) and I mean
by "THROW commits" -- that you execute the cleanup forms pending on the
unwind-protect frames, but you are "committed" _not_ to re-enter the bodies
without first exiting the CATCH to which you were throwing. [But the local
variable environments are still guaranteed in existence during the cleanup-
form execution, since they can make reference to those variables. Do I need
to be more specific here?]
I rather like your phraseology above -- using terms like "lifetime of a
CATCH" etc.
Mabye the right approach to this miasma is to delete situation (1) from
the current proposal, and then let it be passed; for we all seem to be in
agreement that it should be possible to "extend" a THROW in progress,
while aborting out of one particular cleanup-form execution. Then, submit
another proposal for the same issue which addresses only the situation (1)
part. Could you possibly take a stab at doing this before Larry's deadline?
re: In retrospect, all the stuff about looping and unstoppable programs was a
distraction from the real issue, which only enables people to flame instead
of thinking about the real issue. I'm sorry I brought it up, and I wish
it were removed from the proposal and people would stop talking about it.
I didn't realize you were the guilty party here. I think a lot of other
people independently fell into this pit because of the obvious "re-entering
the body without ever exiting the CATCH" capability, which would exist if
situation (1) weren't proscribed. My previous msg described it thus:
"As someone has said previously, this proposal isn't about proscriptions
against writing looping code -- e.g., (prog () A (go A)) -- but about the
dynamic scoping relations between THROW and UNWIND-PROTECT cleanups.
[Well, if they didn't say exactly that, they should have!]"
Also, I think a proposal about case (1) will have to address the
CATCH-BARRIER implication, if for no other reason than that someone
actually claimed that he wanted to erect a barrier using the mechanism
of situation (1) scoping. At the very least -- if it is such good idea
to permit catch barriers -- then an explicit proposal for CATCH-BARRIER
(or CATCHALL, or whatever) should be put forward (and hopefully defeated);
otherwise one is subject to the _unintentional_ falling into an unseen
barrier simply because of poor scoping on THROW's. Jim MacDonald's reply
to KMP seems to me to show that an unrestricted CATCH-BARRIER really isn't
needed for an sensibly-written program; and whatever arguments kept
CATCH-BARRIER out of Common Lisp in 1983 are probably still relevant today.
-- JonL --
∂02-Jun-88 2141 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Jun 88 21:41:12 PDT
Received: by labrea.stanford.edu; Thu, 2 Jun 88 21:41:34 PDT
Received: from bhopal.lucid.com by edsel id AA04439g; Thu, 2 Jun 88 21:16:55 PDT
Received: by bhopal id AA29028g; Thu, 2 Jun 88 21:14:52 PDT
Date: Thu, 2 Jun 88 21:14:52 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806030414.AA29028@bhopal.lucid.com>
To: gls@think.com
Cc: Moon@stony-brook.scrc.symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: gls@Think.COM's message of Wed, 1 Jun 88 16:57:58 EDT <8806012057.AA22284@kali.think.com>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
re: Conversely, consider the INTPRO (interrupt protect) macros we used in the
source code of PDP-10 MacLisp. The problem here was that it was essential
that certain crucial instruction sequences be regarded as atomic (such as
the guts of CONS), and yet there was a provision for running arbitrary user
code during an interrupt. The game here was that the interrupt trap
handler checked the PC, and if the PC was in a crucial interval then some
cleanup routine was performed, and *the interrupt state was then modified
to return to a PC other than where the interrupt had occurred*. . . .
I think this situation is very similar to
an UNWIND-PROTECT taking a look at the state of a Lisp data structure,
discovering that it is inconsistent, and deciding to THROW elsewhere
instead. Now maybe a previous THROW should not be forgotten, . . .
I believe the analogy you are making here supports the notion of "extending"
the throw, but not one of "barricading" it; it worst, it would "extend"
the PC to a point a little beyond where the interrupt really happend.
It was like retroactively masking out interrupts during the interval
between the two PC's.
To the extent that this analogy has any relevance at all for the CL dynamic
scoping problem, then one should note that the "cleanup" routine for the
INTPRO hack was completely "dynamically" scoped; that is, it is like
"Situation 0" of the the proposal under discussion, rather than the
disputed "Situation 1".
-- JonL --
∂02-Jun-88 2216 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Jun 88 22:16:02 PDT
Received: by labrea.stanford.edu; Thu, 2 Jun 88 22:16:20 PDT
Received: from bhopal.lucid.com by edsel id AA04593g; Thu, 2 Jun 88 22:08:32 PDT
Received: by bhopal id AA29144g; Thu, 2 Jun 88 22:06:32 PDT
Date: Thu, 2 Jun 88 22:06:32 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806030506.AA29144@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
Following version omits the "FLUSH-UPGRADING" proposal, which no one on this
committee offered to support. Additionally, it has a re-organization of the
discussion (as per moon's suggestion) now that only one proposal is present.
It doesn't attack the COMPLEX problem. I think biting off array element-type
semantics is enough for now; if it passes, then one of us will submit a
COMPLEX-ELEMENT-TYPE-SEMANTICS issue; if it fails, then COMPLEX will be moot.
-------------------------------------------------------------------------------
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Version 3, 02-Jun-88, JonL
(flush alternate proposal ["flush-upgrading"]; consequently,
move more of discussion back to discussion section)
Problem description:
CLtL draws a distinction between type-specifiers "for declaration" and
"for discrimination" in the case of array type specifiers -- i.e., those
that are subtypes of ARRAY [this implicitly includes SIMPLE-ARRAY and
VECTOR]. Many people are confused by this situation, which may be one of
the more insidious flaws in the current CL design.
A consequence of this "flaw" is that a variable declared to be of type
<certain-type>
and all of whose assigned objects are created in accord with that type,
still may have *none* of its values ever satisfied by the TYPEP predicate
with that type-specifier. One type-specifier with this property in most
implementations of CL is <certain-type> = (ARRAY (SIGNED-BYTE 5)).
An array created with this type specifier will, depending on the vendor,
either be of typep (ARRAY (SIGNED-BYTE 8)) or (ARRAY T); but (almost)
never of typep (ARRAY (SIGNED-BYTE 5)).
[Notation: because of the inability to show meta- or linguistic variables
in a different typeface, some code examples will use a backquote format;
a form like ",x" will simply mean "substitute the value of x here".
and a form like `(...) will simply mean "evaluate this first, doing
the indicated comma substitutions." Also, the term "type-equivalent"
will be used to denote two types which are each subtypes of the other;
this relation establishes a partition on the set of type-specifiers
into disjoint sets, and members of the same equivalence class are
simply different names for the same type.]
Test case:
Let aet-x and aet-y be two distinct type specifiers that are definitely
not type-equivalent in a given implementation, but for which make-array
will return an object of the same primitive type; let this primitive
type be described by `(array ,aet-y). This will be an implementation
dependent search, but in every implementation that the present writer
(JonL) has tested, there will be some such types; often, (signed-byte 5)
and (signed-byte 8) will work. Thus in each case, it should be true that:
(array-element-type (make-array 0 :element-type ',aet-x)) ==> ,aet-y
(array-element-type (make-array 0 :element-type ',aet-y)) ==> ,aet-y
and if such a function exists, then:
(upgrade-array-element-type ',aet-x) ==> ,aet-y
(upgrade-array-element-type ',aet-y) ==> ,aet-y
Now for a first set of tests; to eliminate the distinction between "for
declaration" and "for discrimination" both of the following should be true:
[A]
`(typep (make-array 0 :element-type ',aet-x)
'(array ,aet-x))
`(typep (make-array 0 :element-type ',aet-y)
'(array ,aet-y))
Since `(array ,aet-x) and `(array ,aet-y) are different names for exactly
the same set of objects -- those arrays specialized to hold elements of
type aet-y -- then if the correlation between type-names and sets of objects
is being observed, these names should be type-equivalent. That means that
both of the following tests should be true:
[B]
`(subtypep '(array ,aet-x) '(array ,aet-y))
`(subtypep '(array ,aet-y) '(array ,aet-x))
Additionally, to show that un-equivalent type-specifiers that are upgraded
to the same "element type" should be equivalent as element-type specifiers,
then both the following type tests should be true:
[C]
`(typep (make-array 0 :element-type ',aet-y)
'(array ,aet-x))
`(typep (make-array 0 :element-type ',aet-x)
'(array ,aet-y))
Proposal (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
-- Delete all the documentation that suggests the :element-type argument
to make-array might not be a satisfactory element-type in the type
specifier for the kind of array produced. Particularly, delete the
documentation that permits a difference between type-specifiers "for
declaration" and "for discrimination; primarily this means parts
of the discussion in CLtL, section 4.5, p. 45 and 46. Include a
statement that `(array ,aet) is a suitable type-specifier for the
array made by `(make-array <dims> :element-type ',aet ...).
-- Change the documentation of ARRAY-ELEMENT-TYPE, CLtL p. 291 by deleting
the sentence begining "This set may be larger than the set requested
when the array was created; for example . . ."
-- Add documentation assuring that the resultant array-element-type
from a call to make-array is independent of any argument to make-array
except for the :element-type argument. Thus upgrading, if done at all,
must be done the same way for complex and multi-dimensional arrays as for
simple vectors.
-- Introduce a function UPGRADE-ARRAY-ELEMENT-TYPE, which will reveal how
a particular :element-type argument to make-array will be treated.
Semantically, this would be equivalent to:
(defun upgrade-array-element-type (element-type)
(array-element-type (make-array 0 :element-type element-type)))
but it wouldn't have to cons up the 0-element array first. Also,
the presence of this name, as a documented function in the language,
would serve notice that "upgrading" is an important aspect of any real
implementation of CL arrays.
-- Change TYPEP (and SUBTYPEP) so that `(typep x '(array ,aet)) is true
if and only if `(typep x '(array ,(upgrade-array-element-type aet)))
is true.
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and "for
discrimination".
Current Practice:
Every vendor's implementation that the present writer has queried does
some amount of non-trivial "upgrading" [generally, using (signed-byte 5)
as an :element-type argument to make-array will show it]; this includes
LUCID, VAXLISP, SYMBOLICS, FRANZ, and XEROX. Most implementations fail
tests [A] and [C] part 1, but pass tests [A] and [C] part 2; this is a
consequence of implementing the distinction between "for declaration" and
"for discrimination". Lucid and Xerox both pass test [B], and the other
vendors fail it [it may be that these two vendors have implemented a
partial solution for subtypep, with a view to future extensions.]
Cost to Implementors:
Typically, a small amount of work will be required in every vendor's
implementation of TYPEP and SUBTYPEP; some vendors may have already
done the work, but not fully integrated it.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely that
any user code will have to be changed. In fact, it is more likely that some
of the vendors will cease to get bug reports about make-array returning a
result that isn't of "the obvious type".
Cost of non-adoption:
See Benefits.
Benefits:
It will greatly reduce confusion in the user community; the fact that
(make-array <n> :element-type '<aet>) frequently is not of type (array <aet>)
has been very confusing to almost everyone. That is, in practice,
the distinction between "for declaration" and "for discrimination" has
been a disaster.
Esthetics:
Discussion:
To get a sense of how the community is confused, see the arpanet mailing
list for Common Lisp, in a series of exchanges started on Thu,
17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
under the subject line of "Types in CL". Also see the exchange started
Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
under the subject line of "TYPEP warp implications"
A common feeling among Common Lisp users is that the set of type-specifiers
forms a mathematical language, and the SUBTYPEP relation is generated by some
basic, generating set of relations between these names. People want to see
this language actually describing the implementation in which it is running
-- that the objects of the implementation are a model for that language --
rather than seeing it be limited to some theoretical model which no vendor
bothers to implement. Hence, typep and subtypep should be changed to
reflect what kinds of arrays get built. [Alternatively, make-array should
be changed to exhibit the distinctions that typep makes.]
Many senior implementors at Lucid favor this proposal. In network mail
"Date: Sat, 9 Jan 1988 15:54 EST" Rob McLaughlin favored the gist of this
proposal -- namely that upgrading should be continued, and that TYPEP should
be fixed. Here is an excerpt of his words:
There are two obvious solutions, one of which has already been proposed:
-- Make the mapping more direct. Eliminating "array element type
upgrading" would be an instance of this.
-- Make the mapping explicitly ill-defined in a more useful way.
I think we need to do the latter because the former won't work. I don't
see how to eliminate "array element type upgrading" without creating
more problems [than] we solve. . . .
My conclusion is that it isn't array types that are wrong, it is the
understanding of the meaning of TYPEP that is wrong.
Many persons are in favor of the permission to upgrade; but they would not
like to see CL become a language like C where there are a prescribed set of
kinds of arrays that must be implemented (e.g, "int", "long int", "single",
"double" etc), and no others can exist. In short, no one would want to gain
portability at the expense of limiting the language to the architectural
features of the hardware on which it was first implemented.
One possible criticism of this proposal is that it hinders portability by
exposing an implementation dependent facet, namely the "upgrading" function.
But the kind of portabililty achieved by a programmer ignorant of the
realities of array implementations -- that only a finite number of array
type classes are really implemented efficiently in any particular CL
implementation -- would be a very pyrrhic victory to say the least. The
kinds of attention a programmer would have to pay to these array type
boundaries is the same kind of attention he now has to pay to the
fixnum/bignum boundary (i.e., arithmetic that is doable in unit time, and
that which requires tens to hundreds of units of time). No one seems to
remember just exactly why this "warp" was put into Common Lisp in the first
place -- drawing a distinction between array type-specifiers "for declaration"
and "for discrimination". Possibly it was added in a mistaken belief that it
would promote portability. ["Mistaken", because the source of non-portability
is the permission to upgrade; if two different implementations do any
upgrading differently, then the effect will be the same kind of
non-portability that results when two different implementations set the
boundary between fixnums and bignums differently.]
Since this proposal contains the implication:
`(array ,aet-x) is-type-equivalent-to `(array ,aet-y)
==>
,aet-x is-type-equivalent-to ,aet-y
then the question naturally arises "Does the reverse implication hold?"
That is, should two non-EQ but type-equivalent type-specifiers ,aet-x
and ,aet-y always give rise to the same array types? For example,
consider SHORT-FLOAT and SINGLE-FLOAT in an implementation where these
are type-equivalent (because only one internal float type is provided for
Lisp objects -- see CLtL section 2.1.3). One may desire to implement
(ARRAY SHORT-FLOAT) and (ARRAY SINGLE-FLOAT) differently. Say, for example
that the former is packed into 16-bit half-words, whereas the latter is
packed into 32-bit words; but for either kind of packing, the result of
AREF is an ordinary "single-float". The whole point is merely to specify
a packing technique for "packed float" arrays. This "krinkle", however,
will not be addressed by the proposals herein; it should simply be
remembered that the implication above goes only one way, and is not
an "if-and-only-if" link.
This proposal arises from focusing on type specifiers as names for
collections of objects, and on SUBTYPEP as being "subsetp" on collections
of objects.
-- The second paragraph of CLtL p11 makes it clear that "data types" are
just sets of objects; subsequent discussion makes it clear that the
second argument to TYPEP (a type specifier) is a name for some such
set, and that there may be several distinct names specifying the same
set (or type). The first paragraph of section 6.2.1 on page 72 says
that TYPEP is a set membership test, and SUBTYPEP is a subset test.
-- The first two paragraphs of section 4.5, on page 45, describe a
permission for what may be called "element-type upgrading" on arrays;
the documentation for ARRAY-ELEMENT-TYPE on page 291 also makes it
clear that a conforming implementation is permitted to "collapse"
array element types into some more limited set of types, providing
that the array returned by make-array is at most an "upgrade". The
array types STRING and BIT-ARRAY are excluded from upgrading.
For example, depending on how primitive arrays are actually implemented,
(make-array <dims> :element-type '(signed-byte 5))
and
(make-array <dims> :element-type '(signed-byte 8))
might legitimately create arrays specialized to hold exactly the same set of
objects. The only constraint seems to be that that (array (signed-byte 8))
be the most specific type *** in that implementation *** which can hold
all the arrays made by (make-array <dims> :element-type '(signed-byte 5) ...).
In this case, we say that the array element type has been upgraded from
(signed-byte 5) to (signed-byte 8), and we imply that there is no particular
special provisions for arrays of element type, say, (signed-byte 6).
By the bulletted paragraphs above, (array (signed-byte 5)) and
(array (signed-byte 8)) are in fact names for exactly the same
set of objects.
However pages 45 and 46 go at length to specify that these two different
names for the same set of objects must be treated differently by TYPEP
and SUBTYPEP. This seems to "warp" the utility of TYPEP since it puts
it at variance with the fundamental principle: "SUBTYPEP means subsetp".
∂03-Jun-88 1048 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Jun 88 10:48:45 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 3 Jun 88 11:38:53 EDT
Received: by kali.think.com; Fri, 3 Jun 88 11:38:47 EDT
Date: Fri, 3 Jun 88 11:38:47 EDT
From: gls@Think.COM
Message-Id: <8806031538.AA24924@kali.think.com>
To: edsel!jonl@labrea.stanford.edu
Cc: gls@Think.COM, Moon@stony-brook.scrc.symbolics.com,
cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Thu, 2 Jun 88 21:14:52 PDT <8806030414.AA29028@bhopal.lucid.com>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Date: Thu, 2 Jun 88 21:14:52 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
re: Conversely, consider the INTPRO (interrupt protect) macros we used in the
source code of PDP-10 MacLisp. The problem here was that it was essential
that certain crucial instruction sequences be regarded as atomic (such as
the guts of CONS), and yet there was a provision for running arbitrary user
code during an interrupt. The game here was that the interrupt trap
handler checked the PC, and if the PC was in a crucial interval then some
cleanup routine was performed, and *the interrupt state was then modified
to return to a PC other than where the interrupt had occurred*. . . .
I think this situation is very similar to
an UNWIND-PROTECT taking a look at the state of a Lisp data structure,
discovering that it is inconsistent, and deciding to THROW elsewhere
instead. Now maybe a previous THROW should not be forgotten, . . .
I believe the analogy you are making here supports the notion of "extending"
the throw, but not one of "barricading" it; it worst, it would "extend"
the PC to a point a little beyond where the interrupt really happend.
It was like retroactively masking out interrupts during the interval
between the two PC's.
To the extent that this analogy has any relevance at all for the CL dynamic
scoping problem, then one should note that the "cleanup" routine for the
INTPRO hack was completely "dynamically" scoped; that is, it is like
"Situation 0" of the the proposal under discussion, rather than the
disputed "Situation 1".
-- JonL --
Indeed. I am more sympathetic to the "THROW commits" notion after
further pondering this analogy. My main point is that the nature of
the intermediate state needs to be made clear.
--Guy
∂03-Jun-88 1134 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 3 Jun 88 11:34:06 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 3 Jun 88 14:34:23 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
In-reply-to: Your message of Wed, 01 Jun 88 13:14:00 -0400.
<19880601171408.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 03 Jun 88 14:33:42 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU
In previous iterations of this proposal, I was one of the people who
forcefully argued for the "continuation model". My primary concern was
that, as a compiler writer, my life would be substantially complicated by
proposals that required an error *to be signalled* when the appropriate
metaphysical violation of the dynamic extent of a lexical control construct
(i.e. BLOCK) happened. This was where this example came from:
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
It is useful for a compiler to be able to have internal representations
which treat the same continuation as the same continuation, with FOO and
BAR just being different names for this. Too many people out there are
wandering around thinking "BLOCK is the same as CATCH (and presumably
implemented using it.)"
I don't care if anyone wants case one to "be an error", I just don't want
it to be required to be signalled.
Rob
∂07-Jun-88 1255 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jun 88 12:55:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 415979; Tue 7-Jun-88 15:55:17 EDT
Date: Tue, 7 Jun 88 15:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880531111336.6.KMP@PEWEE.SCRC.Symbolics.COM>
Message-ID: <19880607195459.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve this, but noticed a couple of typos while reading it:
Note: Since special variable proclamations are pervasive and
declarations are not, the technique for determining whether binding
the variable named by SYMBOL is not dependent on the surrounding
lexical environment.
In the third line, some phrase like "produces a SPECIAL binding"
is missing.
Symbolics Genera has undocumented internal function which does this.
"an" is missing.
∂07-Jun-88 1359 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jun 88 13:59:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 416025; Tue 7-Jun-88 16:58:52 EDT
Date: Tue, 7 Jun 88 16:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8806030506.AA29144@bhopal.lucid.com>
Message-ID: <19880607205831.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
In general, I agree with ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING,
however I have a few comments.
To my mind the proposal never quite says explicitly what it's proposing.
It speaks in terms of modifications to the document rather than features of
the language. I would summarize it as "The type specifier (ARRAY type)"
denotes the set of all arrays that can result from calling MAKE-ARRAY with
a :ELEMENT-TYPE argument of type. The equivalence relations among type
specifiers (ARRAY type1) and (ARRAY type2) are implementation-dependent,
since they depend on whether the implementation has distinct
representations for arrays with the two element types. The subtype
relations among type specifiers (ARRAY type1) and (ARRAY type2) are as
follows: For all values of type1 and type2, (ARRAY type1) and
(ARRAY type2) are either equivalent or disjoint."
[I added that last sentence, since I didn't find your proposal clear on
SUBTYPEP. Is my sentence what you intended to propose?]
I really don't think it's acceptable to leave COMPLEX out. The declaration
versus discrimination distinction applies just as much to COMPLEX as to
ARRAY; at a minimum, COMPLEX should be mentioned in the body of the
proposal as a subject for a necessary companion proposal. I think it would
be better to include the proposal for COMPLEX in this one; it's a
straightforward extension of the ARRAY proposal and will not complicate it.
The one sentence version is "The type specifier (COMPLEX type) denotes the
set of objects that can result from giving numbers of the specified type to
the function COMPLEX." To that one should add the same comment about type
equivalence and subtypes as I made for arrays in the preceding paragraph.
You need to list explicitly the type specifiers that are affected by
this proposal, so no one overlooks one.
I really don't think the UPGRADE-ARRAY-ELEMENT-TYPE function is necessary.
Everything you explain in terms of it can be explained in terms of
ARRAY-ELEMENT-TYPE.
I'm not sure I believe your claim that the cost to implementors and cost to
users are small. This is an incompatible change, admittedly in an obscure
area. Symbolics makes much heavier use of types than most other users of
Common Lisp that I am aware of, particularly in presentation types, a
compatible extension of Common Lisp types, and Statice types, another
compatible extension of Common Lisp types. I would not care to assert that
this proposal will have no impact in those areas, I'd have to do some study
first. The cost to implementors to change TYPEP and SUBTYPEP themselves is
clearly small, but the cost to keep other things in the implementation
consistent with the change might not be small. Also the claim that no
users could depend on the current workings of Common Lisp in this area
because some users are confused is poor reasoning, and appears naive about
users. I would not care to assert that there are no users out there who
depend on the present behavior.
I think it would be better to admit that it is an incompatible change
and argue that the decrease in confusion justifies the cost.
The discussion section was real long, so I didn't read it.
∂07-Jun-88 1429 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jun 88 14:28:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 416043; Tue 7-Jun-88 17:28:49 EDT
Date: Tue, 7 Jun 88 17:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-SUB-METHODS (Version 4)
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8805270229.AA06629@bhopal.lucid.com>
Message-ID: <19880607212838.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
The writeup is much improved. I favor SETF-SUB-METHODS:DELAYED-ACCESS-STORES.
I don't think it's accurate to say there is no cost to users. For
example, the original setf of getf example, which was proposed by a
user, will behave differently under this proposal than it behaved in
several implementations. Users of those implementations might have been
depending on the old behavior. You can say there is no effect on
portable programs, but you can't say that no users will be affected.
Even users who had ported programs among several implementations
and mistakenly concluded that their programs were portable might
be affected.
I think the <dont care>s in the test cases should be removed. CLtL
specifies specific values to be returned by all these forms; while
those values are irrelevant to the current issue, I think it is
better practice to include them in the test cases. Otherwise
someone might think you were proposing to stop specifying specific
values to be returned, and allow the values to become
implementation-dependent.
I was asked to provide Current Practice information for Symbolics:
Symbolics Genera 7.2 foolishly adopted an earlier proposal
(SETF-METHOD-FOR-SYMBOLS) before it was officially approved by X3J13 and
its parent standards organization. This proposal is incompatible with
that one, so Genera 7.2 does not implement the behavior described here,
and fails test cases 1, 2, 4, 5, and 6. I believe Symbolics Genera 7.1
is closer to this proposal, however I don't have access to it so I didn't
test it.
I didn't test Symbolics CLOE, perhaps Kent can provide information on it.
An earlier version of the proposal had Current Practice information
for Xerox, Franz, HP, and DEC. Where did it go?
∂07-Jun-88 1559 CL-Cleanup-mailer Cleanup issues -- OK to mail out?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jun 88 15:59:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JUN 88 15:57:31 PDT
Date: 7 Jun 88 15:57 PDT
From: Masinter.pa@Xerox.COM
Subject: Cleanup issues -- OK to mail out?
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <880607-155731-1271@Xerox>
Due to a combination of circumstances, I've been unable to work on cleanup
activities. The committee has proceeded admirably, but I've been behind in
summarizing. Since we're behind, we can have some discussion and
information-exchange at the meeting on the issues that have been worked through
so-far. I will bring some hardcopy of these issues to the meeting.
I think to make progress I should bring along the "last summary" of the open
issues and we can have a more free-form discussion at the meeting.
OK? Objections?
∂07-Jun-88 1614 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jun 88 16:13:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JUN 88 16:11:01 PDT
Date: 7 Jun 88 16:04 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
In-reply-to: Masinter.pa's message of 14 Feb 88 12:29 PST
To: CL-CLEANUP@Sail.Stanford.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <880607-161101-1303@Xerox>
My records about this issue are unclear, and I can't figure it out from the
minutes of the last meeting. What happened with this one? Was it passed?
Rejected? Tabled?
I'll bring it again...
∂07-Jun-88 1614 CL-Cleanup-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jun 88 16:14:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JUN 88 16:14:16 PDT
Date: 7 Jun 88 16:14 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
line-fold: no
Message-ID: <880607-161416-1308@Xerox>
I changed current practice as per Moon, added a remark to the discussion (from JonL's message), and removed the endorsement (there's some risk in saying that 3 people endorse it, lest it be misconstrued that the rest of us don't.)
This one will go out tomorrow afternoon.
!
Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE
References: CLtL, pages 331, 386
Category: CLARIFICATION
Edit history: Version 1, 25-Mar-88 JonL
Version 2, 29-Mar-88 JonL (fix typos; comments by Daniels)
Version 3, 23-May-88 JonL (fix nits raised by Masinter)
Version 4, 23-May-88 JonL (change issue name -- only 1 proposal)
Version 5, 7-Jun-88 Masinter (more nits)
Problem description:
CLtL p386 says that FORMATting to a fill-pointer'd string should add
characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that
WITH-OUTPUT-TO-STRING will work "as if using VECTOR-PUSH-EXTEND if the
string is adjustable, and otherwise as if using VECTOR-PUSH". It's very
unlikely that the original authors of these parts intended differing
semantics for these two cases. Furthermore, the semantics for
WITH-OUTPUT-TO-STRING permit the inconspicuous loss of characters
written to the string, since VECTOR-PUSH will just "drop on the floor"
any characters that would go beyond the end.
Proposal (WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND):
Change the documentation of WITH-OUTPUT-TO-STRING to be like that under
FORMAT. That is, replace the first sentence of the next-to-last paragraph
on CLtL p331 by:
"If *string* is specified, it must be a string with a fill pointer;
the output is incrementally appended to the string (as if by use of
VECTOR-PUSH-EXTEND)."
Test Case:
(let ((str (make-array 4 :element-type 'string-char :fill-pointer 0)))
(with-output-to-string (s str) (princ "You Luz, Bunkie!" s))
str)
CLtL behaviour will return "You "; proposed behaviour will signal an error.
Rationale:
It's unlikely that the mention of VECTOR-PUSH in CLtL p331 was intended
to suggest that characters could be quietly "dropped on the floor". In
any case, there is no practical or theoretical reason to make FORMAT and
WITH-OUTPUT-TO-STRING act differently on non-adjustable strings.
Current Practice:
VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier
versions implement CLtL. For WITH-OUTPUT-TO-STRING, Xerox Common Lisp
implements CLtL. Symbolics Genera 7.2 implements the proposal.
Cost to Implementors:
Very small.
Cost to Users:
Virtually none.
Benefits:
Less special-casing in the semantics of "printing" to strings.
More conformity with naive expectations about printing to strings.
Aesthetics:
Minor impact.
Discussion:
Implementations may want to actually call VECTOR-PUSH, rather than
VECTOR-PUSH-EXTEND, on non-adjustable string in order to test the
result -- nil means an overflow of the total length of the string;
thus they may signal an error more directly related to the problem,
rather than permitting VECTOR-PUSH-EXTEND to complain about a non-
adjustable array. But either way, the semantics is still that of
VECTOR-PUSH-EXTEND: when you get to the end of the string, adjustable
strings are extended, and non-adjustable strings cause error signals.
It's perfectly acceptable to use VECTOR-PUSH-EXTEND with a non-adjustable
array. It's the error-signalling property of VECTOR-PUSH-EXTEND, as opposed
to the "dropping on the floor" of VECTOR-PUSH, that motivated this proposal.
∂08-Jun-88 1356 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jun 88 13:56:15 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 416590; 8 Jun 88 16:55:29 EDT
Date: Wed, 8 Jun 88 16:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880608165454.0.KMP@PEWEE.SCRC.Symbolics.COM>
Well, this really needs a lot more polish, but I don't have more time to
spend on it today and I wanted to get it out for people to look at
before we meet next week. This is definitely a rough cut and I'm sure it
won't want to go to committee in this form, but at least now all the
proposals are under a single cover and we don't have to play leap-frog
with Moon removing my proposal or my removing his (unless one of us
gives in).
-----
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category: ADDITION
Edit history: 06-Jun-87, Version 1 by James Kempf
17-Jul-87, Version 2 by James Kempf
12-Nov-87, Version 3 by Pitman (alternate direction)
01-Feb-88, Version 4 by Moon
(from version 2 w/ edits suggested by Masinter)
06-Jun-88, Version 5 by Pitman
(fairly major overhaul, merging versions 3 and 4)
Status: For internal discussion
Problem description:
Common Lisp provides reader syntax (#,) which allows the programmer
to designate that a particular expression within a program is to be
evaluated early (at load time) but to later be treated as a constant.
Unfortunately, no access to this capability is available to programs
which construct other programs without going through the reader.
Some computations can be deferred until load time by use of EVAL-WHEN,
but since EVAL-WHEN must occur only at toplevel, and since the nesting
behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
solution to the problem of load-time computation of program constants.
Also, CLtL is vague about whether the result of this early evaluation
is re-evaluated at runtime. The meaning of #,exp in an for-evaluation
position is unclear. Although CLtL doesn't come out and say so explicitly,
portable code must currently use only '#,exp to get consistent behavior
across implementations.
CLtL is also vague on whether the result of a #, expression may be
treated as a read-only constant by the loader (and hence shared with
other programs). Users probably want some both read-only and modifiable
load-time constants, so this may not be simply an issue of deciding on
a single "right answer".
Proposal (LOAD-TIME-EVAL:QUOTED-MAGIC-TOKEN):
Add a function MAKE-LOAD-TIME-CONSTANT, as described here:
MAKE-LOAD-TIME-CONSTANT form env &optional read-only-p [Function]
FORM is a Lisp form. ENV is an environment of the sort received
by the &ENVIRONMENT argument to a macro.
When MAKE-LOAD-TIME-CONSTANT is called from the interpreter or the
COMPILE function, it simply evaluates FORM in the null lexical
environment and returns its value. When MAKE-LOAD-TIME-CONSTANT is
called during a file compilation, the result is a special object
that is recognized at load time, when it occurs inside a constant.
At load time, FORM is evaluated and its value is substituted for
the object.
MAKE-LOAD-TIME-CONSTANT uses its ENV argument and/or dynamic state
to determine whether it is being called during a file compilation.
Until Common Lisp is modified to specify the semantics of file
compilation more precisely, this is necessarily implementation
dependent.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL, the result must be considered ordinary,
modifiable data. If T, the result is a read-only quantity which may, as
appropriate, be copied into read-only space and/or shared with other
programs.
Specify that '(... #,exp ...) is equivalent to
#.`(... ,(MAKE-LOAD-TIME-CONSTANT exp NIL T) ...).
Rationale:
This approach is the most compatible with existing practice.
Cost to Implementors:
The cost to implementors will depend on how #, is implemented.
In some implementations, the primitives for implementing
MAKE-LOAD-TIME-CONSTANT may already exist, in others, more substantial
changes may be required.
Cost to Users:
This change is upward compatible with user code.
Benefits:
It would be possible for macros to expand into load time constants.
Examples:
Case QUOTED-MAGIC-TOKEN-1:
(defmacro print-software-version (&environment env)
`(quote ,(make-load-time-constant
'(format T "~A~%" (software-version))
env)))
When interpreted or processed during invocation of COMPILE, this
macro prints the value of (software-version) at macro expansion
time and expands into (quote nil). When macroexpanded during a
file compilation, printing is deferred until the compiled file is
loaded, and the constant is still (quote nil).
Case QUOTED-MAGIC-TOKEN-2:
(defmacro table-of-tables (&rest predicates &environment env)
`(quote ,(mapcar #'(lambda (predicate)
`(,predicate
,(make-load-time-constant
`(make-hash-table :test ',predicate)
env)))
predicates)))
(table-of-tables eql equal) expands into
(quote ((eql #<table :test eql>) (equal #<table :test equal>)))
except that when macroexpanded during a file compilation,
the tables are not created until load time. This example
shows that the <object> returned by make-load-time-constant is
recognized even when it is interior to a quoted constant.
Proposal (LOAD-TIME-EVAL:NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-CONSTANT, which has the following
contract:
LOAD-TIME-CONSTANT form &optional read-only-p [Special Form]
All processing of the FORM is deferred until the expression is
in the "runtime" environment. Once that environment is available,
FORM is evaluated in the null lexical environment and the result
is both returned and saved for immediate access by the program
on subsequent evaluations.
In the interpreter, the FORM may be evaluated during pre-processing
(if any) or dynamically when the LOAD-TIME-CONSTANT is first seen
(in a non-pre-processing implementation). If the same LOAD-TIME-CONSTANT
expression is later seen again by the interpreter, the previously
obtained result is immediately retrieved and returned as the result
of evaluating the object; no re-evaluation occurs.
If the LOAD-TIME-CONSTANT expression is seen by the file compiler
(eg, COMPILE-FILE), the compiler arranges for all semantic processing
of FORM (including macro expansion) to occur at load time in a null
lexical environment (independent of whether any value has been cached
for interpreter use). At runtime, the result of that evaluation will
be treated as an immediate quantity; no re-evaluation occurs.
If a LOAD-TIME-CONSTANT expression is seen by the runtime compiler
(eg, COMPILE), the compiler checks for a cached value which may have
been produced by the interpreter. If one is found, it is used. If no
such value is found, the runtime compiler will evaluate the FORM in
a null lexical environment and use that value. The value used will be
treated as an immediate quantity in the code which is produced; no
re-evaluation occurs.
Note that since some implementations are compiled-only (that is, they
implement their interpreter using a compiler pre-pass) and some are
interpreted-only (that is, they implement their compiler as a null
operation and use only an interpreter), the question of whether the
interpreter or the compiler will end up doing the processing is left
somewhat vague. The programmer may assume only that the given FORM
will be evaluated only once for each time it is loaded into a runtime
environment.
Note, however, that in the case of quoted code (processed by explicit
use of EVAL), each call to EVAL is treated like a load. Caching may not
be implemented by having LOAD-TIME-CONSTANT displace its source level
call. So while
(DEFVAR *FOO* 1)
(DEFUN FOO () (LOAD-TIME-CONSTANT (INCF *FOO*)))
will increment *FOO* only once,
(DEFUN FOO () (EVAL '(LOAD-TIME-CONSTANT (INCF *FOO*))))
will increment *FOO* once each time FOO is called.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL, the result must be considered ordinary,
modifiable data. If T, the result is a read-only quantity which may, as
appropriate, be copied into read-only space and/or shared with other
programs. (Because this is a special form, this argument is -not- evaluated
and only the literal symbols T and NIL are permitted.)
Make #,exp be equivalent to (LOAD-TIME-CONSTANT exp T). As such, it
would -always- appear in a for-evaluation position, and never inside quoted
structure.
Rationale:
By making the description of LOAD-TIME-CONSTANT defined as a special
form, we eliminate the need for it to take an environment argument.
By making #, agree with LOAD-TIME-CONSTANT in terms of where it may be
used, we simplify the description of the resulting language.
As discussed in more detail elsewhere in this proposal, the #, syntax
is currently only reliably useful -inside- quoted structure, but this
is unnecessarily complicated for most known uses. Since this proposal
suggests a meaning for #, only -outside- quoted structure, it is an
incompatible change (though not one that would necessarily require
vendors to immediately remove support for existing code).
Cost to Implementors:
This is an incompatible change to the program interface.
The cost is not trivial, but is not particularly high.
Most of the "hard" substrate required to support this proposal
probably already exist; in most cases, what needs to change is
only the way in which the substrate is presented to the
programmer.
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Cost to Users:
Very few users probably use #, right now. A very small amount of code
might need to be rewritten (and recompiled).
The following kinds rewrites exemplify the total amount of work needed
in the few situations that use #, currently:
'#,exp => #,exp
'(... #,exp ...) => #,`(... ,exp ...)
`(... #,exp ...) => `(... ,#,exp ...)
Some user-defined code-walkers would have to be taught about
this new special form. Such changes would also be likely be trivial.
Although change to #, is an incompatible one, vendors would be free to
provide compatibility support for the old behavior for whatever period
they deemed appropriate. #, is equivalent to, but not the same as,
(LOAD-TIME-CONSTANT exp T), so it might in fact expand into
(SYSTEM::LOAD-TIME-CONSTANT exp T) which might be both a macro that
expanded into (LOAD-TIME-CONSTANT exp T). SYSTEM::LOAD-TIME-CONSTANT
might be a magic token which was treated specially within quoted
structure as an unportable extension during a transition period.
Benefits:
Relatively consistent interpreter/compiler treatment of this special form
would be possible.
Pretty printing expressions in which LOAD-TIME-CONSTANT occurred would be
possible.
An expression such as `(... #,(... , ...) ...) would be meaningful.
Manipulating expressions involving uses of LOAD-TIME-CONSTANT would be
possible. Currently, calling READ is enough to trigger resolution of the
constant, so a program doing file-to-file source code rewrites must
either use a special readtable or resign itself to premature resolution
of load time constants.
Expressions involving quoted LOAD-TIME-CONSTANT expressions would be
possible to quote. Currently, the #, feature is syntactic, not semantic,
and so is not sensitive to levels of quotation. You can refer to a
load time constant by writing '#,exp but you cannot refer in turn to that
expression which refers to a load time constant by writing ''#,exp .
Under this NEW-SPECIAL-FORM proposal #,exp and '#,exp and ''#,exp (and
so on) are all usefully distinct.
It would be possible to use , in a #, expression. For example, the expression:
Examples:
Case NEW-SPECIAL-FORM-1:
(defmacro print-load-timestamp ()
`(print (load-time-constant
`(load-timestamp ,(incf *foo*) ,(get-universal-time))
t)))
(defvar *foo* 0)
(defun test-1 () (print-load-timestamp))
(test-1)
CLtL does not define this situation.
Under this proposal, this code would print
(LOAD-TIMESTAMP 1 <<a-universal-time>>)
at the time the test case is loaded, whether interpreted or compiled.
Subsequent calls to (TEST-1) should print the identical expression.
Currently, no known implementation supports the proposed behavior.
Case NEW-SPECIAL-FORM-2:
(defun test-2 () (print #,'(+ 3 4)))
CLtL does not adequately define this situation.
Under this proposal, this would print (+ 3 4), whether interpreted
or compiled.
Currently, some compilers complain about the syntax, some arrange for
it to print (+ 3 4), and some arrange forit to print the result of
(+ 3 4), or 7.
Case NEW-SPECIAL-FORM-3:
(defun test-3 () (print '#,'(+ 3 4)))
Under CLtL, this would print (+ 3 4).
Under this proposal, the behavior would be undefined.
Currently, most implementations support the proposed behavior.
Case NEW-SPECIAL-FORM-4:
(pprint '(+ x #,(sqrt x)))
prints something re-readable like
(+ X #,(SQRT 2)) or (+ X (LOAD-TIME-CONSTANT (SQRT 2) T))
but not something like
(+ X 1.4142135)
Currently, no implementation is known to already support the
proposed behavior, but in principle it is possible for a valid
implementation to already do so.
Case NEW-SPECIAL-FORM-5:
(defmacro foo (x y)
`(member ,x #,`(foo ,,y baz)))
(macroexpand '(foo *bar*)) => ??
Under CLtL, this situation is not adequately defined.
Under this proposal, the macroexpansion would be
(member foo #,`(foo ,*bar* baz))
Currently, this triggers a read error such as "comma not in backquote"
or "SYSTEM::BACKQUOTE-COMMA undefined function" in most
implementations.
Current practice:
Although most implementations provide a substrate which would allow
program-mediated access to load time evaluation in some way, the language
only defines access to this substrate through the sharpsign read syntax.
Costs of Non-Adoption:
There are numerous possible uses for this facility. Among them are:
* Version control and system building facilities.
* The Common Lisp Object System.
* Language translators which desire to emulate "linking".
While every implementation of Common Lisp could certainly provide an
implementation specific facility capable of supporting such facilities,
portability of such facilities would suffer.
Benefits:
Portability and extended language power. The nature of each proposed
extension is such as to enable other extensions to be added more
gracefully. The Common Lisp Object System is a clear example.
Aesthetics:
These proposals fill a hole in the spectrum of alternatives for
deferring evaluation until a compiled file is loaded. Currently, code
which is read by the reader can arrange for it to be done, as can
top level code, but embedded code cannot. As such, these proposals
clarify and regularize existing parts of the language. Also, by
adding program-accessible entry points to facilities already provided
in a more contrived way, it makes the language easier to use.
Discussion:
There is likely to be some controversy about this proposal, since
there is no universally agreed upon formal processing model for
Common Lisp.
The cleanup committee seems to generally approve of the idea of a
load-time-eval capability, but a number of the details seem to need
ironing out.
Moon supported a previous draft of QUOTED-MAGIC-TOKEN. In this draft,
KMP changed the presentation and also added the READ-ONLY-P argument
in order to make it sit nicely with the alternate proposal,
NEW-SPECIAL-FORM. It's more than slightly possible that after all this
editing, Moon will have some problems with this version and want to
submit a refined draft.
Pitman supports NEW-SPECIAL-FORM.
Rees has expressed strong support for the idea of implementing #, as a
new special form rather than perpetuating the current state of affairs.
He had some input into the high-level content of this proposal, though
he hasn't reviewed any drafts. This paragraph is intended primarily to
incite him to say something definitive one way or the other.
∂08-Jun-88 1724 CL-Cleanup-mailer Re: Cleanup Committee Mtg?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 17:24:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 17:18:08 PDT
Date: 8 Jun 88 17:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Cleanup Committee Mtg?
In-reply-to: Rosemary Bouzane <bouzane@scrc-pegasus.ARPA>'s message of Wed, 8
Jun 88 19:29:19 edt
To: bouzane@scrc-pegasus.ARPA
cc: cl-cleanuP@Sail.stanford.edu
Message-ID: <880608-171808-3571@Xerox>
I'm sorry that I've been very bad & not done so sooner.
I think we wanted to have a cleanup meeting Tuesday morning. Can you accomodate
us? Thanks.
Larry
∂09-Jun-88 0714 CL-Cleanup-mailer Issue: LAST-N (Version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Jun 88 07:14:29 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 9 Jun 88 10:11:00 EDT
Received: by kali.think.com; Thu, 9 Jun 88 10:10:57 EDT
Date: Thu, 9 Jun 88 10:10:57 EDT
From: gls@Think.COM
Message-Id: <8806091410.AA03128@kali.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: Masinter.pa@xerox.com's message of 8 Jun 88 19:57 PDT <880608-195718-3790@Xerox>
Subject: Issue: LAST-N (Version 2)
I cast a "grue" vote for LAST-N:ALLOW-OPTIONAL-ARGUMENT; that is,
I support it and will continue to support it until it has consumed
either ten more messages on this mailing list or ten minutes of
meeting time, after which I will fiercely oppose it.
--Guy
∂09-Jun-88 0907 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jun 88 09:03:36 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02943; 9 Jun 88 10:01 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa07565;
9 Jun 88 10:00 BST
To: cl-cleanup@sail.stanford.edu
CC: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-reply-to: Masinter.pa@com.xerox's message of 8 Jun 88 15:07 PDT <880608-150925-3305@Xerox>
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Date: Thu, 9 Jun 88 10:02:42 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
>>Rationale:
>>
>>Since it would be difficult to prescribe reasonable behavior for
>>this situation, it should be considered an error. Checking for it
>>would be costly so signaling this error is not required.
Sorry, I do not see the great cost. Surely defstruct is in effect a
declaration, and the cost of checking is small and the value great.
==John
∂09-Jun-88 0953 CL-Cleanup-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Jun 88 09:53:47 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 417215; Thu 9-Jun-88 12:52:55 EDT
Date: Thu, 9 Jun 88 12:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880609125240.3.KMP@PEWEE.SCRC.Symbolics.COM>
At Larry's request, I went over this to try to reconcile Moon's comments
with my previous draft. I ended up updating the proposal to add ``more
concrete vagueness.'' I'm certainly willing to believe that this part still
needs work.
Moon had asked specifically about whether we wanted to make DOLIST more like
MAPHASH by allowing deletion of the element you're at, but I decided not
to follow up on that suggestion because in the case of MAPHASH you have the KEY
which acts as a unique pointer into the structure, while in the case of DOLIST
you can have duplicated elements, and so you don't really have a pointer into
the structure. A better case might have been MAPL, but I declined to address that
because it was starting to seem more like an obscure point (even though I agree
with Moon that it makes things more general, the fact that it's only meaningful
in a few cases makes it seem like a special case ...)
-----
Issue: MAPPING-DESTRUCTIVE-INTERACTION
References: MAPCAR, MAPLIST, ... (p128);
DOLIST (p126); MAPHASH (p285);
DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS (pp187-188);
All functions using :TEST
Related-Issues: REMF-DESTRUCTION-UNSPECIFIED.
Category: CLARIFICATION
Edit history: 07-Mar-88, Version 1 by Pitman
09-Jun-88, Version 2 by Pitman
(merge Moon's comments and update current practice)
Status: For Internal Discussion
Problem Description:
The interaction of mapping functions and DOLIST with destructive
operations on the list being operated on is unclear. For example,
if you destructively modify some tail of a list being mapped down,
does that affect the mapping process?
Proposal (MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE):
Clarify that it in general is an error (the effect is not defined
but in general no error will be signalled) for code executed during a
"structure traversing" operation to destructively modify the
structure in a way that might affect the ongoing traversal operation.
For list traversal operations, this means that the cdr chain of the
list may not be destructively modified.
For array traversal operations, the array may not be adjusted and
its fill-pointer, if any, may not be changed.
For hash tables, new elements may not be added or deleted EXCEPT
that the element corresponding to the current hash key may be
changed or removed.
For packages, new symbols may not be interned in or uninterned from
the package being traversed or any package that it uses EXCEPT that
the current symbol may be uninterned from the package being traversed
in a DO-SYMBOLS.
Note: This proposal is intended to clarify restrictions on user code
for use with structure manipulators which are not inherently
destructive. Other operators, such as DELETE-DUPLICATES or NREVERSE,
may have much more complicated restrictions and are intentionally not
treated by this proposal. See the issue REMF-DESTRUCTION-UNSPECIFIED
for more discussion of such issues.
Test Case:
(LET* ((L (LIST 'A 'B 'C)) (LL L) (I 0))
(DOLIST (FOO L)
(INCF I)
(IF (EQ FOO 'B)
(SETF (CDR LL) NIL)
(POP LL)))
(LIST I L)) might return (2 (A B)) or (3 (A B)), for example.
Rationale:
This clarifies the status quo.
Also, the likelihood that the user will want to destructively alter a
structure while it is being traversed is low. The likelihood that such
code would be readable and maintainable is also low. The likelihood
that a compiler could do some interesting optimization if this point
were not pinned down is high enough to be the overriding consideration
in this case.
Current Practice:
The implementation of DOLIST in Symbolics Genera, KCL, and PopLog Common Lisp
returns (3 (A B)) for the test case.
Cost to Implementors:
None. This simply makes the status quo explicit.
Cost to Users:
Technically none. People who were mistakenly assuming that CLtL guaranteed
things which it does not might be inclined to rewrite their code in a more
portable way.
Cost of Non-Adoption:
Users would be less informed.
Benefits:
users would be more informed.
Aesthetics:
Some might say it would be clearer to define this one way or the other, but
advocates of both camps exist and their arguments are fairly symmetric.
In any case, since this is a proposal to preserve the status quo, it has no
major impact on aesthetics.
Discussion:
This idea for this proposal was suggested by the Japanese community.
Pitman drafted the formal proposal and supports the EXPLICITLY-VAGUE proposal.
Moon generally supported version 1 of this proposal, but had some specific
criticisms about weakness of the wording which this version is an attempt to fix.
∂09-Jun-88 1525 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 15:25:16 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 15:24:14 PDT
Received: from bhopal.lucid.com by edsel id AA16555g; Thu, 9 Jun 88 15:19:42 PDT
Received: by bhopal id AA25468g; Thu, 9 Jun 88 15:18:17 PDT
Date: Thu, 9 Jun 88 15:18:17 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806092218.AA25468@bhopal.lucid.com>
To: Masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu, labrea!cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 12:39 PDT <880608-123958-2954@Xerox>
Subject: Issue: DECLARATION-SCOPE (Version 2)
Did you really want to distribute this to the X3J13 committee as a whole?
I had proposed a major rewrite of this issue, based on treating DECLARE
simply as a lexical construct, but haven't had the time to work on it before
the upcoming meeting. I'd hoped to see cleanup subcommittee discuss it
again before bringing the issue to the committee as a whole.
-- JonL --
∂09-Jun-88 1726 CL-Cleanup-mailer Re: X3 subcommittee room
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jun 88 17:26:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 88 17:19:51 PDT
Date: 9 Jun 88 16:45 PDT
From: masinter.pa@Xerox.COM
Subject: Re: X3 subcommittee room
In-reply-to: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>'s message of Thu, 9 Jun
88 09:48:04 PDT
To: edsel!jlz@labrea.stanford.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880609-171951-5790@Xerox>
I didn't hear from many other folks about the subcommittee meeting, but the ones
I did hear from I think are expecting to meet tuesday morning. So lets
tentatively book both Monday at Symbolics and Tuesday at the hotel, since
there's really more than a mornings worth of stuff to do.
∂09-Jun-88 2120 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 21:20:34 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 21:18:37 PDT
Received: from bhopal.lucid.com by edsel id AA17893g; Thu, 9 Jun 88 21:10:37 PDT
Received: by bhopal id AA26479g; Thu, 9 Jun 88 21:09:17 PDT
Date: Thu, 9 Jun 88 21:09:17 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806100409.AA26479@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: x3j13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 17:47 PDT <880608-174735-3615@Xerox>
Subject: Issue: EQUAL-STRUCTURE (Version 2)
I thought you were going to incorporate my comments into this issue, which
I sent in reply to its first presentation:
Date: Fri, 18 Mar 88 21:21:51 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Fri, 18 Mar 88 17:39 EST <880318173922.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 1)
Generally ok write-up of the issues. You left out the option of adding
a jillion-skillion new functions -- one for each conceivable kind of
equivalence relation between s-expressions. But that's ok; I want to
focus on just one of your proposals.
re: Proposal (EQUAL-STRUCTURE:DESCEND):
Change EQUAL and EQUALP to descend structure slots.
EQUALP is already documented to descend structures (CLtL, p81). So this
proposal should just say "Change EQUAL ...".
Had all the negative arguments against this particular proposal -- the one
you call (EQUAL-STRUCTURE:DESCEND) -- been thought of 6 years ago, CL could
not even have an EQUALP function. The logical conclusion of these
"technical details" arguments is that EQUAL cannot be defined either.
These arguments go roughly as follows:
(1) The equivalence which EQUAL implements is not graph-isomorphism --
which *is* uniquely defined -- but rather an ill-defined one
making reference to the underspecified notion of "printing".
Attempts to make it more precise are merely arbitrary.
(2) EQUAL is not a total function since it is permitted to run amok
on circular structures. In fact, it is much more "likely" that
defstruct instances will contain ultimately circular links than
that cons cells will; hence one will "probably" lose more much
often if EQUAL were to descend structures.
The more "wizard", or "theorist" one is, the more compelling the above
arguments seem. On the other hand, the more a "user" one is, the more
likely he will argue as follows:
I've used the EQUAL function for over 15 years, and have almost never
been dissatisfied with it, as the Doctors of Technology say I should be;
and every instance of dissatisfaction was due to its failue to descend
through pointer vectors. I keep my house in order, and know exactly
how my data pyramids are built up; so why should I be punished just
because some Conehead somewhere got lost playing around with his
Klein bottles and Moebius strips?
All the problems alleged for EQUALP's descent into structures also apply
to EQUAL's descent into lists; it's only a matter of probabilities. Hence,
I don't believe this issue can be settled by technical discussion.
The only non-time-wasting effort I can see to do from now on is to look for
some way to present our dilemma to a broad "user" community. We could try
to tell them, in cursory terms and few words, of the technical arguments
that show EQUAL (and EQUALP) to be ill-behaved functions. Then let them
decide (by straw vote?) if the extra functionality provided by this proposal
is worth the extra risk.
Related Issues:
-- Are DEFSTRUCT-defined types and CONS, ARRAY, HASH-TABLE, PACKAGE,
READTABLE, STREAM, etc. pairwise disjoint?
-- Will CLOS require EQUAL to be "generic"? Also, what about COPY?
-- JonL --
∂09-Jun-88 2123 CL-Cleanup-mailer X3 subcommittee room
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 21:23:01 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 21:21:25 PDT
Received: from bhopal.lucid.com by edsel id AA17929g; Thu, 9 Jun 88 21:17:19 PDT
Received: by bhopal id AA26494g; Thu, 9 Jun 88 21:15:57 PDT
Date: Thu, 9 Jun 88 21:15:57 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806100415.AA26494@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: edsel!jlz@labrea.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 9 Jun 88 16:45 PDT <880609-171951-5790@Xerox>
Subject: X3 subcommittee room
re: So lets tentatively book both Monday at Symbolics and Tuesday at the
hotel, since there's really more than a mornings worth of stuff to do.
Don't book it during 2pm to 5pm on Monday -- we have had the Iteration
subcommittee meeting scheduled for that time slot for a long time, and
there is substantial overlap of membership.
-- JonL --
∂09-Jun-88 2136 CL-Cleanup-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 21:36:30 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 21:35:26 PDT
Received: from bhopal.lucid.com by edsel id AA18027g; Thu, 9 Jun 88 21:27:54 PDT
Received: by bhopal id AA26522g; Thu, 9 Jun 88 21:26:35 PDT
Date: Thu, 9 Jun 88 21:26:35 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806100426.AA26522@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 20:24 PDT <880608-202925-3823@Xerox>
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION
Touretzky actually said he would alter his proposal to account for the
:rehash-size and :rehash-threshold omissions; but this version of the
proposaldoesn't show that. I remember remarking that you still can't
call the objects "first class" if the printed representation cannot be
read in as an equivalent copy; and the fact that CL has some other datatypes
that aren't "first class" doesn't argue for doing something substandard
for hash-tables. I don't seem to have a copy of the mail from Dave in
which he said he would alter his proposal.
Date: Mon, 23 May 88 15:37:48 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
To: labrea!Dave.Touretzky@CS.CMU.EDU
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Mon, 23 May 88 11:27:58 EDT <361.580404478@DST.BOLTZ.CS.CMU.EDU>
Subject: HASH-TABLE-PRINTED-REPRESENTATION
re: One problem with the currently proposed #H notation is that it provides
no way to specify a rehash-size or rehash-threshold. This should not be
a fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is
also shared by #nA notation.
I think this is a fatal flaw. The fact that *some* complex classes of
arrays also share this fatal flaw is no argument for retaining it. It
is still the case that simple arrays of the more common element types
do not have the flaw; and several years ago there was some discussion
on how to fix other manifestations of the flaw on multi-dimensional arrays.
-- JonL --
∂09-Jun-88 2314 CL-Cleanup-mailer Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jun 88 23:14:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 88 23:13:19 PDT
Date: 9 Jun 88 23:13 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION
In-reply-to: Jon L White <edsel!jonl@labrea.stanford.edu>'s message of Thu, 9
Jun 88 21:26:35 PDT
To: edsel!jonl@labrea.stanford.edu
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <880609-231319-6124@Xerox>
Note the word DRAFT repeated twice. I'd hate to see Dave update the proposal
just to see it rejected by X3J13. This was far enough along that I thought we
might be able to get a sense of whether *anything* like this was acceptable.
Date: 8 Jun 88 20:24 PDT
From: Masinter.pa
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION
to: X3J13@Sail.stanford.edu
cc: masinter
reply-to: cl-cleanup@Sail.stanford.edu
line-fold: NO
This draft is for discussion at the June 1988 X3J13 meeting.
!
Status: DRAFT
Issue: HASH-TABLE-PRINTED-PREPRESENTATION
∂09-Jun-88 2357 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jun 88 23:57:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 88 23:56:28 PDT
Date: 9 Jun 88 23:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
In-reply-to: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK's message of Thu, 9 Jun 88
10:02:42 BST
To: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <880609-235628-6152@Xerox>
The Rationale is probably misstated. The problem is really that it is difficult
to specify what error gets signalled when -- when the DEFSTRUCT macro gets
expanded? Or when the macro expansion gets executed?
Checking the error is certainly a good idea.
∂10-Jun-88 0000 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 00:00:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 88 23:59:25 PDT
Date: 9 Jun 88 23:59 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: EQUAL-STRUCTURE (Version 2)
In-reply-to: Jon L White <edsel!jonl@labrea.stanford.edu>'s message of Thu, 9
Jun 88 21:09:17 PDT
To: edsel!jonl@labrea.stanford.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880609-235925-6154@Xerox>
In this case, I had misfiled your message and did not see it when I generated
version 2. I'm sorry.
∂10-Jun-88 0056 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 00:56:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 00:45:32 PDT
Date: 10 Jun 88 00:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-SUB-METHODS (Version 4)
In-reply-to: Jon L White <edsel!jonl@labrea.stanford.edu>'s message of Thu, 26
May 88 19:29:49 PDT
To: edsel!jonl@labrea.stanford.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880610-004532-6175@Xerox>
My original take on this was that it was close to release status, but I think it
deserves to have Moon's comments incorporated. My personal preference would to
cast it in imperative mode rather than first person plural but I wouldn't hold
it up for that.
My reading on this issue is that, once cl-cleanup gets it sorted out, there will
be no controversy in X3J13.
∂10-Jun-88 0159 CL-Cleanup-mailer [masinter.pa: Issue: COERCE-INCOMPLETE]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 01:59:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 01:58:32 PDT
Date: 10 Jun 88 01:58 PDT
From: Masinter.pa@Xerox.COM
Subject: [masinter.pa: Issue: COERCE-INCOMPLETE]
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <880610-015832-6234@Xerox>
This issue is for discussion in the subcommittee.
----- Begin Forwarded Messages -----
From: masinter.pa
Date: 28 Feb 88 8:07:18 PST
Subject: Issue: COERCE-INCOMPLETE
To: cl-cleanup@sail.stanford.edu
Message-ID: <880228-080805-2138@Xerox>
I'm not really back until next week, but this came in for consideration...
----------
Return-Path: <@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET>
Received: from RELAY.CS.NET by Xerox.COM ; 25 FEB 88 23:39:52 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa07232; 26 Feb 88 2:16 EST
Received: from utokyo-relay by RELAY.CS.NET id aa26262; 26 Feb 88 2:06 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA19019; Fri, 26 Feb 88 15:54:40 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.3Junet-1.0)
id AA12493; Fri, 26 Feb 88 15:55:57+0900
Date: Fri, 26 Feb 88 15:55:57+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8802260655.AA12493@tansei.cc.u-tokyo.junet>
To: ida%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET, masinter.pa
Subject: Coercion
Dear Larry Masinter,
I wrote my opinion on coercion which is attached consulting your suggestion on the format.
Please find and use if you think it is valuable to have.
Masayuki Ida
--------------------------------------------------------------------
Issue: Coerce
Reference: coerce (CLtL p50)
Category: change
Edit history: version 1 by M.Ida, 26-Feb-1988
Problem Description:
--------------------
Problem 1:
Coerce is not symmetric or not generic among data types.
In CLtL, Coerce is defined in page 50 and 51 that,
1) a sequence type may be converted to any other sequence type.
2)Some strings, symbols, and integers may be converted to characters.
2-1) If object is a string of length 1,
then the sole element of the string is returned.
2-2) If object is a symbol whose print name is of length 1,
then the sole element of the print name is returned.
2-3) If object is an integer n,
then (int-char n) is returned.
3) any non-complex number can be converted to a XXX-float.
4) any number can be converted to a complex number.
The next table shows that how coerce is not symmetric among character,
string, symbol and integer.
TABLE 1. Possible Conversions among character, string,symbol, integer
type of conversion provided functions coercion under the CLtL
character -> string string X
character <- string coerce (if the string has only one char.) O
character -> symbol (intern (string @i[ch])) X
character <- symbol coerce (if pname length is 1) O
character -> integer char-code, char-int X
character <- integer code-char (zero font-, zero bits- attrib.) O
int-char (any font- and any bits-)
string -> symbol intern, make-symbol X
string <- symbol string, symbol-name X
string -> integer (char-code (coerce @i[string] 'character)) X
string <- integer (string (code-char @i[integer])) X
symbol -> integer (char-code (coerce @i[symbol] 'character)) X
symbol <- integer (intern (string (code-char @i[integer]))) X
Problem 2:
The function of coerce for character is defined to act as char-int/int-char
not as char-code/code-char.
Proposal: Coerce :replace
-------------------------
COERCE should be more generalized for string, symbol, integer, and character
data types. The observations show there are
no problem if extensions are fully written out in the details.
Here is an extension to the current coerce definition using the CLOS.
(defmethod coerce ((x character) (y (eql string))) (string x))
(defmethod coerce ((x character) (y (eql symbol))) (intern (string x)))
(defmethod coerce ((x character) (y (eql integer))) (char-code x))
(defmethod coerce ((x string) (y (eql symbol))) (intern x))
(defmethod coerce ((x symbol) (y (eql string))) (string x))
(defmethod coerce ((x string) (y (eql integer)))
(char-code (coerce x 'character)))
(defmethod coerce ((x integer) (y (eql string))) (string (code-char x)))
(defmethod coerce ((x symbol) (y (eql integer)))
(char-code (coerce x 'character)))
(defmethod coerce ((x integer) (y (eql symbol)))
(intern (sting (code-char x))))
(defmethod coerce ((x integer) (y (eql character)))
(code-char x)) ; redefinition. CLtL defines as int-char
The keys are
a) ignore char-bits and char-font upon the conversion of characters,
assuming font-attribute will be flushed from the language spec.
b) ignore the package name upon the conversion of symbols.
(package name has no role upon the conversion.)
c) the created symbol will be interned to the current package.
Rationale:
----------
By extending the definition as this document suggests, the functionality
of coerce is symmetric among characters, strings, symbols and integers.
Current Practice:
Cost to implementors:
Cost to users:
Benefits:
Aesthetics:
Discussion:
Among the functions in Table 1, we can pick up the role of @t[STRING] function.
@T[STRING] has odd definition. It was also
the starting point of discussions described in the following.
The problems or the awkwards are mainly on the design of the symmetry of
the function names.
We would start the discussion with the following two observations.@*
i) @t[(string @i(x))] is OK. But, @t[(coerce @i(x) 'string)] is illegal.@*
While, @t[(character @i(x))] is OK. And @t[(coerce @i(x) 'character)] is OK too..@*
ii) To convert from a symbol to a string, use @t[SYMBOL-NAME] or @t[STRING].
While, to convert from a string to a symbol,
use @t[MAKE-SYMBOL] to an uninterned symbol, or
use @t[INTERN] to an interned symbol.@*
@*
@*
@b[ Discussions on Coercion in Common-Lisp E-mails 1986]
The awkward were discussed already in Common-lisp E-mails.
The author checked the 10M bytes E-mails on disk.
The discussions around @t[coerce] were almost in 1986, and not much in 1985 or before.
The sequence of our concern started by a mail of fateman@@dali.berkeley.edu,
dated Fri, 16 May 1986 15:40 PDT as follows.@*
1) fateman@@dali.berkeley.edu fri 16 may 1986 15:40 PDT:@*
This mail describes the same issue as for STRING function.
2) jeff@@aiva.edinburgh.ac.uk sun 18 may 17:17 GMT@*
@t[ ... 'string' applied to a sequence of characters gives an error, typically
saying the sequence can't be coerced to a string, but 'coerce' will in fact coerce it...]
3) gls@@think.com, Mon 19 may 1986 12:20 EDT@*
@begin[t]Research shows that the Common Lisp archives up to a couple of months
ago contains 18 messages that mention @t[COERCE]. None explicitly addresses
this issue, but the general tone of the messages is one of conservatism.
I now remember that this issue was tied up with the design of the
sequence functions. There was real resistance to letting symbols be
treated as general sequences, and so the general decision was made that
string-specific functions would accept symbols, but general sequence
functions would not. ...@end[t] To check his talk, @b[3.3] shows all the
early discussions on @t[coerce] the author can find.
4) fahlman@@c.cs.cmu.edu Mon, 19 May 1986 20:44 EDT@*
@t[... I would not object to generalizing coerce to handle some of the
additional cases that people imagine it ought to handle.]
@begin[verbatim]
5) cfry@@oz.ai.mit.edu, Tue, 20 May 1986 03:21 EDT@*
... Coercion is a powerful, easy to remember concept. I think it should be
extended as much as possible. ... :
(coerce #\a 'string) => "a"
(coerce 123 'string) => "123"
(coerce #\a 'integer) => (char-code #\a) ; explicitly not provided CLtL p52.
It appears that the only reason is that no one could decide on using
char-code or char-int for the conversion so they chose not to do it
at all. This reasoning is odd. Pick the most frequently used way,
document it, and permit it. Same argument for coercion of numeric types.
Further out extensions might be:
(coerce #'foo 'compiled-function) => returns a compiled function object
...
(coerce string-1 'pathname)
(coerce bit-vector-1 'integer) ...
Undoubtedly there are other coercions which would make sense. ...
Users would save a lot of manual searching if coerce was extended.
@end[verbatim]
6) Eliot@@umass-cs.csnet, Tue 20 May 1986 15:31 EST@*
@t[Coercing symbols to stings is fine, as long as NIL is treated as
the empty SEQUENCE, rather than as a symbol.]
@begin[verbatim]
7) REM@@IMSSS, 19 May 09:34 PST referring to the mail of gls saying
that "@t[COERCE] was limited to ... sequence and numerical coercions".
This is one of the bad points of many LISPs, including CL, functions that
are miss-named or otherwise don't do what you'd expect from their name.
... I hope the international standards committee will fix this kind of
problem so programmers reading somebody else's code can have the meaning
apparent in most cases form general programming tradition rather than
having to constantly check the manual to see if the function does what
it seems to say it would do.
8) DCP@@scrc-quabbin.arpa, Wed, 21 May 1986 16:45 EDT,@*
Does (coerce @i(symbol) 'string) return
(symbol-name @i(symbol)), or (format nil "~S" @i(symbol)),
or (format nil "~A::~A"
(package-name (symbol-package @i(symbol))) (symbol-name @i(symbol)))
or what ? If this weren't enough, added in with my personal views of
style and functionality, for me to want to help veto this coercion, the
special casing of NIL certainly would. Programs should reflect their
meaning. A string is a sequence, a symbol is not. Why shouldn't
@# (coerce :ascii-EOT 'integer)
work? The answer is that the requested behavior is not a coercion
between compatible types, it is a functional translation between human
understandable names for the ascii control characters and the integers
that are their corresponding values.
@end[verbatim]
We found that there is a possibility to extend the semantics of @t[coerce]
to cope with more generic types. It should be noted that the two key designers of Common Lisp
mentioned their opinions, and they do not always be against to the extension.
The discussion was stopped at this point and we cannot find their continuation yet.
We find from this story that @*
1) If we don't care about the package, we may extend the coerce
to the function from a symbol to a string, @*
2) If we are free to care about the font- and bits- attribute,
we may extend the coerce to include the function from a character to other types.@*
@*
@*
@b[ Early discussions on coercion]
The following sequence was picked up from the archives. They are almost all the meaningful
talk the author can find. They were in 1983, one year before @i(CLtL) was published.
@begin(verbatim)
1) Guy Steele, dated 27 May 83 01:23:14 EDT, (in the summary of the discussion
with DLW and moon upon the laser edition update)
a)No.38: it is noted that DLW said "coercing of characters to integers
should probably be allowed too." and this point was marked as {controversial}.
b) Moon's comment. "if (string x) <=> (coerce x 'string) exactly, say so.
Both of these should coerce a character into a 1-element string; neither says
so now. The old argument against this, that people might expect string of a
number to give not numbers." and Guy Steele agreed.
N.197: {gloss} string is required to signal an error if its argument is not a
string and not a symbol. This is wrong; it should convert a character to a
one-character string. Also it says that string will not convert a sequence of
characters into a string, but coerce will. This might be all right, except
under coerce it says that when coercing to a string the implementation is
allowed to return a more general type. ... Also the coerce writeup
doesn't say anything for or against coercing from a character to a 1-long string.
{controversial} {will clarify}
2) Fahlman, dated Sat, 28 May 1983 22:34 EDT;
At least, I would like you to consider dropping these. ...
Page 38: Coercing of characters to integers is not a very useful operation in
portable code if the language spec does not specify the correspondence (and
Common Lisp does not). Do you still want to propose that we add this coercion?
I'm not particularly opposed, I just worry that users will find it too easy to
inadvertently do non-portable things if given this coercion.
3) Moon, date: sat, 28 May 1983, 22:40-EDT
I don't think coercion of characters to integers should be allowed, because
how do you know whether you want the char-code or what. Dan was probably
just stuck in our old mindset from not having character objects on the Lisp
machine. Coercion of characters to strings, however, I believe is useful.
4) Daniel L.Weinreb, Date: Tuesday, 31 May 1983, 15:40-EDT
... It's OK with me if COERCE doesn't coerce characters to integers. However,
I strongly suggest putting in a clarification note to that effect... Or maybe
a Rationale note saying that it doesn't because it wouldn't be clear what to do
about the char-code versus whole character, and telling you to use the particularly
function instead. This note is for the benefit of users more than of implementors.
5) Scott E. Fahlman, Date: Wed, 1 Jun 1983 01:47 EDT < referring 4)>
It's OK with me if COERCE doesn't coerce characters to integers.
However, I strongly suggest putting in a clarification note to that ...
<< I assume Guy will do this. >>
@end(verbatim)
As far as we can see from this talk, that the process of making a coercion between
characters and integers be restricted such that char-to-integer conversion is not provided,
while integer-to-char is. The coercions from characters to integers are
purposely not provided; @t[char-code] or @t[char-int] may be used explicitly to
perform such conversions (See @b[Appendix] for the definitions of @t[char-code]
and @t[char-int]).
The difference between @t(char-int) and @t(char-code) is on the treatment of
@i(font) and @i(bits) attributes.
If these two attributes have no significant meaning and are ignored by everyone,
we can make the story much simpler. (And @b[4.] describes at least font- is
not alive).
----- End Forwarded Messages -----
∂10-Jun-88 0205 CL-Cleanup-mailer Issue: FOLLOW-SYNONYM-STREAM
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 02:04:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 02:02:49 PDT
Date: 10 Jun 88 02:02 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FOLLOW-SYNONYM-STREAM
To: cl-cleanup@sail.stanford.edu
Message-ID: <880610-020249-6237@Xerox>
----- Begin Forwarded Messages -----
Return-Path: <@SAIL.STANFORD.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: Xerox-Common-Lisp↑.x
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 19 DEC 86 12:59:09
PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Dec 86
12:22:04 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 28330; Fri 19-Dec-86
15:20:50 EST
Date: Fri, 19 Dec 86 15:19 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FOLLOW-SYNONYM-STREAM
To: Common-Lisp@SAIL.STANFORD.EDU
Message-ID: <861219151955.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
From time to time, I find myself doing:
(LET ((*TERMINAL-IO* *STANDARD-OUTPUT*))
...)
in a multi-window system in order to temporarily change my interaction to the
same window as output has been redirected to. On the Lisp Machine (and probably
on many or most other implementations), *STANDARD-OUTPUT* can sometimes (often)
contain a synonym-stream for *TERMINAL-IO* and the result of the operation
above is to send output to a stream which is a (circular) synonym for itself.
The kind of lossage this results in is fairly severe because *DEBUG-IO* is often
a synonym for *TERMINAL-IO* and if that is in turn a synonym for *TERMINAL-IO*,
then the debugger cannot run.
A couple of things would make this problem more tractable:
SYNONYM-STREAM-P object [Function]
This accepts any kind of argument. If the argument is not a synonym
stream, then NIL is returned. If the argument is a synonym stream,
then the symbol for which the object is a synonym is returned.
FOLLOW-SYNONYM-STREAM stream [Function]
This accepts a stream and returns the result of following that stream
through any number of synonym stream indirections (including zero).
While I'm on page 329, I think we should also have the following functions
(or functionalities) which I have needed at other times:
BROADCAST-STREAM-P object [Function]
CONCATENATED-STREAM-P stream [Function]
TWO-WAY-STREAM-P [Function]
...
This accepts any kind of argument. It returns T if the argument is a
{concatenated/broadcast/two-way/...} stream and NIL if the argument is
any other kind of stream.
EXPAND-BROADCAST-STREAM broadcast-stream [Function]
EXPAND-CONCATENATED-STREAM concatenated-stream [Function]
EXPAND-TWO-WAY-STREAM two-way-stream [Function]
...
This accepts a {broadcast/concatenated/two-way/...} stream and returns
a list of the streams which were used to compose it (in an order
compatible with the order of arguments to the creation function).
Note: Implementations are allowed, but not required, to return the
same list every time. The result list should not be destructively modified.
----- End Forwarded Messages -----
∂10-Jun-88 0223 CL-Cleanup-mailer Issue: FUNCTION-ARGUMENT-TYPE-SEMANTICS]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 02:22:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 02:20:50 PDT
Date: 10 Jun 88 02:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-ARGUMENT-TYPE-SEMANTICS]
To: cl-cleanup@sail.stanford.edu
Message-ID: <880610-022050-6259@Xerox>
Here is a (fairly random) subset of the mail text on this issue. This is partly
to jog your memory.
A careful reading of CLtL p. 47 suggests, at least to some folks, that (proclaim
'(function my-function (integer))) does *not* imply that it is an error to pass
a non-integer to my-function. I've enclosed most of the relevant mail on the
subject. My inclination is to specify in the standard that such declarations
mean what (apparently) almost everyone has taken them to mean, rather than what
CLtL says.
What does
(declare (function my-cons (float string) list) )
mean? It says that my-cons is a function that can "accept a floating-point
number and a string (among other things), and its result is an object of type
list...."
The problem is that the argument type declaration here is of absolutely no use.
That the declared function can accept a float and a string among other things
has no content. It doesn't say that it is illegal to pass a non-float as the
first argument. It says that if you pass a float, its ok, and if you pass a
non-float, it might be OK too. Isn't that the same as saying (function my-cons
(t t) list)?
It would be more valuable as far as I can see to say that a (function (float
string) list) is one to which *only* a float and a string can be passed. Perhaps
someone familiar with an implementation that pays attention to these
declarations can explain what they are used to denote?
2) On the specific issue at hand: I'm inclined to be more sympathetic to
allowing &REST <element-type>; function type specifiers are, after all, already
a specialized little language -- the &KEY arguments have a separate syntax which
only vaguely resembles the original lambda list syntax, for example.
3) Should the function type specifier also allow &ALLOW-OTHER-KEYS?
Here is some (old) mail from the Common Lisp mailing list which touches on some
related issues:
!
Date: 18 Apr 1986 16:07-EST
Subject: Type Specifier: (OR (FUNCTION ...) ...)
From: NGALL@G.BBN.COM
Question: What is the 'most informative' type specifier for the CL function
COPY-SEQ?
How 'bout? (function (sequence) sequence)
Unfortunately, this does not tell the reader nor the compiler that if the
argument is a list, then the result is also a list, and vice versa. So how
about this:
(or (function (list) list)
(function (vector) vector))
This is syntactically valid CL, and the definition of the OR and FUNCTION type
specifiers makes it meaningful. Unfortunately, it is not clear from pg. 158
whether or not the following is legal:
(proclaim '(ftype (or (function (list) list)
(function (vector) vector))
copy-seq))
It is not legal in VaxLisp, and my guess is that there aren't any
implementations that would do the right thing with it. So I would like to
propose that such a use of OR/FUNCTION be considered legal CL.
Without such a declaration, one is forced to either wrap (the <result-type> ...)
around all calls to such functions or to DECLARE a restricted version of
FUNCTION in the appropriate places, e.g., (defun foo (alist avector)
(declare (list alist)
(vector avector)
(function copy-seq (list) list))
(zap (copy-seq alist)
(let ()
(declare (function copy-seq (vector) vector))
(zoop (copy-seq avector))))
Either method is a real pain.
This use of OR would give CL something akin to Ada overloading. It allows the
overloading of multiple 'function type signatures' on a single function name.
Such overloading is already implicit throughout CL (esp. the seq. functions).
My proposal would merely allow a way of describing it.
-- Nick
!
Date: Mon, 4 Nov 85 22:29 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Declaring Functions
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
Message-ID: <851104222904.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
In-Reply-To: <8511012045.AA07112@utah-orion.ARPA>
Date: Fri, 1 Nov 85 13:45:55 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
The notion of a function type is mentioned in two places: p. 47 of the
CLM, where the (function ...) type specifier is defined, and p. 158-159,
where (ftype ...) and (function ...) are defined as options to declare.
Are they intended to be the same?
Read page 159 more carefully. It explains that they have the same meaning, but
are syntactically different. "function" has the disadvantage that you can only
declare one thing per clause, unlike most other declarations, but the advantage
that it looks mildly like "defun".
If so, then the second definition
should say that keywords and a (values ...) type specifier are allowed.
If by keywords you mean &optional and friends, it isn't strictly necessary to
repeat that, although it would sure clear things up if there were a cross
reference in the book.
However, there appears to be a typo on page 159. The form following the phrase
"entirely equivalent to", which currently reads
(ftype (function arglist result-type1 result-type2 ...) name)
ought to read
(ftype (function arglist (values result-type1 result-type2 ...)) name)
in order to be consistent with page 47.
----- Next Message -----
Date: Wed, 2 Dec 87 21:42:47 PST
From: Pavel.pa
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: <871202-204108-1072@Xerox>
To: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-214253-1099@Xerox>
Larry says:
``I don't know what (declare (function my-cons (float string) list) ) means.''
It is usual in type theory for this to be read as an implication:
IF
you pass a float and a string to MY-CONS
THEN
MY-CONS is guaranteed to return a list.
More rigorously, a type theorist would see (function my-cons (float string)
list) as representing the set of all functions that, when applied to a float and
a string, return a list.
Under this view of types, we understand the constructor OR to be set-union (that
is, the type (OR t1 t2) represents the set of values in the union of the sets
represented by t1 and t2) and the AND constructor is thus set intersection.
Under this view, Nick Gall gives the wrong answer to his question about a
specific type for COPY-SEQ when he claims that a good one would be
(or (function (list) list)
(function (vector) vector))
Since this does not guarantee that COPY-SEQ will return a list when applied to a
list; in fact, a function in this type might very well bomb when presented with
a list. In general, ORing function types isn't very helpful. What he really
wants here is AND, not OR:
(and (function (list) list)
(function (vector) vector))
This represents the set of functions that both map lists to lists and vectors to
vectors.
Let me point out that I'm not claiming that this is how CLtL intends function
types to be interpreted, just that this meaning has proven very convenient for
most uses.
Pavel
----- Next Message -----
Date: Wed, 2 Dec 87 22:36:17 PST
From: Pavel.pa
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: <871202-222029-1111@Xerox>
To: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-223623-1122@Xerox>
That's right. Unless you know something about the types of the arguments, you
can assume nothing about the type of the result.
Pavel
----- Next Message -----
Date: Thu, 3 Dec 87 16:30 EST
Message-ID: <RAM.12355605918.BABYL@>
From: Ram@C.CS.CMU.EDU
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>, cl-cleanup@SAIL.STANFORD.EDU,
Masinter.pa, sandra%orion@CS.UTAH.EDU
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Msg of 3 Dec 1987 12:52-EST from Kent M Pitman <KMP at
STONY-BROOK.SCRC.Symbolics.COM>
My compiler cleanup proposal addresses a number of the issues being
discussed here. We already went around once on cl-cleanup about the
meaning function type.
In my initial proposal, I had assumed a strict interpretation of
function type. It was pointed out to me, that not only is CLTL very
clear about its non-restrictive interpretation, it is also very
difficult to use a strict interpretation within the framework of the
current type system.
Basically, the problem is that if you think about "function type
declarations" as being declarations about the type of the object which
is the function, then it isn't possible to use a strict
interpretation. If you attempt to do so, then there will be cases
where a type declaration is necessary for a program to be correct, and
removing declarations can cause a program to be incorrect. In
addition to problems with defining where declarations are necessary,
requiring declarations is also clearly in conflict with the stated
goals for declarations in Common Lisp.
Basically, the reason for this non-intuitive result is that a
declaration of a function's type actually makes a statement about what
definitions are legal, rather than what calls are legal. What a
compiler really wants to know is what calls are legal.
The solution I suggest in my proposal is to introduce a mechanism that
allows arbitrary information about a function definition to be bound
at compile time. You don't declare the function type, you just define
the function, with any appropriate argument type declarations.
Since you have asserted that calls to the function can be bound at
compile time, the compiler can apply any assertions on the formal
parameters to the actual parameters and use type information derived
from the definition as the type of the call result.
Early-binding of function names also allows many other optimizations
such as "inline expansion" and "block compilation".
Before people flame uncotrollably about the horror of static function
binding in Lisp, I will point out that I don't propose that static
function binding be required, or even that it necessarily be the
default. It is also worth noting that the extent to which static
binding is actually done once it has been allowed is an implementation
decision. Declaring static binding doesn't necessarily prevent
incremental redefintion or reduce safety, it might only cause better
compiler warnings to be generated.
If this capability exists, then function type declarations (and
function types) are more useless than they currently are (if that is
even possible).
Rob
P.S. My proposal is <ram>cprop.txt on c.cs.cmu.edu
----- Next Message -----
Date: 7 Dec 87 14:40 PST
From: Masinter.pa
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Ram@C.CS.CMU.EDU's message of Thu, 3 Dec 87 16:30 EST
To: Ram@C.CS.CMU.EDU
cc: KMP@SCRC-STONY-BROOK.ARPA, cl-cleanup@SAIL.STANFORD.EDU, Masinter.pa,
sandra%orion@CS.UTAH.EDU
Ram: I've scanned your latest proposal, but it still doesn't seem to address the
minor issue at hand here:
What does
(declare (function (integer integer) t) foo)
imply?
We've discussed what it could mean, what it should mean, what CLtL says it
means, but I'd to hear about current practice. What, if anything, do current
implementations do with such declarations? Do any implementations pay attention
to the types of arguments in function declarations?
----- Next Message -----
Date: Thu, 3 Dec 87 12:52 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Masinter.pa
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
In-Reply-To: <871202-204108-1072@Xerox>
Message-ID: <871203125256.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 2 Dec 87 20:40 PST
From: Masinter.pa@Xerox.COM
...
(declare (function my-cons (float string) list) )
...
The problem is that the argument type declaration here is of absolutely
no use.
...
It would be more valuable as far as I can see to say that a
(function (float string) list)
is one to which *only* a float and a string can be passed. Perhaps
someone familiar with an implementation that pays attention to these
declarations can explain what they are used to denote?
In Maclisp, if you declared a function to take arguments (fixnum flonum),
for example, special tricks were allowed to be done with passing the arguments
without having to heap-cons them. You were required to only use this declaration
if you had made it available to the compiler at the time of compiling the
function
(so that it would have done the special tricks necessary to make the external
calling sequence work). The net effect was that the function had a naive entry
point (for people who didn't know about the declaration) and a magic entry point
for people who wanted to exploit the declaration information and bypass some
setup instructions.
In order to get this effect in CL, we have only to restrict the declaration of
a function to be exactly the declaration that the function was compiled under.
That is, there are a number of possible universes we could elect to be in:
* We could allow local function declarations to just say things we know to
be true, regardless of whether they were interesting. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)
This would tend to thwart interesting compilations because nothing in the
declaration would tell you anything useful about how the function was
compiled.
* We could allow local function declarations only if they restrict the
declaration under which the function was compiled. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
but not by
(LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)
This might thwart some interesting compilations because you wouldn't know
everything about the way the function was compiled, but you'd know some
information.
* We could allow local function declarations only if they exactly match
the declaration under which the function was compiled. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
but not by
(LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)
This would have the best chance of getting interesting compilations, I think.
* We could, as I guess Pavel is suggesting (though I lost or missed the
original mail), allow multiple declarations of the same function, in which
case the information provided would be of an entirely different nature (in
what amounts to a DEFMETHOD style) than what it's used for in the previous
three bullet items.
Presumably there are some gains to be had from this style. I have no feel for
how useful they are. An example, though, would be:
(PROCLAIM '(FUNCTION FOO (LIST) LIST))
(PROCLAIM '(FUNCTION FOO (VECTOR) VECTOR))
which would let you compile
(LENGTH (FOO (THE LIST L)))
into
(SYSTEM:LENGTH-ROUTINE-FOR-THINGS-KNOWN-TO-BE-OF-TYPE-LIST (FOO L))
[Sigh. I'd have called it SYSTEM:LIST-LENGTH, but that's taken by CLtL for
something that doesn't mean what I think of as LIST-LENGTH. A poor naming
decision if you ask me...]
* This is a placeholder to remind readers that the likelihood that this list is
exhaustive is fairly low.
This really gets at the heart of the problem, which is:
* Are declarations just for compilation or do they serve some more abstract
higher level goal (eg, "documentation").
* How important is exact-typep information vs typep information.
* How much of a modularity violation (or documentation constraint) is it to
have to know the exact conditions under which a function was compiled.
* How important are optimal compilations?
----- Next Message -----
Date: Thu, 3 Dec 87 11:57:05 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712031857.AA21459@orion.utah.edu>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: Masinter.pa, cl-cleanup@sail.stanford.edu, sandra%orion@cs.utah.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 3 Dec 87
12:52 EST
One reason for wanting to use a FUNCTION type specifier is that you may
only be concerned with how many arguments a function can take, and you
don't care at all about their types. Back when we were trying to
implement a CL compatibility package in PSL, we wanted to do the
matching of actual arguments to lambda variables at compile-time so we
could use the EXPR call protocol instead of the much slower NEXPR
protocol. (Basically, we had an EXPR entry point for every function
with a 1-1 correspondence between actual arguments and lambda
variables.) The problem is, you couldn't do the transformation on a
call unless you already knew something about the lambda list for the
function.
I agree that the argument type business is confusing and not very useful
in its current state. I'd like to say that
(LOCALLY (DECLARE (FTYPE (FUNCTION (INTEGER INTEGER) INTEGER) +))
(+ X Y))
is equivalent to
(THE INTEGER (+ (THE INTEGER X) (THE INTEGER Y)))
but I'm not sure that's exactly what CLtL is getting at.
-Sandra
-------
----- Next Message -----
Date: 03 Dec 87 11:23 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: cl-cleanup@SAIL.Stanford.EDU
I'd like to reiterate what Pavel said: the declaration
(declare (function my-cons (float string) list) )
means that the function MY-CONS accepts two arguments, the first at least
of the type FLOAT (it can be a more general type), and the second at least
of the type STRING; it returns one value which is of the type LIST (it
could be more specific).
Unfortunately, it does not mean that if the two arguments are of types
FLOAT and STRING then the result is of type LIST, which would be
useful.
Lucid has a variant of this called RESTRICTIVE-FTYPE (or something),
which would mean MY-CONS assumes it receives two arguments of types
FLOAT and STRING and produces something of type LIST.
See page 47 (CLtL), the last complete paragraph, to see this.
-rpg-
----- Next Message -----
Date: Thu, 3 Dec 87 14:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: sandra%orion@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Masinter.pa,
cl-cleanup@sail.stanford.edu
In-Reply-To: <8712031857.AA21459@orion.utah.edu>
Message-ID: <871203141725.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 3 Dec 87 11:57:05 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
One reason for wanting to use a FUNCTION type specifier is that you may
only be concerned with how many arguments a function can take, and you
don't care at all about their types. ...
Thanks for remembering to mention this issue. It pops into my head from time to
time
and then I always forget it before I get to the console.
Yes, the same style of issues as I raised in my last message applies to argument
number. eg, if I did
(PROCLAIM '(FUNCTION FOO (NUMBER NUMBER) NUMBER))
(DEFUN FOO (X Y) (+ X Y))
and later did:
(LOCALLY (DECLARE (FUNCTION FOO (FIXNUM &REST (LIST T)) FIXNUM)) ... (FOO ...)
...)
would I be within reason? ie, is there semantic impact to the &REST which goes
beyond
type declaring the rest of the arguments to be of type T? Am I also declaring
that the
function was in fact compiled believing that a &REST style argument pickup was
used
(and at the same point as I've specified it here). What about:
(PROCLAIM '(FUNCTION FOO (NUMBER &REST (LIST NUMBER)) NUMBER))
(DEFUN FOO (X &REST Y) (APPLY #'+ X Y))
and then later
(LOCALLY (DECLARE (FUNCTION FOO (NUMBER NUMBER &REST (LIST NUMBER)) NUMBER))
... (FOO ...at least two arguments...) ...)
In my CL conversion of Macsyma, I threw out all the *LEXPR declarations because
CL couldn't make any use of them and they were just clutter. (And they'd be
trivial
to re-conjure if they were ever needed.) But I felt funny as I did it because I
did
know I was throwing away information that would be interesting to some compilers
and that seemed sad, so I definitely agree that one way or another, this is a
real
issue.
----- Next Message -----
Date: 9 Dec 87 02:59 PST
From: Masinter.pa
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Ram@C.CS.CMU.EDU's message of Tue, 8 Dec 87 14:21 EST
To: Ram@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871209-030006-1558@Xerox>
I think I understand and agree with most of what you say, in particular "I think
that we should either entirely flush the concept of "function types" or change
the theory behind them. The CLtL interpretation is well-defined, but not very
useful. "
There are two components to your proposal: (1) what is allowed (and what it
means), and (2) how it is described in the standard.
I like the part of your proposal which is to change the interpretation of
function declarations to mean an implicit assertion of argument and value types
(the "restrictive interpretation").
I like defining (declare (type (function (frob grid) bunker) x)) to mean
(funcall x y z) has implicitly means (the bunker (funcall (the function x)
(the frob y) (the grid z)))
I don't see, however, that there is much leverage to removing FUNCTION from the
section on type specifiers. It would do some violence to the otherwise useful
concept of
(deftype binary-arithmetic () '(function (number number) number))
to be used in
(declare (ftype binary-arithmetic x y z)) .
I don't see at all that (funcall #'foo x y) doesn't mean (the t (funcall #'foo
(the integer x) (the integer y)))) given (declare (function foo (integer
integer) t)).
In the type propagation rules, you can transform funcall and apply expressions
using the asserted value of the function argument, and the asserted value type
of #'name is derived from the asserted ftype of name.
In this interpretation, AND would distribute nicely,
Given (proclaim '(function foo (s1 t1) v1)) and (declare (function foo (s2 t2)
v2)) you could assert that
(foo x y) => (the (and v1 v2) (foo (the (and s1 s2) x) (the (and t1 t2) y))).
(OR doesn't distribute as nicely, e.g., given (declare (ftype (or (function (s1
t1) v1) (function (s2 t2) v2)) foo)), there isn't a simple way to describe the
type assertions made for (foo x y).
We might even want to explicitly allow FUNCTION declarations in THE
expressions, as in
(funcall (the binary-arithmetic x) y z).
----- Next Message -----
Date: Tue, 8 Dec 87 14:21 EST
Message-ID: <RAM.12356893261.BABYL@>
From: Ram@C.CS.CMU.EDU
To: Masinter.pa
Cc: cl-cleanup@SAIL.STANFORD.EDU, KMP@SCRC-STONY-BROOK.ARPA,
sandra%orion@CS.UTAH.EDU
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Msg of 7 Dec 1987 17:40-EST from Masinter.pa at Xerox.COM
Date: Monday, 7 December 1987 17:40-EST
From: Masinter.pa at Xerox.COM
To: Ram at C.CS.CMU.EDU
cc: KMP at SCRC-STONY-BROOK.ARPA, cl-cleanup at SAIL.STANFORD.EDU,
Masinter.pa at Xerox.COM, sandra%orion at CS.UTAH.EDU
Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
[...] What does (declare (function (integer integer) t) foo) imply?
We've discussed what it could mean, what it should mean, what CLtL
says it means, but I'd to hear about current practice. What, if
anything, do current implementations do with such declarations? Do
any implementations pay attention to the types of arguments in
function declarations?
Our current compiler totally ignores function type declarations.
I am working on a new compiler that currently gives function type
declarations a strict interpretation, i.e. the function must be called
only with two integer arguments. (I suspect that this is like the
RESTRICTIVE-FTYPE declarations that someone from Lucid mentioned.) At
least as an interpretation for FTYPE, this is clearly wrong. I intend
to at least rename this declaration, and perhaps entirely flush it as
a user-visible facility.
I think that we should either entirely flush the concept of "function
types" or change the theory behind them. The CLtL interpretation is
well-defined, but not very useful. The intuitive strict
interpretation is useful, but is not a type declaration, at least in
the sense used in CLtL.
The restrictive interpretation can be modeled as a sort of magic
syntactic shorthand for a bunch of THE declarations at the call site:
(the t (foo (the integer x) (the integer y)))
But under this interpretation, a "function type" isn't a type at all,
since it isn't in any sense the type of the function object being
called. It wouldn't be meaningful to declare a variable or value to
have a function type. A "function type declaration" would be a piece
of magic recognized by the implementation that constrains calls to a
particular function variable.
If we did this, then the concept of a "function type specifier" should
be flushed, since "function types" can't be used in any of the ways
real types can. The "function type" syntax would become part of the
syntax peculiar to a "function type declaration". (A minor beneficial
side-effect is that it would make obvious the restriction on function
types in TYPEP.)
One problem that I have with this interpretation is that it makes the
evaluation of the functional position even more peculiar than it
already is. Since a "function type declaration" would be purely
syntactic, it would only take effect when there was a syntactic match,
i.e. an obvious normal call to a declared function variable. It would
probably be incorrect to do this transformation:
(funcall #'foo x y) ==>
(the t (funcall #'foo (the integer x) (the integer y))))
Rob
----- Next Message -----
Date: Wed, 9 Dec 87 08:00:48 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712091500.AA16131@orion.utah.edu>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Masinter.pa
Cc: Ram@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu, sandra%orion@cs.utah.edu
In-Reply-To: Masinter.pa@Xerox.COM, 9 Dec 87 02:59 PST
Date: 9 Dec 87 02:59 PST
From: Masinter.pa@Xerox.COM
Given (proclaim '(function foo (s1 t1) v1)) and (declare (function foo (s2 t2)
v2)) you could assert that
(foo x y) => (the (and v1 v2) (foo (the (and s1 s2) x) (the (and t1 t2) y))).
I disagree. The DECLARE should shadow the PROCLAIM; see p. 156 of
CLtL. Or is there another proposal in the works to change declaration
shadowing as well? :-)
-Sandra
-------
From: masinter.PA
Date: 16-Dec-87 1:32:02 PST
Subject: Current practice:argument types in function declarations
To: common-lisp@sail.stanford.edu
cc: masinter
The cleanup committee is considering various issues surrounding function
declarations, and, in particular, declarations of the types of arguments.
We've had considerable input about what such declarations could mean, should
mean, what CLtL says they mean. Rather than going over all of that, this is a
question about current practice:
What do current implementations actually do? What do current users actually use
have in their programs?
Is anyone aware of any (released? supported?) Common Lisp implementation that
pays any attention at all to the types of arguments, e.g., for which
(proclaim '(function my-function (list vector) t))
has any effect different from
(proclaim '(function my-function (t t) t))
?
Does anyone *have* any Common Lisp code which contains such declarations? What
is the intent of the declarations, other than as documentation?
-----------
Date: Wed, 16 Dec 87 06:50:49 PST
Message-Id: <8712161450.AA12099@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: masinter.PA, VANROGGEN@decwrl.dec.com
Subject: RE: Current practice:argument types in function declarations
VAX LISP certainly does heed such proclamations when compiling calls
to the declared functions. And we do have such code in our system.
---Walter
-----------------------
Date: 16 Dec 87 12:42 PST
From: Masinter.pa
Subject: RE: Current practice:argument types in function declarations
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Wed, 16 Dec 87
06:50:49 PST
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: masinter.PA
Sigh, I don't have a VAX LISP manual. In what way does it "heed such
proclaimations"?
For example, does VAX LISP assume that, given
(proclaim '(function my-function (integer symbol) t))
that it is an error to call
(my-function 'a-symbol 3)?
-----------------------
Date: Wed, 16 Dec 87 13:02:06 PST
Message-Id: <8712162102.AA07759@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: Masinter.pa, VANROGGEN@decwrl.dec.com
Subject: RE: Current practice:argument types in function declarations
That's right--your example would be in error.
...
-----------------------
Date: Wed, 16 Dec 87 13:11 est
From: mike%acorn@LIVE-OAK.LCS.MIT.EDU
To: masinter.PA
Subject: Current practice:argument types in function declarations
Cc: common-lisp@sail.stanford.edu
From: masinter.PA@Xerox.COM
Date: 16 Dec 87 1:32:02 PST
>Is anyone aware of any (released? supported?) Common Lisp implementation that
>pays any attention at all to the types of arguments, e.g., for which
> (proclaim '(function my-function (list vector) t))
>has any effect different from
> (proclaim '(function my-function (t t) t))
> ?
>Does anyone *have* any Common Lisp code which contains such declarations?
>What is the intent of the declarations, other than as documentation?
First off, either signature tells you more than nothing at all, since
it fixes the number of arguments. Presumably, you have to check
the number of arguments as well as the types for really safe calls.
As for use, we are not using them currently, but plan to use them.
The goal is to generate "safe" calls for functions when compiling if
the type signature is unknown. If the type signature is known;
however, the checking burden is placed on the caller (and can be
minimized via type inference, etc.) and an unsafe call is generated.
The type signature can be known either via block compilation, or
by using function type proclamations. In any case if you ftype a function
and a call can be shown to contradict the proclamation, then you
should get a warning and a safe (slow) call.
The one difficulty with these things is that common lisp's type
language doesn't allow you to specify accurate types for things
like <. E.G.,
(proclaim '(ftype < (function (&rest ??) (or T nil))))
For ?? you'd like to say "zero or more non-complex numbers". You do
NOT want to say LIST here.
I am considering defining a (list-of ...) type specifier.
where the argument is a type. This cannot really be written in
common lisp, since it doesn't allow parameterized types in general.
But we as implementors can put it in place as an extension.
Mike Beckerle
Gold Hill Computers.
----------------------
Date: Wed, 16 Dec 87 18:13:25 GMT
Message-Id: <561.8712161813@csuna.cvaxa.sussex.ac.uk>
To: "masinter.PA" <@NSS.Cs.Ucl.AC.UK,@cvaxa.sussex.ac.uk:masinter.PA@xerox.com>
Subject: Re: Current practice:argument types in function declarations
POPLOG Common Lisp (POPLOG is a UK AI development environment) will
recognise function declarations in the next release, but only because
it is interested in knowing how many arguments and results a function
takes (especially the number of results).
John Williams (johnw@uk.ac.sussex.cvaxa)
----------------------
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Re: Current practice:argument types in function declarations
Original-Date: Thu, 17 Dec 87 03:05 EST
Organization: University of Rochester, Department of Computer Science
Postal-address: 401A CS Building, Computer Science Department, University of
Rochester, Rochester NY 14627
Phone: 716-275-1118
Date: 16 Dec 87 1:32:02 PST
From: masinter.PA@Xerox.COM
Does anyone *have* any Common Lisp code which contains such declarations?
What
is the intent of the declarations, other than as documentation?
All the code I write has such delcarations, including for the types of all
returned values. The immediate purpose is documentation since it's ignored on
the machine I happen to work on (a symbolics) but it's my hope that in future
the compiler/interpreter would complain about calls to the function that pass
the wrong type of argument at compile time, if it can tell. (runtime would
depend on OPTIMIZE SAFETY or some such, and probably local declarations inside
the defun or whatever).
Also, it could be used as a note to the debugger, since it could flag that an
argument was of an unexpected type if some other problem arises and it gets
invoked. (this would help track down the error).
But I'm a user, not an implementor: this is just what I hope to eventually get
out of it. As I said, right now it's just documentation so the next guy knows
what I expected the function to handle when I wrote it.
Brad Miller
------
miller@cs.rochester.edu {...allegra!rochester!miller}
Brad Miller
University of Rochester Computer Science Department
----------------------
From: <samalone@ATHENA.MIT.EDU>
Subject: Re: Current practice:argument types in function declarations
Date: Fri, 18 Dec 87 09:29:12 EST
Yes, I often proclaim functions to take arguments of specific types.
Usually this happens when I want to proclaim the return value of a
function and my sense of taste insists that I proclaim the types of the
arguments as well. However, none of the implementations I've used seem
to do much with the information.
There is one time when proclaiming the types of arguments to a function is
obviously useful: when compiling the function itself. True, one could
use declarations inside of the function to achive the same result, but
using a proclamation keeps all of the function's type specification in one
place.
Without repeating them, I'd also like to voice my support of the
comments made by Mike Bekerle and Brad Miller.
--Stuart A. Malone
∂10-Jun-88 0227 CL-Cleanup-mailer [Dan L. Pierson <pierson@mist.ARPA>: Issue: LET-TOP-LEVEL (version 1)]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 02:27:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 02:26:14 PDT
Date: 10 Jun 88 02:25 PDT
From: Masinter.pa@Xerox.COM
Subject: [Dan L. Pierson <pierson@mist.ARPA>: Issue: LET-TOP-LEVEL (version 1)]
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <880610-022614-6263@Xerox>
I have 34 messages on this topic in early march, and it petered out.
This is the original proposal, to jog to your memory.
----- Begin Forwarded Messages -----
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 01 MAR 88 13:04:32 PST
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:01:05 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA11586; Tue, 1 Mar 88 16:02:47 EST
Received: from localhost by mist.UUCP (3.2/4.7)
id AA21522; Tue, 1 Mar 88 16:02:38 EST
Message-Id: <8803012102.AA21522@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax.ARPA
Subject: Issue: LET-TOP-LEVEL (version 1)
Date: Tue, 01 Mar 88 16:02:35 EST
From: Dan L. Pierson <pierson@mist.ARPA>
Issue: LET-TOP-LEVEL
References: Top-Level Forms (p. 66), DEFUN (p. 67),
DEFVAR, DEFPARAMETER, DEFCONSTANT (pp. 68-69)
Category: ADDITION
Edit history: Version 1 by Pierson 3/1/88
Status: For Internal Discussion
Problem description:
The main defining forms in CLtL do not support defining (as opposed to
creating) closures in lexical environments.
Proposal (LET-TOP-LEVEL:ALLOW-DEF):
Require implementations to support DEFUN, DEFVAR, DEFPARAMETER, and
DEFCONSTANT enclosed in a LET at top level as well as a PROGN at top
level. Do not require support for DEFMACRO (environment irrelevant)
or EVAL-WHEN. Explicitly note that a "top level" let can be included
in a top level PROGN.
Test Cases/Examples:
The following creates a simple resource allocation package for THINGs.
It needs to be COMPILE-FILEd to test it.
(LET ((THINGS '()))
(DEFUN GET-THING ()
(IF THINGS
(PROG1 (CAR THINGS)
(SETF THINGS (CDR THINGS)))
(MAKE-THING)))
(DEFUN FREE-THING (THING)
(SETF THINGS (CONS THING THINGS))))
Rationale:
Common Lisp tries to support lexical closures but this support is
really confined to anonymous lambdas within other function
definitions. This proposal attempts to move lexical closures closer
to first-class status in Common Lisp.
Current practice:
The above example works in both Ibuki Lisp and Lucid, however only
Ibuki Lisp describes (SYMBOL-FUNCTION 'GET-THING) as a closure. Both
Symbolics and TI are reported to leave GET-THING and FREE-THING as
named-lambdas instead of compiling them.
Cost to Implementors:
While there is obviously some work required, it shouldn't be too hard
since all Common Lisp compilers are required to understand functions
in lexical closures in other contexts.
Cost to Users:
None, this is an upward compatible change.
Cost of non-Adoption:
Common Lisp will continue to leave a major style of lexical closure
use unsupported. This is probably most important to people converting
from Scheme to Common Lisp.
Benefits:
Lexical closures will become more useful. The increased information
hiding available may make some programs more maintainable by reducing
the number of global variables which really should be private to a
small group of functions. It will be easier to migrate some Scheme
programming styles to Common Lisp.
Aesthetics:
The aesthetics of the language will be improved by supporting a more
uniform view and use of lexical closures.
Discussion:
It has been pointed out that much of this proposal can be accomplished
by layering macros on top of SETF of SYMBOL-FUNCTION. The problem
with the macro approach is that it doesn't support whatever additional
environmental things the implementation may decide to do with DEFUN
(e.g. make an entry in the cross reference database).
One disadvantage of this proposal is that it doesn't interact well
with Lisp-style incremental development, for example a new top-level
defun of GET-THING wouldn't work. Pierson believes that this is an
inherent consequence of heavy use of lexical closures and that the
best workaround is to use an inspector which can support incremental
development within the current lexical scope, however this is all
outside the purvue of this committee.
Maybe this should be a compiler proposal instead of a cleanup proposal.
----- End Forwarded Messages -----
∂10-Jun-88 0228 CL-Cleanup-mailer Withdrawn issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 02:28:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 02:27:35 PDT
Date: 10 Jun 88 02:27 PDT
From: Masinter.pa@Xerox.COM
Subject: Withdrawn issues
To: CL-CLEANUP@Sail.stanford.edu
Message-ID: <880610-022735-6265@Xerox>
Just to make sure, this is the list of issues that I've removed from my list of
ones we are actively considering. I think they are gone for good. If you think
differently, be prepared to volunteer to help bring them out in good form.
- GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Withdrawn for good this time
- FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just
an open file-stream. Let it take a keyword argument :ELEMENT-TYPE,
defaulting to STRING-CHAR for non-stream arguments and to the
element-type of the stream for a stream argument."
Need volunteer to write up.
I have two notes, one is "withdrawn" and the other is "may return NIL".
I think the first is correct.
- LAMBDA-LIST-DUPLICATES (Version 1, 07-Mar-88)
(allow sequential non-interative)
Leave status quo: not allowed.
- PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
Withdrawn, this time for good.
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
Withdrawn, subsumed by SETF-SUB-METHODS
- SHARPSIGN-BACKSLASH-BITS
I think I had this on a previous withdrawn list, but I hadn't moved
the issue file.
The character committee will propose removing BITS.
∂10-Jun-88 0231 CL-Cleanup-mailer [Masinter.pa: Issue: Pathname-subdirectory-list]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 02:31:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 02:30:12 PDT
Date: 10 Jun 88 02:29 PDT
From: Masinter.pa@Xerox.COM
Subject: [Masinter.pa: Issue: Pathname-subdirectory-list]
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <880610-023012-6268@Xerox>
----- Begin Forwarded Messages -----
Return-Path: <@SAIL.STANFORD.EDU:Masinter.pa@Xerox.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 15 JUL 87 13:32:06 PDT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jul 87 13:29:01 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 15 JUL 87 13:27:05 PDT
Date: 15 Jul 87 13:24 PDT
From: Masinter.pa
Subject: Issue: Pathname-subdirectory-list
To: cl-cleanup@sail.stanford.edu
cc: Ghenis.pasa
Message-ID: <870715-132705-3165@Xerox>
This arrived in my mailbox before the X3J13 meeting. While I suspect
there may be some alternative proposals, and perhaps some other
important related issues, this seems like a good way to introduce the
topic.
!
ISSUE: (PATHNAME-SUBDIRECTORY-LIST)
REFERENCES: CLtL pages 409 - 418
CATEGORY: ADDITION
EDIT HISTORY: Version 1 by Ghenis.pasa@Xerox.com, 06/18/87
PROBLEM DESCRIPTION:
It is impossible to write PORTABLE code that can produce a pathname
based on directory plus SUBDIRECTORY information. If the directory used
is not a root, then the string provided must contain OS-specific
separators. This defeats the purpose of having an abstraction like
pathname. Specifying a subdirectory RELATIVE to the current default is
possible but also inconvenient and non-portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
PROPOSAL (PATHNAME-SUBDIRECTORY-LIST:ALLOW):
Add a :SUBDIRECTORIES field to pathnames, to store a list of strings.
The string form of a pathname can be obtained by using the appropriate
OS-specific separator and end-delimiters.
Require global variables called LISP:*HOST-OS-ALIST* and
LISP:*DEFAULT-OS* to provide the information needed to assemble
namestrings correctly
TEST CASE (desired behavior):
>(defparameter LISP:*HOST-OS-ALIST*
'(("vmsvax" . "vms") ("unixvax" . "unix"))
>(defparameter LISP:*DEFAULT-OS* "msdos")
>(defvar vmspath
(make-pathname :host "vmsvax"
:directory "smith"
:sudirectories '("lisp")
:name "test"
:type "lsp"))
>(defvar localpath
(make-pathname :directory "smith"
:sudirectories '("lisp")
:name "test"
:type "lsp"))
>(namestring vmspath)
"{vmsvax}[smith.lisp]test.lsp"
>(namestring localpath)
"c:\smith\lisp\test.lsp"
RATIONALE:
Pathnames are an abstraction meant to deal with the common notions in
file systems. Subdirectories exist in most operating systems. Common
Lisp must provide a standard way of dealing with subdirectories for
pathnames to be truly useful.
CURRENT PRACTICE:
CLtL acknowledges this problem and declares it to be a system dependent
issue.
ADOPTION COST:
This should be a simple addition to implement.
BENEFITS:
Adding a :SUBDIRECTORIES field to pathnames would make the abstraction
completely system-independent. Relative pathnames could be trivially
specified by pathnames lacking a :DIRECTORY field.
CONVERSION COST: This is an upwards-compatible addition.
AESTHETICS:
Adding a :SUBDIRECTORIES field to pathnames would make the abstraction
completely system-independent.
DISCUSSION: >>Additional arguments, discussions, endorsements,
testimonials, etc. should go here.<<
----- Next Message -----
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 16 JUL 87 17:15:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 194405; Thu 16-Jul-87 20:14:29 EDT
Date: Thu, 16 Jul 87 20:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: Pathname-subdirectory-list
To: Masinter.pa, Ghenis.pasa
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870715-132705-3165@Xerox>
Message-ID: <870716201416.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 15 Jul 87 13:24 PDT
From: Masinter.pa@Xerox.COM
PROBLEM DESCRIPTION:
It is impossible to write PORTABLE code that can produce a pathname
based on directory plus SUBDIRECTORY information. If the directory used
is not a root, then the string provided must contain OS-specific
separators. This defeats the purpose of having an abstraction like
pathname. Specifying a subdirectory RELATIVE to the current default is
possible but also inconvenient and non-portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
I agree with the problem description. We've been dealing with heterogeneous
network for quite some time and have run into the same thing.
PROPOSAL (PATHNAME-SUBDIRECTORY-LIST:ALLOW):
Add a :SUBDIRECTORIES field to pathnames, to store a list of strings.
Adding a new field as a way of solving this problem doesn't make sense.
Subdirectories are a structuring of the existing directory field, they are
not a new -independent- aspect of a pathname.
The solution to this problem that Symbolics has used for years works
quite well. The directory is a structured field whose value is returned
as a list of strings, one string for each subdirectory level. In
addition to strings, in our system we allow certain keywords in the
list, enumerated below. Note that this general approach is the solution
suggested by CLtL itself, page 412 about 3/4 of the way down the page;
thus the only reason to change the language would be if we want to force
all implementations to use the same representation of structured
directories, which might be difficult if some implementation uses a
strange file system with a directory feature we haven't thought of.
When constructing a pathname, either a list of strings, or a single
string containing host-dependent delimiters, is accepted. To retrieve a
string containing host-dependent delimiters, the existing
DIRECTORY-NAMESTRING function is used.
In case those keywords aren't self-evident, here are some examples.
Vixen is a Unix, presumably everyone is familiar with Unix pathname
syntax.
(make-pathname :host "vixen"
:directory '("foo" "bar")) => #P"VIXEN:/foo/bar/"
(make-pathname :host "vixen"
:directory '(:relative "bar")) => #P"VIXEN:bar/"
(make-pathname :host "vixen"
:directory '(:relative :up "bar")) => #P"VIXEN:../bar/"
(make-pathname :host "vixen"
:directory '(:relative :up :up "bar")) => #P"VIXEN:../../bar/"
(make-pathname :host "vixen"
:directory '("foo" :wild "bar")) => #P"VIXEN:/foo/*/bar/"
I can't show you :wild-inferiors on Unix, because Unix is too simple
and elegant to have such useful features, so I'll use VMS:
(make-pathname :host "dumbo"
:directory '("foo" :wild "bar")) => #P"DUMBO:[foo.*.bar]"
(make-pathname :host "dumbo"
:directory '("foo" :wild-inferiors "bar")) => #P"DUMBO:[foo...bar]"
The name of the VMS host is not intended to be particularly pejorative, all of
our
Vaxes are named after flying critters.
----- Next Message -----
Return-Path: <@SAIL.Stanford.EDU:Masinter.pa@Xerox.COM>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 26 OCT 87 14:16:37 PST
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 14:13:22 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 14:08:46 PST
Date: 26 Oct 87 14:55 PDT
From: Masinter.pa
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST
In-reply-to: EWeaver.pa's message of Mon, 26 Oct 87 09:35 PST
To: cl-cleanup@sail.stanford.edu
cc: ibuki!dbp@labrea.stanford.edu
Message-ID: <871026-140846-2061@Xerox>
I had marked the issue PATHNAME-SUBDIRECTORY-LIST as withdrawn; I
thought Moon's point ("the only reason to change the language would be
if we want to force all implementations to use the same representation
of structured directories, which might be difficult if some
implementation uses a strange file system with a directory feature we
haven't thought of.") was compelling.
However, I think there is some advantage to encouraging some consistency
of practice for those systems which do have subdirectory structures...
I'd recommend we postpone this issue for now...
----- End Forwarded Messages -----
∂10-Jun-88 0244 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 10 Jun 88 02:43:54 PDT
Received: by labrea.stanford.edu; Fri, 10 Jun 88 02:42:48 PDT
Received: from bhopal.lucid.com by edsel id AA19194g; Fri, 10 Jun 88 02:23:15 PDT
Received: by bhopal id AA27396g; Fri, 10 Jun 88 02:21:54 PDT
Date: Fri, 10 Jun 88 02:21:54 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806100921.AA27396@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 7 Jun 88 16:58 EDT <19880607205831.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
I intend to put some more work in on this proposal later today (Friday)
which will, among other things, incorporate some of your suggestion; but
others of your comments I'm not sure what to do with.
re: To my mind the proposal never quite says explicitly what it's proposing.
It speaks in terms of modifications to the document rather than features
of the language.
Of the several parts of the proposal, two go like this:
-- Introduce a function UPGRADE-ARRAY-ELEMENT-TYPE, which will reveal how
a particular :element-type argument to make-array will be treated.
Semantically, this would be equivalent to:
(defun upgrade-array-element-type (element-type)
(array-element-type (make-array 0 :element-type element-type)))
. . .
-- Change TYPEP (and SUBTYPEP) so that `(typep x '(array ,aet)) is true
if and only if `(typep x '(array ,(upgrade-array-element-type aet)))
is true.
I think those are specific enough, as proposals. The discussion section,
which you say you didn't read, contained further ramifications; much of
that would cover what you want to add. The remaining three parts of
the proposal are indeed concerned with documentation, since I think that
is one of the fundamental problems here -- CLtL has the particular mis-
features of the "warp" built-in at numerous places, and they will have to
be removed.
re: The subtype relations among type specifiers (ARRAY type1) and
(ARRAY type2) are as follows: For all values of type1 and type2,
(ARRAY type1) and (ARRAY type2) are either equivalent or disjoint.
Yea, I *think* this is true under the unify-upgrading proposal; but isn't
it true under the status quo also? see the "warp" statement at the
bottom of CLtL p45, and the disjointness statement on p46: "Now
(array character) is not a subset of (array t); the two sets are in fact
disjoint because ..." What I thought the interesting question would be
is that found in the discussion section of the proposal, near:
Since this proposal contains the implication:
`(array ,aet-x) is-type-equivalent-to `(array ,aet-y)
==>
,aet-x is-type-equivalent-to ,aet-y
then the question naturally arises "Does the reverse implication hold?"
The answer I came up with is no. Perhaps you should go read that after all.
re: ... COMPLEX should be mentioned in the body of the
proposal as a subject for a necessary companion proposal.
Ok, why not. It seems clear to me that most implementations will have a
totally different kind of upgrading for COMPLEX's than for ARRAY's, and
that's part of the reason I don't want to mix the two together right now.
re: You need to list explicitly the type specifiers that are affected by
this proposal, so no one overlooks one.
I did, but in the problem statement part:
. . . i.e., those [type-specifiers] that are subtypes of ARRAY.
This implicitly includes SIMPLE-ARRAY and VECTOR.
What more were you thinking of? simply noting that forms like
(ARRAY <type>) and (VECTOR <type> 3) and (SIMPLE-ARRAY <type> (* * *))
are all subtypes of ARRAY?
One more question I have for you [apparently no one else is reading
these more complicated proposals?]. Do you find the notation
`(array ,aet-y) distracting? I notice that in your comments you use
(ARRAY type-y) instead. Is the form `(array ,aet-y) bad enough
to warrant complete substitution? At least one of my early readers
here at lucid didn't like it.
I think it would be real good if we could get some knowledgeable, but
"uncontaminated", reader to go over this proposal now. Or maybe Version 4.
-- JonL --
∂10-Jun-88 0827 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 3)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 10 Jun 88 08:25:09 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA04307; Fri, 10 Jun 88 11:22:35 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA08738; Fri, 10 Jun 88 11:25:58 EDT
Message-Id: <8806101525.AA08738@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: FORMAT-PRETTY-PRINT (version 3)
Date: Fri, 10 Jun 88 11:25:52 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
This version trys to specify a bit more. What directives did I leave
out?
Issue: FORMAT-PRETTY-PRINT
References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 3/4/88
Version 2 by Pierson 5/24/88 (fix name typo)
Version 3 by Pierson 6/10/88 incorporate comments
Status: For Internal Discussion
Problem description:
The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively. The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.
Proposal (FORMAT-PRETTY-PRINT:YES):
Add a header "Printer Control Variables" before the description of
*PRINT-ESCAPE* on page 370.
Add the following paragraph to page 386 just before the paragraph
starting with "It is an error":
"The FORMAT function by itself binds *PRINT-ESCAPE* to NIL and
binds no other of the printer control variables. Specific FORMAT
directives bind exactly the printer control variables specified in
their description. While implementations may specify the binding
of new, implementation specific printer control variables for each
FORMAT directive, they may neither bind any standard printer
control variables not specified in description of a FORMAT
directive nor fail to bind any standard printer control variables
as specified in the description."
Add the following to the descriptions of the following FORMAT
directives:
~A
Binds *PRINT-ESCAPE* to NIL.
~S
Binds *PRINT-ESCAPE* to T.
~D
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 10.
~B
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 2.
~O
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 8.
~X
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 16.
~R
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to the value of the first argument iff a first
argument is specified.
~@C
Binds *PRINT-ESCAPE* to T.
~F,~G,~E,~$
Binds *PRINT-ESCAPE* to NIL.
Test Cases/Examples:
(LET ((TEST '#'(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL (EVAL TEST) TEST))
This should print four copies of the above lambda expression. The
first pair should appear identical and the second pair should appear
identical. The only difference between the two pairs should be the
absence of string quotes in the second pair.
Rationale:
FORMAT should interact with the printer control variables in a
predictable way. This proposal is one of the two simplest possible
definitions and provides the most flexibility to the user.
A major advantage of this proposal is that the following two
expressions are guaranteed to have exactly the same effect:
(FORMAT stream "~S" object)
(PRIN1 object stream)
Thus use or non-use of FORMAT becomes a purely stylistic matter.
Current practice:
Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.
Cost to Implementors:
While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications. How does a pretty-printing ~A
interact with MINCOL, etc? How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?
Cost to Users:
Truely portable code shouldn't be affected because existing
implementations are inconsistent. Despite this, there are probably a
number of user programs in non-complying which will have to change
whichever way this is decided.
Cost of non-Adoption:
The interaction of FORMAT and the printer controlvariables (especially
*PRINT-PRETTY*) will remain undefined. This will continue to make
portable Common Lisp programming harder than it need be.
Benefits:
Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.
Aesthetics:
The interaction between two related parts of output will be clarified
in a simple way.
Discussion:
Pierson feels that this is important because the ease of implementing
major system interfaces with FORMAT can unintentionally lead to less
flexibility for the user compared to an old-style PRIN1/PRINC/TERPRI
implementation. This clarification would generate some up front work
but would make it harder for people to accidentally create restrictive
interfaces.
After discussion in the cleanup committee, this proposal has been
recast to explictly specify more of the behavior of FORMAT.
∂10-Jun-88 0845 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 4)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 10 Jun 88 08:44:56 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA04427; Fri, 10 Jun 88 11:42:27 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA08790; Fri, 10 Jun 88 11:45:52 EDT
Message-Id: <8806101545.AA08790@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 4)
Date: Fri, 10 Jun 88 11:45:50 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Walter asked for this correction and I can't remember whether this was
formally passed last meeting or not. If it was, then I'd prefer not
to disturb it.
Issue: DISASSEMBLE-SIDE-EFFECT
References: DISASSEMBLE (p. 439), COMPILE (p. 439)
Category: CLARIFICATION
Edit history: Version 2 by Pierson 12/30/87
Version 3 by Pierson 1/21/88
Version 4 by Pierson 6/10/88 correct VAX Lisp practice
Status: Ready For Release?
Problem description:
The definition of DISASSEMBLE says that "if the relevant function is
not a compiled function, it is first compiled.". The definition of
COMPILE says that "If name is a non-nil symbol, then the
compiled-function is installed as the global function definition of
the symbol...". Several implementations have taken this to mean that
if DISASSEMBLE is passed a symbol which has an uncompiled function
definition, then it has the side-effect of (COMPILE 'symbol).
Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL):
Clarify that when DISASSEMBLE compiles a function, it will never
install the newly compiled function.
Test Cases/Examples:
(DEFUN F (A) (1+ A))
(EQ (SYMBOL-FUNCTION 'F)
(PROGN (DISASSEMBLE 'F)
(SYMBOL-FUNCTION 'F)))
This code will return T if this proposal is adopted. Some current
implementations will return T, some will return NIL.
Rationale:
Several current implementations of DISASSEMBLE have surprising side
effects, especially for new users.
Current practice:
Allegro CL installs the compiled definition. Lucid, Symbolics, Xerox,
VAX Lisp, and KCL don't install it.
Cost to Implementors:
Some implementations will have to make a simple change.
Cost to Users:
Very little. DISASSEMBLE is really part of the environment and is
probably not called by much, if any user code.
Cost of non-Adoption:
DISASSEMBLE will continue to surprise less experienced users.
Benefits:
DISASSEMBLE will become the predictable debugging function it was
meant to be.
Aesthetics:
Some who worried that DISASSEMBLE was supposed to install the compiled
function may find that the language has become a little cleaner.
Discussion:
DISASSEMBLE is an environment feature; some question has been raised
as to the place and force of environment features in the standard.
However, this proposal stands if DISASSEMBLE is part of the standard
language.
∂10-Jun-88 0904 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 10 Jun 88 09:03:59 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA04670; Fri, 10 Jun 88 12:01:32 EDT
Message-Id: <8806101601.AA04670@multimax.ARPA>
To: cl-cleanup@sail.stanford.edu, a37078%tansei.cc.u-tokyo.junet@relay.cs.net
Subject: Re: Issue: COERCE-INCOMPLETE
Date: Fri, 10 Jun 88 12:01:31 EDT
From: Dan L. Pierson <pierson@multimax.ARPA>
While I support the idea of filling out a more complete coercion matrix for
Common Lisp, I find some of the specifics of this proposal counter-intuitive
and unpleasant. For example, I would like the following to return 5:
(COERCE "5" 'INTEGER)
I would also like the following to work and return 456:
(COERCE "456" 'INTEGER)
This proposal would require the first expression to return 53 (for ascii
implementations) and force the second expression to signal an error (I
think).
∂10-Jun-88 1006 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 3)
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 10 Jun 88 10:05:20 PDT
Date: 10 Jun 88 12:46:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Issue: FORMAT-PRETTY-PRINT (version 3)
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
I think it's confusing to say that FORMAT always binds *PRINT-ESCAPE* to
NIL and also either binds it to T or NIL as required by various directives.
Furthermore, this would seem to disallow directives which don't bind any
of those *PRINT-xxx* variables. VAX LISP has a ~W directive which prints
using the current *PRINT-xxx* bindings.
---Walter
------
∂10-Jun-88 1041 CL-Cleanup-mailer Re: Issue: FORMAT-PRETTY-PRINT (version 3)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 10 Jun 88 10:41:28 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA06417; Fri, 10 Jun 88 13:38:57 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA08969; Fri, 10 Jun 88 13:42:22 EDT
Message-Id: <8806101742.AA08969@mist.UUCP>
To: "cl-cleanup" <cl-cleanup%sail.stanford.edu@Multimax>,
vanroggen%SAIL.Stanford.EDU@multimax
Subject: Re: Issue: FORMAT-PRETTY-PRINT (version 3)
In-Reply-To: Your message of 10 Jun 88 12:46:00 -0400.
<8806101713.AA05859@multimax.ARPA>
Date: Fri, 10 Jun 88 13:42:20 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I think it's confusing to say that FORMAT always binds *PRINT-ESCAPE* to
NIL and also either binds it to T or NIL as required by various directives.
That was a kludge to make it clear that non of the text in format
statements is ever escaped. It is probably unnecessary and a mistake.
Furthermore, this would seem to disallow directives which don't bind any
of those *PRINT-xxx* variables. VAX LISP has a ~W directive which prints
using the current *PRINT-xxx* bindings.
Good point. A new draft will appear shortly.
∂10-Jun-88 1045 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 4)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 10 Jun 88 10:44:59 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA06642; Fri, 10 Jun 88 13:42:29 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA09004; Fri, 10 Jun 88 13:45:54 EDT
Message-Id: <8806101745.AA09004@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: FORMAT-PRETTY-PRINT (version 4)
Date: Fri, 10 Jun 88 13:45:52 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Walter pointed out that version 3 was broken, so...
Issue: FORMAT-PRETTY-PRINT
References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 3/4/88
Version 2 by Pierson 5/24/88 (fix name typo)
Version 3 by Pierson 6/10/88 incorporate comments
Version 4 by Pierson 6/10/88 comments from Van Roggen
Status: For Internal Discussion
Problem description:
The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively. The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.
Proposal (FORMAT-PRETTY-PRINT:YES):
Add a header "Printer Control Variables" before the description of
*PRINT-ESCAPE* on page 370.
Add the following paragraph to page 386 just before the paragraph
starting with "It is an error":
"The FORMAT function by itself never binds any of the printer
control variables. Specific FORMAT directives bind exactly the
printer control variables specified in their description. While
implementations may specify the binding of new, implementation
specific printer control variables for each FORMAT directive, they
may neither bind any standard printer control variables not
specified in description of a FORMAT directive nor fail to bind
any standard printer control variables as specified in the
description."
Add the following to the descriptions of the following FORMAT
directives:
~A
Binds *PRINT-ESCAPE* to NIL.
~S
Binds *PRINT-ESCAPE* to T.
~D
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 10.
~B
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 2.
~O
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 8.
~X
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 16.
~R
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to the value of the first argument iff a first
argument is specified.
~@C
Binds *PRINT-ESCAPE* to T.
~F,~G,~E,~$
Binds *PRINT-ESCAPE* to NIL.
Test Cases/Examples:
(LET ((TEST '#'(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL (EVAL TEST) TEST))
This should print four copies of the above lambda expression. The
first pair should appear identical and the second pair should appear
identical. The only difference between the two pairs should be the
absence of string quotes in the second pair.
Rationale:
FORMAT should interact with the printer control variables in a
predictable way. This proposal is one of the two simplest possible
definitions and provides the most flexibility to the user.
A major advantage of this proposal is that the following two
expressions are guaranteed to have exactly the same effect:
(FORMAT stream "~S" object)
(PRIN1 object stream)
Thus use or non-use of FORMAT becomes a purely stylistic matter.
Current practice:
Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.
Cost to Implementors:
While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications. How does a pretty-printing ~A
interact with MINCOL, etc? How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?
Cost to Users:
Truely portable code shouldn't be affected because existing
implementations are inconsistent. Despite this, there are probably a
number of user programs in non-complying which will have to change
whichever way this is decided.
Cost of non-Adoption:
The interaction of FORMAT and the printer controlvariables (especially
*PRINT-PRETTY*) will remain undefined. This will continue to make
portable Common Lisp programming harder than it need be.
Benefits:
Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.
Aesthetics:
The interaction between two related parts of output will be clarified
in a simple way.
Discussion:
Pierson feels that this is important because the ease of implementing
major system interfaces with FORMAT can unintentionally lead to less
flexibility for the user compared to an old-style PRIN1/PRINC/TERPRI
implementation. This clarification would generate some up front work
but would make it harder for people to accidentally create restrictive
interfaces.
After discussion in the cleanup committee, this proposal has been
recast to explictly specify more of the behavior of FORMAT.
∂10-Jun-88 1513 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 4)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 10 Jun 88 15:13:08 PDT
Received: by labrea.stanford.edu; Fri, 10 Jun 88 15:12:05 PDT
Received: from bhopal.lucid.com by edsel id AA21973g; Fri, 10 Jun 88 15:08:21 PDT
Received: by bhopal id AA01830g; Fri, 10 Jun 88 15:07:04 PDT
Date: Fri, 10 Jun 88 15:07:04 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806102207.AA01830@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 7 Jun 88 17:28 EDT <19880607212838.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: SETF-SUB-METHODS (Version 4)
re: An earlier version of the proposal had Current Practice information
for Xerox, Franz, HP, and DEC. Where did it go?
By modifying the part about (setf (getf ...) ...), the semantics were changed
enough that I couldn't be sure what to say about these implementations. I
think the before-modification proposal was trying to defend the status quo;
its likely that almost nobody fits the current description exactly now.
-- JonL --
∂10-Jun-88 2016 CL-Cleanup-mailer [Dan L. Pierson <pierson@mist.ARPA>: Issue: LET-TOP-LEVEL (version 1)]
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 10 Jun 88 20:16:48 PDT
Received: by labrea.stanford.edu; Fri, 10 Jun 88 20:15:15 PDT
Received: from bhopal.lucid.com by edsel id AA23206g; Fri, 10 Jun 88 20:04:18 PDT
Received: by bhopal id AA03653g; Fri, 10 Jun 88 20:03:01 PDT
Date: Fri, 10 Jun 88 20:03:01 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806110303.AA03653@bhopal.lucid.com>
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: Masinter.pa@Xerox.COM's message of 10 Jun 88 02:25 PDT <880610-022614-6263@Xerox>
Subject: [Dan L. Pierson <pierson@mist.ARPA>: Issue: LET-TOP-LEVEL (version 1)]
My impression of the petering-out discussion was that this was still
a moot issue. The cl-compiler committee is handling three much more
concrete related issues:
(1) COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS [ah, the infamous top-level!]
(2) EVAL-WHEN-NON-TOP-LEVEL [or, simply put semantics of EVAL-WHEN]
(3) DEFINING-MACROS-NON-TOP-LEVEL [like, for example DEFUN inside a LET]
I believe these issues will adequately address the real concerns brought
up by Dan.
-- JonL --
∂12-Jun-88 2142 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 12 Jun 88 21:42:38 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa01299; 13 Jun 88 0:36 EDT
Received: from utokyo-relay by RELAY.CS.NET id ae19675; 13 Jun 88 0:28 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA11864; Mon, 13 Jun 88 11:18:21 JST
Received: by aoyama.cc.aoyama.junet (3.2/6.3Junet-1.0)
id AA26328; Mon, 13 Jun 88 11:07:16 JST
Date: Mon, 13 Jun 88 11:07:16 JST
From: Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@aoyama.cc.aoyama.junet>
Message-Id: <8806130207.AA26328@aoyama.cc.aoyama.junet>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: COERCE-INCOMPLETE
Since I was not involved in the cl-cleanup list,
I have no information on the process of COERCE-INCOMPLETE issue which
seems to be discussed.
I guess it must be the issue I raised and I sent to Larry Masinter
according to his request.
I still have a interest on this issue but
I myself understand the situation as it is the issue I gave to cl-clearup
subcommittee.
So, I have no will to discuss on the matter unless the subcommittee
forward the mails of their discussions.
I have a desire to receive the mailing-list,
but as some of you may know,
All the traffic between US and I are paid by myself.
So, I am afraid that I will short of money for this year's research with
the expenses of un-needed mails.
So, I hope a kind of moderated communication about the cleanup things.
Hoping your kind treatment.
Masayuki Ida
∂13-Jun-88 0732 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 4)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 13 Jun 88 07:31:58 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA01253; Mon, 13 Jun 88 10:28:31 EDT
Message-Id: <8806131428.AA01253@multimax.ARPA>
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02921; 13 Jun 88 13:03 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa21233;
13 Jun 88 13:08 BST
To: pierson <@multimax.arpa:pierson@mist>
Cc: cl-cleanup <@multimax.arpa:cl-cleanup@sail.stanford.edu>
In-Reply-To: "Dan L. Pierson"'s message of Fri, 10 Jun 88 11:45:50 EDT <8806101545.AA08790@mist.UUCP>
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 4)
Date: Mon, 13 Jun 88 13:07:55 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
I would find the world much tidier if disassembly were only permitted
on compiled objects, and if the function was not already compiled,
then it is an error. This is of course easier if the language
supports compiled functions as a data type......
==John
∂17-Jun-88 1754 CL-Cleanup-mailer Issue: STREAM-ACCESS (version 1)
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 17 Jun 88 17:53:54 PDT
Date: 17 Jun 88 20:34:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Issue: STREAM-ACCESS (version 1)
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Issue: STREAM-ACCESS
References: streams (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 17-Jun-88, version 1 by Walter van Roggen
Problem Description:
There are many components of streams which are specified upon creation
but are not accessible afterwards. Furthermore there is no way in
Common Lisp to determine the type of a stream to see if it has particular
components, or even if it is OPEN.
Proposal: (STREAM-ACCESS:PROVIDE)
Add the following types and functions to the language:
Stream Data Types and Predicates:
BROADCAST-STREAM [Type]
BROADCAST-STREAM-P object [Function]
The predicate is true if the object is of type BROADCAST-STREAM
and is false otherwise. MAKE-BROADCAST-STREAM returns a stream
of type BROADCAST-STREAM.
CONCATENATED-STREAM [Type]
CONCATENATED-STREAM-P object [Function]
The predicate is true if the object is of type CONCATENATED-STREAM
and is false otherwise. MAKE-CONCATENATED-STREAM returns a stream
of type CONCATENATED-STREAM.
ECHO-STREAM [Type]
ECHO-STREAM-P object [Function]
The predicate is true if the object is of type ECHO-STREAM
and is false otherwise. MAKE-ECHO-STREAM returns a stream
of type ECHO-STREAM.
FILE-STREAM [Type]
FILE-STREAM-P object [Function]
The predicate is true if the object is of type FILE-STREAM
and is false otherwise. OPEN returns a stream
of type FILE-STREAM.
STRING-STREAM [Type]
STRING-STREAM-P object [Function]
The predicate is true if the object is of type STRING-STREAM
and is false otherwise. MAKE-STRING-INPUT-STREAM and
MAKE-STRING-OUTPUT-STREAM return a stream of type STRING-STREAM.
SYNONYM-STREAM [Type]
SYNONYM-STREAM-P object [Function]
The predicate is true if the object is of type SYNONYM-STREAM
and is false otherwise. MAKE-SYNONYM-STREAM returns a stream
of type SYNONYM-STREAM.
TWO-WAY-STREAM [Type]
TWO-WAY-STREAM-P object [Function]
The predicate is true if the object is of type TWO-WAY-STREAM
and is false otherwise. MAKE-TWO-WAY-STREAM returns a stream
of type TWO-WAY-STREAM.
Stream Informational Functions:
BROADCAST-STREAM-STREAMS broadcast-stream ==> list of streams
This function returns a list of output streams that constitute
all the streams the broadcast stream is broadcasting to. It is
an error if the argument is not of type BROADCAST-STREAM.
CONCATENATED-STREAM-STREAMS concatenated-stream ==> list of streams
This function returns a list of input streams that constitute
the ordered set of streams the concatenated stream still has to
to read from, starting with the current one it is reading from.
The list may be () if no more streams remain to be read.
It is an error if the argument is not of type CONCATENATED-STREAM.
ECHO-STREAM-INPUT-STREAM echo-stream ==> input-stream
ECHO-STREAM-OUTPUT-STREAM echo-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type ECHO-STREAM.
SYNONYM-STREAM-SYMBOL synonym-stream ==> symbol
This function returns the symbol whose SYMBOL-VALUE the
synonym stream is using. It is
an error if the argument is not of type SYNONYM-STREAM.
TWO-WAY-STREAM-INPUT-STREAM two-way-stream ==> input-stream
TWO-WAY-STREAM-OUTPUT-STREAM two-way-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type TWO-WAY-STREAM.
Predicate:
OPEN-STREAM-P stream
Returns T if a stream is open, NIL if it is closed. It is an error
if the argument is not a stream.
Current Practice:
VAX LISP implements the proposal.
Cost to Implementors:
Most of these should be trivial to implement, since the information
must be present for nearly all types.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
Discussion:
This issue has come up frequently, particularly dealing with SYNONYM-STREAMs.
------