> Matthew Danish wrote: >> On Mon, Sep 02, 2002 at 10:40:02AM +0300, ilias wrote: >>>> The crucial piece you are missing is that the reader-macro >>>> function for >>>> #\( is allowed to only look for a delimiting #\) character.
>>> where do you get this information?
>> I forgot to address this in my previous post. >> >> CLHS Chapter 2.4.1 ``Left-Parenthesis'': >> >> ``The left-parenthesis initiates reading of a list. read is called >> recursively to read successive objects until a right parenthesis >> is found in the input stream. A list of the objects read is >> returned.'' >> >> As you can see, it explicitly says in the standard that the >> reader-macro for #\( is allowed to only look for a #\) character in >> the stream. It does not need to look for anything more abstract >> than that. >
> The paragraph "CLHS Chapter 2.4.1 ``Left-Parenthesis'':" is > misleading. > > So you've derived a wrong conclusion. > > #\} (closing_brace) is a legal terminator for the > > Proof: > > not enouth margin. > > i'll be back in an hour! >
here it is:
A fresh #V0.1 text, fully unreviewed. please forgive the delay please remember that i'm a LISP-novice.
;;;--------------------------------------------------------------------- ;;; The Scary Readtable ;;;---------------------------------------------------------------------
> The syntax described by this chapter is called the standard syntax. > Operations are provided by Common Lisp so that various aspects > of the syntax information represented by a readtable can be modified > under program control; see Section 23 (Reader). Except as explicitly > stated otherwise, the syntax used throughout this document is > standard syntax.
An conforming implementation has to support the standard syntax.
http://www.lispworks.com/reference/HyperSpec/Body/02_aa.htm > Syntax information for use by the Lisp reader is embodied in an > object called a readtable. Among other things, the readtable > contains the association between characters and syntax types.
The readtable embodies the syntax information for the Lisp reader.
http://www.lispworks.com/reference/HyperSpec/Body/t_rdtabl.htm#readtable > A readtable maps characters into syntax types for the Lisp reader; > see Section 2 (Syntax). A readtable also contains associations between > macro characters and their reader macro functions, and records > information about the case conversion rules to be used by the Lisp > reader when parsing symbols.
> Each simple character must be representable in the readtable.
> A fresh #V0.1 text, fully unreviewed. please forgive the delay > please remember that i'm a LISP-novice.
> ;;;--------------------------------------------------------------------- > ;;; The Scary Readtable > ;;;---------------------------------------------------------------------
> ( ) => { } - [with CommonLisp conforming code]
Your message has too many off-topic and irrelevant details in it. You give too much information that noone is interested in. Noone will ever _seriously_ attempt to just replace parentheses by curly braces because there is no good reason to do that. (And this _is_ a very exact and precise comment to your message.)
> Xanalys LispWorks: OK > Franz Allegro : fails > Corman Lisp : fails
> ...?
Please see the glossary in the HyperSpec - here are some quotes:
"conforming implementation n. an implementation, used to emphasize complete and correct adherance to all conformance criteria. A conforming implementation is capable of accepting a conforming program as input, preparing that program for execution, and executing the prepared program in accordance with this specification. An implementation which has been extended may still be a conforming implementation provided that no extension interferes with the correct function of any conforming program.
conforming program n. a program, used to emphasize the fact that the program depends for its correctness only upon documented aspects of Common Lisp, and can therefore be expected to run correctly in any conforming implementation."
Your program runs only on LispWorks so it is obviously not a conforming program.
Please see also section 1.5 "Conformance" in the HyperSpec.
You haven't found any kind of proof whatsoever, but you have just stumbled across minor implementation details with regard to conformance that are only slightly interesting to the majority of Common Lisp users.
the form (eql #\) #\}) returns T (proof was given earlier).
-- Regards, Alexey Dejneka :-)
--- 11:04:01 <wnewman> bad voodoo is when you can't explain why it works, seriously bad voodoo is when you can't even explain what it is, and the comment is like "don't touch the code in this file or it will probably stop working":-)
>> A fresh #V0.1 text, fully unreviewed. please forgive the delay >> please remember that i'm a LISP-novice.
>> ;;;--------------------------------------------------------------------- >> ;;; The Scary Readtable >> ;;;---------------------------------------------------------------------
>> ( ) => { } - [with CommonLisp conforming code]
> Your message has too many off-topic and irrelevant details in it. You
i see you use my words of my last answer to you tonight.
i was just writing the answer to your post, that i was not able to answer, cause i was analyzing. i'd had better explained that.
sorry, if you felt attacked or rejected or somewhat. It was a little rude from me, but i'm not always a good diplomat while in assimilation-process.
now ok, i'll answer this here first.
> give too much information that noone is interested in.
i don't think so. the information is out of the specs. although it fits well in the general climatic conditions in this forum, i suggest you to speak for yourself. It can be dangerous to use to early the 'we'-form in a community.
> Noone will ever > _seriously_ attempt to just replace parentheses by curly braces because > there is no good reason to do that. > (And this _is_ a very exact and precise comment to your message.)
so i review it with precision.
i (i am one) have just attempt to do that. '_seriously_' is relative. But a conformity-check is a good and serious reason.
>> Xanalys LispWorks: OK >> Franz Allegro : fails >> Corman Lisp : fails
>> ...?
> Please see the glossary in the HyperSpec - here are some quotes:
i've look at the CLHS (Common Lisp HyperSpec) all the night.
> "conforming implementation n. an implementation, used to emphasize > complete and correct adherance to all conformance criteria. A conforming > implementation is capable of accepting a conforming program as input, > preparing that program for execution, and executing the prepared program > in accordance with this specification. An implementation which has been > extended may still be a conforming implementation provided that no > extension interferes with the correct function of any conforming program.
> conforming program n. a program, used to emphasize the fact that the > program depends for its correctness only upon documented aspects of > Common Lisp, and can therefore be expected to run correctly in any > conforming implementation."
thanks that you quote the basic fundament of the language conformity proof.
> Your program runs only on LispWorks so it is obviously not a conforming > program.
false.
for your statement beeing true, the other CL-implementations must be conforming.
My conforming programm is not accepted by uncomforming implementations of Common Lisp.
They may have simply missinterpretated the specs, or they have a simple bug in their code.
They are analysts, programmers - not gods. As the writer of the specs.
And as i'm not a god, too, my proof is maybe wrong.
> Please see also section 1.5 "Conformance" in the HyperSpec.
I'm tired. Will eat something. And the i have to answer some people here.
> You haven't found any kind of proof whatsoever, but you have just > stumbled across minor implementation details with regard to conformance > that are only slightly interesting to the majority of Common Lisp users.
Thats fine. So they are at minimum slightly interesting to the minority of CL users.
>> Your message has too many off-topic and irrelevant details in it. You
> i see you use my words of my last answer to you tonight.
> i was just writing the answer to your post, that i was not able to > answer, cause i was analyzing. i'd had better explained that.
Yes.
> now ok, i'll answer this here first.
>> give too much information that noone is interested in.
> i don't think so.
...but I think so. You haven't given any reason yet why you would want to replace parentheses by curly braces. It doesn't make any sense.
Here is an analogy: when you try to learn English, you don't start by replacing some of the letters of the English alphabet with Greek letters just to make it look "nicer".
> the information is out of the specs.
...but is not relevant to the question why you want to replace the parentheses with something else. If you are interested in a fruitful discussion you should first explain why you want this replacement.
> although it fits well in the general climatic conditions in this forum, > i suggest you to speak for yourself. It can be dangerous to use to early > the 'we'-form in a community.
I have used the "we"-form as a rhetoric device. Sorry, if this was unclear. To be more precise: I cannot imagine that anyone, including you, would seriously want to replace parentheses with something else. Maybe my imagination is lacking, but then I would be happy to learn what the benefit would be of changing the parentheses into something else.
>> Noone will ever _seriously_ attempt to just replace parentheses by >> curly braces because there is no good reason to do that. >> (And this _is_ a very exact and precise comment to your message.)
> so i review it with precision.
> i (i am one) have just attempt to do that.
...and why do you need this? What is your motivation?
> '_seriously_' is relative.
No it isn't. Here is a quote from a dictionary: "'serious' implies a concern for what really matters". Syntax is superficial, you don't get more expressive power by replacing parentheses with curly braces. I don't think that such a replacement "really matters" when compared to the big advantages you get by using Common Lisp's expressive power at the semantic level.
> But a conformity-check is a good and serious reason.
For what purpose?
[...]
> Attack the proofing-line at a specific point.
Why?
> What is your main interest?
...to understand why you want to replace parentheses with curly braces. Why do you need this? Is checking the conformance of Common Lisp implementations a hobby of yours?
> The true/false state of the proof?
No, I am not interested at all in this proof. My impression is that you are trying to solve a specific problem with the wrong means. Are you really interested in getting help with the concrete problem you want to solve? Then you should perhaps give more information about the context for which you want to have a solution.
My impression was that you are looking for your "dream" language that - among other things - should have a specific syntax that pleases your eyes, conforms to your sense of aesthetics. Is this the case?
If yes, you are using the wrong languages and the wrong tools.
If no, please explain what you are actually after.
On Tue, Sep 03, 2002 at 12:53:22PM +0300, ilias wrote:
[quotes omitted]
> the call (set-syntax-of-char #\{ #\( ) is conforming,
> but the resulting form: {a b c) is not!
It is not the resulting form. (technicality) But you can now type {a b c) in and obtain similar behavior to (a b c).
> but after the second conforming call > (set-syntax-of-char #\} #\) )
> {a b c} > becomes valid...
Then why is {a b c) not valid? Here you are neglecting the additional fact that the reader-macro for #\{ looks for a #\). Therefore the value of {a b c} at this point is not equivalent to (a b c).
> Someone may says, here is a weak point in the proof:
> The implementor may don't use the reader-macro-function of ')' but to > compare directly the char retrieved via read-char.
None of your quotes or arguments address this weak point.
[more quotes omitted, to save space]
> A conforming CommonLisp implementation *must* execute:
> (setq *backup-readtable* (copy-readtable) ) ; backup current
> ;;;create a new readtable, with actual readtable > (setq *scary-readtable* (copy-readtable) )
> Xanalys LispWorks: OK > Franz Allegro : fails > Corman Lisp : fails
> ...?
LispWorks's behavior is an extension to the specification. There is no question that people far more experienced than you have been working on Allegro CL and Corman Lisp for years and even decades. While there is the possibility that even a newcomer could discover a misinterpretation or a bug, that should come as a great surprise to him. Blaming the compiler for one's own flawed logic is an old excuse in many venues, and not accepted in any one. Rather you should eliminate all other possible sources of doubt, and re-examine your statements until they are air-tight. The fact that many people have already picked apart your claims should be alerting you that something is wrong with your inferences.
If you still don't understand what is wrong, even after re-reading the counter-arguments that myself and others have posted, then attempt to narrow down your confusion and formulate a specific question. You may even be able to answer it yourself, once you've written it down.
-- ; Matthew Danish <mdan...@andrew.cmu.edu> ; OpenPGP public key: C24B6010 on keyring.debian.org ; Signed or encrypted mail welcome. ; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote: > On Tue, Sep 03, 2002 at 12:53:22PM +0300, ilias wrote: > [quotes omitted]
>>the call (set-syntax-of-char #\{ #\( ) is conforming,
>>but the resulting form: {a b c) is not!
> It is not the resulting form. (technicality) > But you can now type {a b c) in and obtain similar behavior to (a b c).
you are right. i'll change this.
>>but after the second conforming call >>(set-syntax-of-char #\} #\) )
>>{a b c} >>becomes valid...
> Then why is {a b c) not valid?
i quoted: > http://www.lispworks.com/reference/HyperSpec/Body/02_db.htm >> The right-parenthesis is invalid except when used in conjunction with >> the left parenthesis character. For more information, see Section 2.2 >> (Reader Algorithm).
> Here you are neglecting the additional > fact that the reader-macro for #\{ looks for a #\). Therefore the > value of {a b c} at this point is not equivalent to (a b c).
see above.
>>Someone may says, here is a weak point in the proof:
>>The implementor may don't use the reader-macro-function of ')' but to >>compare directly the char retrieved via read-char.
> None of your quotes or arguments address this weak point. > [more quotes omitted, to save space]
what you have omitted do this. the complete following line.
> There is no > question that people far more experienced than you have been working on > Allegro CL and Corman Lisp for years and even decades. While there is > the possibility that even a newcomer could discover a misinterpretation > or a bug, that should come as a great surprise to him. Blaming the > compiler for one's own flawed logic is an old excuse in many venues, and > not accepted in any one. Rather you should eliminate all other possible > sources of doubt, and re-examine your statements until they are > air-tight. The fact that many people have already picked apart your > claims should be alerting you that something is wrong with your > inferences.
> If you still don't understand what is wrong, even after re-reading the > counter-arguments that myself and others have posted, then attempt to > narrow down your confusion and formulate a specific question. You may > even be able to answer it yourself, once you've written it down.
Stop this phrases about experience and all that.
i have given a clear argumentation line.
attack it.
with words, backed up by links, references, links. Minimalistic.
In article <3D74B144.D1B5B...@dls.net>, Paul F. Dietz wrote: > Ok everyone, ilias will not 'conversate' with us if we're > not friendly.
> I want everyone to be as unfriendly as possible with > this person, preferably by email. Go for it.
No. That is not going to work. I believe this Ilias actually enjoys unfriendly responses.
Elias once revealed the secret power of questioning in his article "Crowds and Power":
Sometimes, however, the questioner is not content with this [an answer] and will put further questions. If these continue the person they are addressed to soon becomes annoyed: [...]
On the questioner the effect is an enhanced feeling of power. He enjoys this and consequently asks more and more questions; every answer he receives is an act of submission. [...]
So, what we have here is a prototypical troll. His goal is to annoy as many people as possible and keep drawing responses. Elias continues:
It is possible to find answers which prevent further questions. Alternatively, anyone [...] can counter with questions of his own: [...]
Note how Ilias spends least possible effort to answer counter- questions he is asked.
Lastly, Elias also wrote: "Questions are intended to be answered;
those which are not answered are like arrows shot into the air."
Takehiko Abe wrote: > In article <3D74B144.D1B5B...@dls.net>, Paul F. Dietz wrote:
>>Ok everyone, ilias will not 'conversate' with us if we're >>not friendly.
>>I want everyone to be as unfriendly as possible with >>this person, preferably by email. Go for it.
> No. That is not going to work. I believe this Ilias actually enjoys > unfriendly responses.
> Elias once revealed the secret power of questioning in his article > "Crowds and Power":
> Sometimes, however, the questioner is not content with > this [an answer] and will put further questions. If these > continue the person they are addressed to soon becomes > annoyed: [...]
> On the questioner the effect is an enhanced feeling of > power. He enjoys this and consequently asks more and more > questions; every answer he receives is an act of submission. > [...]
> So, what we have here is a prototypical troll. His goal is to annoy as > many people as possible and keep drawing responses. Elias continues:
> It is possible to find answers which prevent further > questions. Alternatively, anyone [...] can counter with > questions of his own: [...]
> Note how Ilias spends least possible effort to answer counter- > questions he is asked.
> Lastly, Elias also wrote: "Questions are intended to be answered; > those which are not answered are like arrows shot into the air."
knowledge is a dangerous thing.
i aswer the questions to me, that are in-topic.
i share the 'products' of my learning process with the public.
do you really think i enjoy filtering the mass of off-context, off-topic and off-civility replies.
why don't you comment my 2-liner for the 1st problem i asked the group? I've posted it?
Why don't you comment / disproof my claim, that {}-forms are conformant CommonLisp?
>>>> If no, please explain what you are actually after.
>>> i'll talk with you about ghosts.
>> Sorry, I don't understand this sentence. What do you mean?
> you ask permanently what i'm after.
Yes, and you haven't answered this yet. However, I think it is crucial to understand your motivations in order to give you the help you need.
I think that you can help moving this discussion forward by clearly stating your goals. And I don't think it's too hard for you to answer my questions.
> you say: there's a ghost.
> i say: no there isn't.
>>> be friendly.
>> What makes you think I am not?
> 'ghosts' and your writing style.
> simply reread in a few hours or tomorrow.
You are just trying to guess what _my_ motivations are and try to avoid to answer my questions.
Stop these statements about ghosts and all that.
I have stated a clear question.
Answer it.
With words, backed up by goals, rationale, motivation. Minimalistic.
>>>> Pascal Costanza wrote: >>>> ... >>>>> If no, please explain what you are actually after. >>>> i'll talk with you about ghosts. >>> Sorry, I don't understand this sentence. What do you mean? >> you ask permanently what i'm after. > Yes, and you haven't answered this yet. However, I think it is crucial > to understand your motivations in order to give you the help you need.
> I think that you can help moving this discussion forward by clearly > stating your goals. And I don't think it's too hard for you to answer my > questions.
>> you say: there's a ghost. >> i say: no there isn't. >>>> be friendly. >>> What makes you think I am not? >> 'ghosts' and your writing style. >> simply reread in a few hours or tomorrow. > You are just trying to guess what _my_ motivations are and try to avoid > to answer my questions.
i don't try. and i'm not interested in your person. you are not friendly.
> Stop these statements about ghosts and all that.
ok.
> I have stated a clear question.
many times.
> Answer it.
imperative. rejected.
> With words, backed up by goals, rationale, motivation. Minimalistic.
> > The opponents of ilias miss a very simple idea: in the conformant > > implementation of iCL after executing > > (setq *scary-readtable* (copy-readtable) ) > > (copy-readtable *scary-readtable* *readtable*) > > (set-syntax-from-char #\} #\) ) > > (set-syntax-from-char #\{ #\( ) > > the form (eql #\) #\}) returns T (proof was given earlier).
> false. the result in NIL
Heh. Let's see the proof.
ilias wrote: > "giving } the *same* *definition* as the standard definition of the > character )"
> this is very clear. If the closing_brace gets the same definition of > the closing_paren, then the closing_brace must behave like a > closing_paren.
> Conclusion: the reader *must* recognize the closing_brace
Ok. When the reader see ``#\)'', what is the behavior of ``)'' preceded by ``#\''? It is to return the character ``)''. What is the behavior of ``}'' preceded by ``#\''? The same. So, the reader must return the character ``)''. Therefore (eql #\) #\}) => T QED
>>"giving } the *same* *definition* as the standard definition of the >>character )"
>>this is very clear. If the closing_brace gets the same definition of >>the closing_paren, then the closing_brace must behave like a >>closing_paren.
>>Conclusion: the reader *must* recognize the closing_brace
this is an early-text, and i agree, misleading.
> Ok. When the reader see ``#\)'', what is the behavior of ``)'' > preceded by ``#\''? It is to return the character ``)''. What is the > behavior of ``}'' preceded by ``#\''? The same. So, the reader must > return the character ``)''. Therefore > (eql #\) #\}) => T > QED
ilias wrote: > Matthew Danish wrote: > > On Tue, Sep 03, 2002 at 12:53:22PM +0300, ilias wrote: > > [quotes omitted]
> >>the call (set-syntax-of-char #\{ #\( ) is conforming,
> >>but the resulting form: {a b c) is not!
> > It is not the resulting form. (technicality) > > But you can now type {a b c) in and obtain similar behavior to > > (a b c).
> you are right. i'll change this.
You can't (not the way you're trying to do it).
The standard allows a conforming implementation to look for the close-paren character. You'll have to re-write code in the lisp reader.
Here's the code for read-list, which is what the CMUCL reader uses as the reader macro function for #\(
(defun read-list (stream ignore) (declare (ignore ignore)) (let* ((thelist (list nil)) (listtail thelist)) (do ((firstchar (flush-whitespace stream) (flush-whitespace stream))) ((char= firstchar #\) ) (cdr thelist)) (when (char= firstchar #\.) (let ((nextchar (read-char stream t))) (cond ((token-delimiterp nextchar) (cond ((eq listtail thelist) (%reader-error stream "Nothing appears before . in list.")) ((whitespacep nextchar) (setq nextchar (flush-whitespace stream)))) (rplacd listtail ;;return list containing last thing. (car (read-after-dot stream nextchar))) (return (cdr thelist))) ;;put back nextchar so we can read it normally. (t (unread-char nextchar stream))))) ;;next thing is not an isolated dot. (let ((listobj (read-maybe-nothing stream firstchar))) ;;allows the possibility that a comment was read. (when listobj (rplacd listtail listobj) (setq listtail listobj))))))
You'll notice that the do loop has the following end test:
(char= firstchar #\) )
This is a hard-coded comparison to the right parenthesis character. Thus you can't make the CMUCL reader accept something other than right-parenthesis as the closing list delimiter without modifying this code.
This is conforming behavior, as has already been pointed out.
If you decide to modify this code, you'd have to do similar things for Allegro Common Lisp and other Lisps that don't have the behavior you want --- and you may not have access to the source code to do the modification.
-- Fred Gilham gil...@csl.sri.com Lisp has jokingly been called "the most intelligent way to misuse a computer". I think that description is a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts. E. Dijkstra
"ilias" believes that after doing set-syntax-from-char on #\{ (from \#() and on \#} (from #\)), the reader should interpret {a b c} in the same way as it does (a b c). The parent of this article (much of which is quoted below) claims to be a proof of that.
Ilias, you may want to skip everything between the line that says "*** START SKIPPING HERE" and the line that says "*** STOP SKIPPING HERE", if you're in a hurry. What's between those lines is point-by-point comment on what you wrote. What's after them is an explanation of why your attempted proof is not successful.
> The functionality of right parenthesis is integrated in the > reader-system via its macro-character-function.
The spec doesn't say that. It says that #\) is defined as a macro character in every conforming implementation. It *doesn't* say what its definition as a macro character has to accomplish; in particular, it doesn't say that its definition as a macro character has to be what makes it work together with #\(.
I think that in most implementations, the macro character definition of #\) just signals an error.
> the call (set-syntax-of-char #\{ #\( ) is conforming,
> but the resulting form: {a b c) is not!
That is not a form. It's a string of characters. "{a b c)" may be interpreted as denoting a list by the Lisp reader after you do (set-syntax-from-char #\{ #\(), and I think that's perfectly legal. The statement that #\) is "invalid" except after #\( describes a CL implementation in its initial state; you can change that state.
> but after the second conforming call > (set-syntax-of-char #\} #\) )
> {a b c} > becomes valid...
That's your claim. It is not supported by the spec.
> Someone may says, here is a weak point in the proof:
> The implementor may don't use the reader-macro-function of ')' but to > compare directly the char retrieved via read-char.
And you have correctly identified the way in which your claim is wrong :-).
> > The syntax described by this chapter is called the standard syntax. > > Operations are provided by Common Lisp so that various aspects > > of the syntax information represented by a readtable can be modified > > under program control; see Section 23 (Reader). Except as explicitly > > stated otherwise, the syntax used throughout this document is > > standard syntax.
> An conforming implementation has to support the standard syntax.
Correct.
> http://www.lispworks.com/reference/HyperSpec/Body/02_aa.htm > > Syntax information for use by the Lisp reader is embodied in an > > object called a readtable. Among other things, the readtable > > contains the association between characters and syntax types.
> The readtable embodies the syntax information for the Lisp reader.
The readtable embodies *some* of the syntax information for the Lisp reader. The spec doesn't say, nor does it mean, that *everything* about Lisp syntax is determined by the readtable.
> http://www.lispworks.com/reference/HyperSpec/Body/t_rdtabl.htm#readtable > > A readtable maps characters into syntax types for the Lisp reader; > > see Section 2 (Syntax). A readtable also contains associations between > > macro characters and their reader macro functions, and records > > information about the case conversion rules to be used by the Lisp > > reader when parsing symbols.
> > Each simple character must be representable in the readtable.
It must. This doesn't mean that every syntactic change you can think of must be achievable by readtable modifications alone. (The page you reference doesn't say anything like that.)
[SNIP: you aren't allowed to change the standard readtable; correct.]
> But the following is not only *allowed*.
> A conforming CommonLisp implementation *must* execute:
[SNIP: set-syntax-from-char twice in a new readtable; Ilias claims it must do as he says]
*** STOP SKIPPING HERE
You haven't really explained why you think that the reader macro function for #\(, when you've associated it with #\{ using SET-SYNTAX-FROM-CHAR, needs to start looking for #\} instead of #\). I conjecture that your argument goes like this:
1 Syntax is modified using the readtable. 2 Therefore, everything about a character's role in Lisp syntax must change when you change its entry in the readtable. 3 Therefore, after (SET-SYNTAX-FROM-CHAR #\} #\)), #\} must behave exactly as #\) used to, including being accepted as a list-closer for #\( or -- if you've copied its syntax to #\{ -- for #\{.
The incorrect step is #2. It is not required that everything about a character's role in Lisp syntax must change when you change its entry in the readtable.
The readtable controls three things about a character. - Its syntax type. (See section 2.1.4.) - Its reader macro function, if any. - What should be done with its case when parsing symbols. (This one isn't settable character-by-character.)
These three things do not determine whether that character is acceptable as a terminator for a list begun with #\(, or with #\{, or with anything else.
A conforming Lisp implementation is allowed to use the readtable for other purposes too. Apparently LispWorks uses it to decide what characters are acceptable list terminators in the reader macro function for #\(. That's permitted by the spec, but it isn't required by the spec.
> Xanalys LispWorks: OK > Franz Allegro : fails > Corman Lisp : fails
Allegro and Corman Lisp don't "fail" on this point. They merely don't do what you expect. If they don't recognize #\} as a list terminator after the code you described, they are fully within their rights.
-- Gareth McCaughan Gareth.McCaug...@pobox.com .sig under construc
Fred Gilham wrote: > If you decide to modify this code, you'd have to do similar things for > Allegro Common Lisp and other Lisps that don't have the behavior you > want --- and you may not have access to the source code to do the > modification.
Which, BTW, you can do in CLISP and Corman Lisp because the source code is available for each.
> You'll notice that the do loop has the following end test:
> (char= firstchar #\) )
yes. clearly a char.
> This is a hard-coded comparison to the right parenthesis character. > Thus you can't make the CMUCL reader accept something other than > right-parenthesis as the closing list delimiter without modifying this > code.
clear.
> This is conforming behavior, as has already been pointed out.
maybe. still working on it.
> If you decide to modify this code, you'd have to do similar things for > Allegro Common Lisp and other Lisps that don't have the behavior you > want --- and you may not have access to the source code to do the > modification.
Gareth McCaughan wrote: > "ilias" believes that after doing set-syntax-from-char > on #\{ (from \#() and on \#} (from #\)), the reader > should interpret {a b c} in the same way as it does (a b c). > The parent of this article (much of which is quoted below) > claims to be a proof of that.
> Ilias, you may want to skip everything between the line > that says "*** START SKIPPING HERE" and the line that says > "*** STOP SKIPPING HERE", if you're in a hurry. What's > between those lines is point-by-point comment on what > you wrote. What's after them is an explanation of why > your attempted proof is not successful.
> *** START SKIPPING HERE
>>http://www.lispworks.com/reference/HyperSpec/Body/02_da.htm >> > The left-parenthesis initiates reading of a list. >> > read is called recursively to read successive objects >> > until a right parenthesis is found in the input stream.
>>This is true for the standard-syntax (standard-readtable).
>>The functionality of right parenthesis is integrated in the >>reader-system via its macro-character-function.
> The spec doesn't say that. It says that #\) is defined > as a macro character in every conforming implementation. > It *doesn't* say what its definition as a macro character > has to accomplish; in particular, it doesn't say that > its definition as a macro character has to be what makes > it work together with #\(.
> I think that in most implementations, the macro character > definition of #\) just signals an error.
OK. will change!
>>http://www.lispworks.com/reference/HyperSpec/Body/02_db.htm >> > The right-parenthesis is invalid except when used in conjunction with >> > the left parenthesis character. For more information, see Section 2.2 >> > (Reader Algorithm).
>>the call (set-syntax-of-char #\{ #\( ) is conforming,
>>but the resulting form: {a b c) is not!
> That is not a form. It's a string of characters.
OK. will change!
> "{a b c)" may be interpreted as denoting a list > by the Lisp reader after you do (set-syntax-from-char #\{ #\(), > and I think that's perfectly legal. The statement that #\) > is "invalid" except after #\( describes a CL implementation > in its initial state; you can change that state.
ok. I should state that i refere to standardsyntax at top of the document.
>>but after the second conforming call >>(set-syntax-of-char #\} #\) )
>>{a b c} >>becomes valid...
> That's your claim. It is not supported by the spec.
yes, my claim.
>>Someone may says, here is a weak point in the proof:
>>The implementor may don't use the reader-macro-function of ')' but to >>compare directly the char retrieved via read-char.
> And you have correctly identified the way in which > your claim is wrong :-).
I wanted to focus the attention of the readers to this point.
this is a so called "Sollbruchstelle" (cannot find english term: in mechanical engeneering, where a part should break if it breaks).
>> > The syntax described by this chapter is called the standard syntax. >> > Operations are provided by Common Lisp so that various aspects >> > of the syntax information represented by a readtable can be modified >> > under program control; see Section 23 (Reader). Except as explicitly >> > stated otherwise, the syntax used throughout this document is >> > standard syntax.
>>An conforming implementation has to support the standard syntax.
> Correct.
OK
>>http://www.lispworks.com/reference/HyperSpec/Body/02_aa.htm >> > Syntax information for use by the Lisp reader is embodied in an >> > object called a readtable. Among other things, the readtable >> > contains the association between characters and syntax types.
>>The readtable embodies the syntax information for the Lisp reader.
> The readtable embodies *some* of the syntax information > for the Lisp reader. The spec doesn't say, nor does it > mean, that *everything* about Lisp syntax is determined > by the readtable.
> I think this is where you have gone astray.
intuition: it has too, but cannot explain (yet). we'll see how i change.
>>http://www.lispworks.com/reference/HyperSpec/Body/t_rdtabl.htm#readtable >> > A readtable maps characters into syntax types for the Lisp reader; >> > see Section 2 (Syntax). A readtable also contains associations between >> > macro characters and their reader macro functions, and records >> > information about the case conversion rules to be used by the Lisp >> > reader when parsing symbols.
>> > Each simple character must be representable in the readtable.
>>left & right parenthesis are included in the readtables. >>left & right braces are included in the readtables.
> They are, yes.
OK
>>The standard-syntax must be modifyable by change of the readtable: >>http://www.lispworks.com/reference/HyperSpec/Body/t_rdtabl.htm#readtable > > It must. This doesn't mean that every syntactic change you > can think of must be achievable by readtable modifications > alone. (The page you reference doesn't say anything like that.) yes, wrong link. will correct.
> [SNIP: you aren't allowed to change the standard readtable; > correct.]
> [SNIP: set-syntax-from-char twice in a new readtable; > Ilias claims it must do as he says]
> *** STOP SKIPPING HERE
> You haven't really explained why you think that the reader macro > function for #\(, when you've associated it with #\{ using > SET-SYNTAX-FROM-CHAR, needs to start looking for #\} instead > of #\). I conjecture that your argument goes like this:
> 1 Syntax is modified using the readtable. > 2 Therefore, everything about a character's role > in Lisp syntax must change when you change its > entry in the readtable. > 3 Therefore, after (SET-SYNTAX-FROM-CHAR #\} #\)), > #\} must behave exactly as #\) used to, including > being accepted as a list-closer for #\( or -- if > you've copied its syntax to #\{ -- for #\{.
not exactly this line.
> The incorrect step is #2. It is not required that > everything about a character's role in Lisp syntax > must change when you change its entry in the readtable.
point 2, not *everything*. (eql #\) #\} ) => nil
> The readtable controls three things about a character. > - Its syntax type. (See section 2.1.4.) > - Its reader macro function, if any. > - What should be done with its case when parsing symbols. > (This one isn't settable character-by-character.)
everything a reader needs.
> These three things do not determine whether that character > is acceptable as a terminator for a list begun with #\(, > or with #\{, or with anything else.
this *seems* correct.
> A conforming Lisp implementation is allowed to use the > readtable for other purposes too. Apparently LispWorks > uses it to decide what characters are acceptable list > terminators in the reader macro function for #\(. That's > permitted by the spec, but it isn't required by the spec.
> Allegro and Corman Lisp don't "fail" on this point. > They merely don't do what you expect. If they don't > recognize #\} as a list terminator after the code > you described, they are fully within their rights.
