I noticed a mistake in one of the examples in the hyperspec, and went looking for an errata. I saw this page on cliki but didn't find the issue there, so I am wondering if the "comprehensive" list is elsewhere:
http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
FWIW, the issue is in the second example under the documentation for SHADOW[1].
(package-shadowing-symbols (make-package 'temp)) => NIL (find-symbol 'car 'temp) => CAR, :INHERITED
FIND-SYMBOL does not accept a symbol as the first argument. All the Lisps that I have checked this on signal an error.
Also, I think the first example should be modified to:
(package-shadowing-symbols (make-package 'temp :use '("CL")))
SBCL by default does not use the CL package. So (find-symbol "CAR" 'temp) returns NIL, NIL instead. It took me a while to figure why the spec example returned a different set of values.
Chaitanya
1. http://www.lispworks.com/documentation/HyperSpec/Body/f_shadow.htm
The Hyperspec is a copyrighted document owned by Lispworks. They can change it, and *perhaps *others could create a revised version under the generous terms of use.
But the Hyperspec is mostly a version of the official ANSI specification for CL, and revising *that *is something much more difficult. (I won't here go into the story how X3J13 manipulated the final draft of the ANS into a freely-available document prior to ANSI slapping their restrictive copyright on it, but that's what the Hyperspec and other similar freely-available versions of the CL specification are derived from.)
The erroneous example you found is real and it would certainly be nice to fix it, but note *1.4.3 Sections Not Formally Part Of This Standard. *Sections labeled *Examples *or *Notes *are not normative -- i.e., they are illustrative only and not a binding part of the language definition.
On 14 December 2017 at 14:59, Steve Haflich shaflich@gmail.com wrote:
The Hyperspec is a copyrighted document owned by Lispworks. They can change it, and perhaps others could create a revised version under the generous terms of use.
But the Hyperspec is mostly a version of the official ANSI specification for CL, and revising that is something much more difficult. (I won't here go into the story how X3J13 manipulated the final draft of the ANS into a freely-available document prior to ANSI slapping their restrictive copyright on it, but that's what the Hyperspec and other similar freely-available versions of the CL specification are derived from.)
You are right, which is why I was wondering if there's one place one could definitively consult for errata in the standard or examples.
The cliki list, even though it didn't have this issue, seems exhaustive though the page is poorly maintained.
Is there any other place where someone is maintaining the errata?
The erroneous example you found is real and it would certainly be nice to fix it, but note 1.4.3 Sections Not Formally Part Of This Standard. Sections labeled Examples or Notes are not normative -- i.e., they are illustrative only and not a binding part of the language definition.
I didn't know that. Thanks!
Chaitanya
When I reported an error I’d noticed in the HyperSpec to Lispworks three years ago their response pointed me at the CLiki page, so I suspect that is probably the best source of errata available. And, more importantly, that response seems to imply they have no interest in updating the HyperSpec. That said, I remain grateful to them that it is available, even in its ossified form.
Just keep in mind that some of the items on the CLiki list propose changes (divergences from) current normative ANSI CL requirements, and that others are simply drafted sloppily. These changes would not have automatically passed review under the original X3J13 process, and no one should assume their long life on the CLiki page means they would be uncontroversial.
On Thu, Dec 14, 2017 at 4:04 AM, Don Morrison dfm2@cmu.edu wrote:
When I reported an error I’d noticed in the HyperSpec to Lispworks three years ago their response pointed me at the CLiki page, so I suspect that is probably the best source of errata available. And, more importantly, that response seems to imply they have no interest in updating the HyperSpec. That said, I remain grateful to them that it is available, even in its ossified form.
-- Don Morrison dfm2@cmu.edu “We are not an endangered species ourselves yet, but this is not for lack of trying.” — Douglas Adams, /Last Chance to See/
On 14 December 2017 at 23:27, Steve Haflich shaflich@gmail.com wrote:
Just keep in mind that some of the items on the CLiki list propose changes (divergences from) current normative ANSI CL requirements, and that others are simply drafted sloppily. These changes would not have automatically passed review under the original X3J13 process, and no one should assume their long life on the CLiki page means they would be uncontroversial.
Yes, and the actual errata was listed at the bottom of that page.
I took all of them and set up a new page, organized by chapter and with proper links:
http://www.cliki.net/CLHS%20Errata
If the community feels this is fine, I will remove the errata section from the earlier page and link to this one instead.
Chaitanya
On Thu, Dec 14, 2017 at 4:04 AM, Don Morrison dfm2@cmu.edu wrote:
When I reported an error I’d noticed in the HyperSpec to Lispworks three years ago their response pointed me at the CLiki page, so I suspect that is probably the best source of errata available. And, more importantly, that response seems to imply they have no interest in updating the HyperSpec. That said, I remain grateful to them that it is available, even in its ossified form.
-- Don Morrison dfm2@cmu.edu “We are not an endangered species ourselves yet, but this is not for lack of trying.” — Douglas Adams, /Last Chance to See/
In addition to http://www.cliki.net/CLHS%20Errata Don't forget this page: http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Richman's Law: No matter how much the government controls the economic system, any problem will be blamed on whatever small zone of freedom that remains. — Sheldon Richman
On Thu, Dec 14, 2017 at 1:24 PM, Chaitanya Gupta mail@chaitanyagupta.com wrote:
On 14 December 2017 at 23:27, Steve Haflich shaflich@gmail.com wrote:
Just keep in mind that some of the items on the CLiki list propose changes (divergences from) current normative ANSI CL requirements, and that others are simply drafted sloppily. These changes would not have automatically passed review under the original X3J13 process, and no one should assume their long life on the CLiki page means they would be uncontroversial.
Yes, and the actual errata was listed at the bottom of that page.
I took all of them and set up a new page, organized by chapter and with proper links:
http://www.cliki.net/CLHS%20Errata
If the community feels this is fine, I will remove the errata section from the earlier page and link to this one instead.
Chaitanya
On Thu, Dec 14, 2017 at 4:04 AM, Don Morrison dfm2@cmu.edu wrote:
When I reported an error I’d noticed in the HyperSpec to Lispworks three years ago their response pointed me at the CLiki page, so I suspect that is probably the best source of errata available. And, more importantly, that response seems to imply they have no interest in updating the HyperSpec. That said, I remain grateful to them that it is available, even in its ossified form.
-- Don Morrison dfm2@cmu.edu “We are not an endangered species ourselves yet, but this is not for lack of trying.” — Douglas Adams, /Last Chance to See/
On 15 December 2017 at 01:26, Faré fahree@gmail.com wrote:
In addition to http://www.cliki.net/CLHS%20Errata Don't forget this page: http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
Actually, I created "CLHS Errata" today by copying the contents of the section "Minor corrections to CLHS (errata)" in "Proposed ANSI Revisions and Clarifications" and re-organizing them a bit.
I now see that the section "Clarifications to the current standard" under the latter page also contains some actual erratum, for example,
Issue ERROR-EXAMPLE: Correct the invalid IF form in the (informational) wargames:no-win-scenario example for ERROR.
I can move all errata under this section too to the "CLHS Errata" page and let only proposals/clarifications remain on the other one, if people think it makes sense.
Chaitanya
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Richman's Law: No matter how much the government controls the economic system, any problem will be blamed on whatever small zone of freedom that remains. — Sheldon Richman
On Thu, Dec 14, 2017 at 1:24 PM, Chaitanya Gupta mail@chaitanyagupta.com wrote:
On 14 December 2017 at 23:27, Steve Haflich shaflich@gmail.com wrote:
Just keep in mind that some of the items on the CLiki list propose changes (divergences from) current normative ANSI CL requirements, and that others are simply drafted sloppily. These changes would not have automatically passed review under the original X3J13 process, and no one should assume their long life on the CLiki page means they would be uncontroversial.
Yes, and the actual errata was listed at the bottom of that page.
I took all of them and set up a new page, organized by chapter and with proper links:
http://www.cliki.net/CLHS%20Errata
If the community feels this is fine, I will remove the errata section from the earlier page and link to this one instead.
Chaitanya
On Thu, Dec 14, 2017 at 4:04 AM, Don Morrison dfm2@cmu.edu wrote:
When I reported an error I’d noticed in the HyperSpec to Lispworks three years ago their response pointed me at the CLiki page, so I suspect that is probably the best source of errata available. And, more importantly, that response seems to imply they have no interest in updating the HyperSpec. That said, I remain grateful to them that it is available, even in its ossified form.
-- Don Morrison dfm2@cmu.edu “We are not an endangered species ourselves yet, but this is not for lack of trying.” — Douglas Adams, /Last Chance to See/
http://www.cliki.net/CLHS%20Errata Don't forget this page: http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
Actually, I created "CLHS Errata" today by copying the contents of the section "Minor corrections to CLHS (errata)" in "Proposed ANSI Revisions and Clarifications" and re-organizing them a bit.
I now see that the section "Clarifications to the current standard" under the latter page also contains some actual erratum, for example,
Issue ERROR-EXAMPLE: Correct the invalid IF form in the (informational) wargames:no-win-scenario example for ERROR.
I can move all errata under this section too to the "CLHS Errata" page and let only proposals/clarifications remain on the other one, if people think it makes sense.
Please make each page reference the other.
Some items (e.g. the NCONC issue I reported) have both errata (use the correct fold) and requests for change.
There are also cans of worms not on that page that a specification successor would have to face: * the horrible unportable mess that are pathnames. * maybe reserving some module names for defsystem, as in (require "asdf")? Make it case-normalizing? * standardizing, at least as options, things like threads? continuations? * dealing with obscure corners of the MOP. * the interaction between backquote and #n(), as in `#5(a ,@'(b c))
In a lot of cases, being able to delegate parts of the standard to other standard/committee/document would be important: pathnames would be defined in terms of the underlying OS so that at least all implementations on a given platform may agree. The meaning of ASDF or other newly "standard" modules would be delegated to their respective authors. Threads, continuations, source-locations, debugger interfacers or other low-level extensions would be delegated to their respective groups, etc.
Note that standardization is not necessary for things that can be built *on top* of CL as libraries, only for things that need to be provided as basic interfaces not locally expressible in terms of previous code (sure, through global transformation of a CL-in-CL compiler, you can do everything). That's already a lot. And probably won't be done - there are no strong stable forces driving it.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Taxonomy is the death of science — A. N. Whitehead
The item discussed in https://groups.google.com/forum/#!searchin/comp.lang.lisp/pierpaolo$20bernar... needs a clarification, and I don't see it listed in the wiki page. Can somebody add it, or should I do it myself? I lost track of what wiki page is the currently cared for one.
TL;DR:
(format nil "~@D" 0) ==> ? (currently unclear)
KMP wrote in that thread: "I would argue for clarifying this as "+0" in a future standard.". Everybody else seemed to substantially agree.
Another item that needs a clarification and I don't see it listed in the page is the one discussed in https://trac.clozure.com/ccl/ticket/1389 and https://trac.clozure.com/ccl/ticket/1082
Spec is not explicit, and currently different implementations do different things.
TL; DR:
(let ((*print-circle* t) (name "q")) (format nil "~A ~A" name name)) ==> ?
On 15 December 2017 at 07:19, Pierpaolo Bernardi olopierpa@gmail.com wrote:
Another item that needs a clarification and I don't see it listed in the page is the one discussed in https://trac.clozure.com/ccl/ticket/1389 and https://trac.clozure.com/ccl/ticket/1082
I've added both of these issues to the new page I am working on: http://www.cliki.net/ANSI%20Clarifications%20and%20Errata
Chaitanya
Spec is not explicit, and currently different implementations do different things.
TL; DR:
(let ((*print-circle* t) (name "q")) (format nil "~A ~A" name name)) ==> ?
I've added both of these issues to the new page I am working on: http://www.cliki.net/ANSI%20Clarifications%20and%20Errata
The last thing we need is two divergent pages on the same topic.
Can you add mutual links and delete migrated issues from the old page, then?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Wealth, like happiness, is never attained when sought after directly. It comes as a by-product of providing a useful service. — Henry Ford
On 17 December 2017 at 02:25, Faré fahree@gmail.com wrote:
I've added both of these issues to the new page I am working on: http://www.cliki.net/ANSI%20Clarifications%20and%20Errata
The last thing we need is two divergent pages on the same topic.
Can you add mutual links and delete migrated issues from the old page, then?
Yes, I plan to do that as soon as I am done organizing all the issues.
Chaitanya
I have moved all errata and clarifications to http://www.cliki.net/ANSI%20Clarifications%20and%20Errata. These are organized by chapter so browsing them should be a bit easier. I tried to restrict all items under this page to "errors, inconsistencies and ambiguities" in the standard.
All other changes suggested to the standard are at http://www.cliki.net/Proposed%20ANSI%20Changes
FWIW I left this page unchanged: http://www.cliki.net/Proposed%20Extensions%20To%20ANSI
The original page now only links to the ones above: http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
I hope people find these changes useful.
Chaitanya
On 17 December 2017 at 02:35, Chaitanya Gupta mail@chaitanyagupta.com wrote:
On 17 December 2017 at 02:25, Faré fahree@gmail.com wrote:
I've added both of these issues to the new page I am working on: http://www.cliki.net/ANSI%20Clarifications%20and%20Errata
The last thing we need is two divergent pages on the same topic.
Can you add mutual links and delete migrated issues from the old page,
then?
Yes, I plan to do that as soon as I am done organizing all the issues.
Chaitanya
-- https://chaitanyagupta.com https://lisper.in https://twitter.com/chaitanya_gupta
On Wed, Dec 20, 2017 at 5:17 PM, Chaitanya Gupta mail@chaitanyagupta.com wrote:
I have moved all errata and clarifications to http://www.cliki.net/ANSI%20Clarifications%20and%20Errata. These are organized by chapter so browsing them should be a bit easier. I tried to restrict all items under this page to "errors, inconsistencies and ambiguities" in the standard.
I’m sorry, I’m a little confused. This thread, I think, started out with errors in the HyperSpec, but this says ANSI so I’m guessing these are actually errors in that document? Is the belief that there are no differences between the HyperSpec and the ANSI spec, or at least that none of these errors are not present in both?
On 21 December 2017 at 04:03, Don Morrison dfm2@cmu.edu wrote:
On Wed, Dec 20, 2017 at 5:17 PM, Chaitanya Gupta mail@chaitanyagupta.com wrote:
I have moved all errata and clarifications to http://www.cliki.net/ANSI%20Clarifications%20and%20Errata. These are organized by chapter so browsing them should be a bit easier. I tried to restrict all items under this page to "errors, inconsistencies and ambiguities" in the standard.
I’m sorry, I’m a little confused. This thread, I think, started out with errors in the HyperSpec, but this says ANSI so I’m guessing these are actually errors in that document? Is the belief that there are no differences between the HyperSpec and the ANSI spec, or at least that none of these errors are not present in both?
Yes, that is what I believe. Authorship info in the hyperspec seems to imply that, but it is not explicit:
http://www.lispworks.com/documentation/HyperSpec/Front/Help.htm#Authorship http://www.lispworks.com/documentation/HyperSpec/Front/Help.htm#Caveats
The earlier page also used the term "ANSI" and not HyperSpec.
http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
Chaitanya
-- Don Morrison dfm2@cmu.edu “Lisa had never intended to be a telephone salesperson. What she really wanted to be was an internationally glamorous jet-setter, but she didn’t have the O-levels.” — Neil Gaiman and Terry Pratchett, /Good Omens/
On Wed, Dec 20, 2017 at 11:33 PM, Don Morrison dfm2@cmu.edu wrote:
On Wed, Dec 20, 2017 at 5:17 PM, Chaitanya Gupta mail@chaitanyagupta.com wrote:
I’m sorry, I’m a little confused. This thread, I think, started out with errors in the HyperSpec, but this says ANSI so I’m guessing these are actually errors in that document? Is the belief that there are no differences between the HyperSpec and the ANSI spec, or at least that none of these errors are not present in both?
We believe that there are no SUBSTANTIAL differences between the Hyperspec and the ANSI standard.
That is, no differences other than typographical style, copyright notices, and other ANSI and Lispworks, respectively, boilerplate.
On Wed, 20 Dec 2017 23:54:17 +0100, Pierpaolo Bernardi said:
On Wed, Dec 20, 2017 at 11:33 PM, Don Morrison dfm2@cmu.edu wrote:
On Wed, Dec 20, 2017 at 5:17 PM, Chaitanya Gupta mail@chaitanyagupta.com wrote:
I’m sorry, I’m a little confused. This thread, I think, started out with errors in the HyperSpec, but this says ANSI so I’m guessing these are actually errors in that document? Is the belief that there are no differences between the HyperSpec and the ANSI spec, or at least that none of these errors are not present in both?
We believe that there are no SUBSTANTIAL differences between the Hyperspec and the ANSI standard.
That is, no differences other than typographical style, copyright notices, and other ANSI and Lispworks, respectively, boilerplate.
Yes, that is correct.
On Thu, Dec 14, 2017 at 5:49 PM, Pierpaolo Bernardi olopierpa@gmail.com wrote:
Spec is not explicit, and currently different implementations do different things.
(let ((*print-circle* t) (name "q")) (format nil "~A ~A" name name)) ==> ?
It may be true that implementations do different things, but IMO the standard permits only one result. #n= notion aught not be produced. See the first paragraph of the dictionary page for *print-circle*:
Controls the attempt to detect circularity and sharing in an *object* http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_o.htm#object being printed.
FORMAT is not a function that prints an *object*. Instead, it interprets a format control. A call to FORMAT may print zero objects or any number of objects.
The functions that are specified to print an object are WRITE, PRINT, PRINC, PRIN1, and PPRINT (which might all be conceptually defined to make the obvious call to WRITE on that object, although this is not required), their mumble-TO-STRING versions, and PPRINT-LINEAR, PPRINT-FILL, and PPRINT-TABULAR. The printer is recursive, but is the outermost entry to one of these functions that defines the boundary for circularity detection. (PRINT-OBJECT might be included in this set, but it is not necessary since it ought only be called dynamically inside one of the others.)
~A, ~S, ~W and various others (e.g. when a numeric format control is given a non-number) act as if they make the obvious call to WRITE. I maintain that the ANS is firm that the following results (here in sbcl) are correct and required. *PRINT-CIRCLE* is true:
* (let ((g "a")) (format nil "~a ~a" g g)) "a a" * (let ((g "a")) (format nil "~a" (list g g))) "(#1=a #1#)" * (let ((g "a")) (format nil "~{~a ~}" (list g g))) "a a "
The first two examples are clear from the above argument. The third follows from the description of ~{, which specifies that it behaves like a recursive format control, and therefore also does not itself "print an object".
So while the ANS is not ambiguous here, this issue can be hard to understand and a clarification could indeed be useful. However, it can only be a clarification, neither a change nor resolution of an ambiguity. It bears repetition that the X3J13 goal for the ANS was a *specification*. Ease of understanding was of course desirable, but a very secondary consideration. There are a great many tangled or distant interrelated passages; one needs be intimately familiar with the entire document even to rememberwhere to look for the other end of a tangle. Also, it is inconceivable to me that someone not already familiar with some Lisp dialect could learn CL from the ANS.
:Chaitanya Gupta
Actually, I created "CLHS Errata" today by copying the contents of the section "Minor corrections to CLHS (errata)" in "Proposed ANSI Revisions and Clarifications" and re-organizing them a bit.
After reading the pages it seems to me that you the topic is actually the same. The errata page should just be an alias for the "Proposed ANSI Revisions and Clarifications" page, that itself needs to be cleaned up: reorganized in section order. Things that are not strictly errata put in a small font or moved to another page, etc.
Discussions for future standards (rather than Errata or Issues with the current one that can be addressed in its own context) have their own pages: http://www.cliki.net/Proposed%20Extensions%20To%20ANSI and http://www.cliki.net/Lisp%20-%20Next%20Generation
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The state is the coldest of all cold monsters. Coldly it lies, too; and this lie creeps from its mouth: "I, the state, am the people." — Nietzsche
On 15 December 2017 at 07:41, Faré fahree@gmail.com wrote:
:Chaitanya Gupta
Actually, I created "CLHS Errata" today by copying the contents of the section "Minor corrections to CLHS (errata)" in "Proposed ANSI Revisions and Clarifications" and re-organizing them a bit.
After reading the pages it seems to me that you the topic is actually the same.
Mostly yes. However the "Proposed ANSI Revisions and Clarifications" page also contains "Proposed changes to the standard". These are neither errata nor clarifications. For example:
* Un-deprecate REMOVE-IF-NOT, DELETE-IF-NOT. * Issue BOOLEAN-RETURNS: Many functions are specified to return true when they could just as easily return T... * Function FIND makes it impossible to find NIL in a sequence since NIL will be returned regardless of the input sequence. The suggestion is to add a second returned variable that is T if the element was found and NIL if it was not - like in GETHASH. (The usual way to deal with this is to use MEMBER instead.)
So, I think it makes sense to split "Proposed ANSI Revisions and Clarifications" in two pages:
* ANSI Clarifications and Errata -- this should strictly cover only objective issues with the spec (mistakes, ambiguity, inconsistencies, etc.), organized by section. * Proposed ANSI Changes -- any suggested changes should go here. Alternately, these can be merged into "Proposed Extensions to ANSI".
I will try to find some time today and tomorrow to set these two pages up, and if they look good we can update "Proposed ANSI Revisions and Clarifications" to link to these two.
Chaitanya
The errata page should just be an alias for the "Proposed ANSI Revisions and Clarifications" page, that itself needs to be cleaned up: reorganized in section order. Things that are not strictly errata put in a small font or moved to another page, etc.
Discussions for future standards (rather than Errata or Issues with the current one that can be addressed in its own context) have their own pages: http://www.cliki.net/Proposed%20Extensions%20To%20ANSI and http://www.cliki.net/Lisp%20-%20Next%20Generation
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The state is the coldest of all cold monsters. Coldly it lies, too; and this lie creeps from its mouth: "I, the state, am the people." — Nietzsche
On Dec 15, 2017 06:57, "Chaitanya Gupta" mail@chaitanyagupta.com wrote:
On 15 December 2017 at 07:41, Faré fahree@gmail.com wrote:
:Chaitanya Gupta
Actually, I created "CLHS Errata" today by copying the contents of the section "Minor corrections to CLHS (errata)" in "Proposed ANSI Revisions and Clarifications" and re-organizing them a bit.
After reading the pages it seems to me that you the topic is actually the same.
Mostly yes. However the "Proposed ANSI Revisions and Clarifications" page also contains "Proposed changes to the standard". These are neither errata nor clarifications. For example:
* Un-deprecate REMOVE-IF-NOT, DELETE-IF-NOT. * Issue BOOLEAN-RETURNS: Many functions are specified to return true when they could just as easily return T... * Function FIND makes it impossible to find NIL in a sequence since NIL will be returned regardless of the input sequence. The suggestion is to add a second returned variable that is T if the element was found and NIL if it was not - like in GETHASH. (The usual way to deal with this is to use MEMBER instead.)
Depending on how much you squint, these small amendments can be viewed as errata: it was an error, that does not reflect past or future usage, to declare remove-if-not deprecated. The other issues are "gotchas" even if they have no chances of being implemented or even gathering consensus.
Now you are right that they are indeed controversial proposals, and should have a distinctive font or color, or a separate section.
So, I think it makes sense to split "Proposed ANSI Revisions and Clarifications" in two pages:
* ANSI Clarifications and Errata -- this should strictly cover only objective issues with the spec (mistakes, ambiguity, inconsistencies, etc.), organized by section. * Proposed ANSI Changes -- any suggested changes should go here. Alternately, these can be merged into "Proposed Extensions to ANSI".
I will try to find some time today and tomorrow to set these two pages up, and if they look good we can update "Proposed ANSI Revisions and Clarifications" to link to these two.
Chaitanya
The errata page should just be an alias for the "Proposed ANSI Revisions and Clarifications" page, that itself needs to be cleaned up: reorganized in section order. Things that are not strictly errata put in a small font or moved to another page, etc.
Discussions for future standards (rather than Errata or Issues with the current one that can be addressed in its own context) have their own pages: http://www.cliki.net/Proposed%20Extensions%20To%20ANSI and http://www.cliki.net/Lisp%20-%20Next%20Generation
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
The state is the coldest of all cold monsters. Coldly it lies, too; and
this
lie creeps from its mouth: "I, the state, am the people." — Nietzsche
-- https://chaitanyagupta.com https://lisper.in https://twitter.com/chaitanya_gupta
-
Chaitanya Gupta -
Don Morrison -
Faré -
Martin Simmons -
Pierpaolo Bernardi -
Steve Haflich