ilias wrote:
> 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
;;;---------------------------------------------------------------------
( ) => { } - [with CommonLisp conforming code]
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).
http://www.lispworks.com/reference/HyperSpec/Body/02_d.htm
> The macro characters defined initially in a conforming implementation
> include the following:
> 2.4.2 Right-Parenthesis
The functionality of right parenthesis is integrated in the
reader-system via its macro-character-function.
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!
but after the second conforming call
(set-syntax-of-char #\} #\) )
{a b c}
becomes valid...
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.
Lets look further:
http://www.lispworks.com/reference/HyperSpec/Body/02_a.htm
> The Lisp reader takes characters from a stream, interprets them as a
> printed representation of an object, constructs that object, and
> returns it.
> 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.
http://www.lispworks.com/reference/HyperSpec/Body/02_ac.htm
> All implementations must support a character repertoire called
> standard-char; characters that are members of that repertoire are
> called standard characters.
left & right parenthesis are included in the readtables.
left & right braces are included in the readtables.
The standard-syntax must be modifyable by change of the readtable:
http://www.lispworks.com/reference/HyperSpec/Body/t_rdtabl.htm#readtable
However, it is not allowed to change the standard-readtable itself:
http://www.lispworks.com/reference/HyperSpec/Body/26_glo_s.htm#standard_readtable
so the calls:
(set-syntax-of-char #\} #\) )
(set-syntax-of-char #\{ #\( )
were not allowed to be used while the standard-readtable is the
current-readtable.
But the following is not only *allowed*.
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) )
(copy-readtable *scary-readtable* *readtable*) ; activates readtable
;;; following code modifies the *scary-readtable*
(set-syntax-from-char #\} #\) ) ;
(set-syntax-from-char #\{ #\( ) ;
{+ 3 2} ; => 5
(+ 3 2) ; => 5
(copy-readtable *backup-readtable* *readtable*) ; restore
{+ 3 2} ; [original behaviour]
(+ 3 2) ; => 5
;;;-----------------------------------------------------------------
ilias - 2002-09-03 - #V0.1
;;;-----------------------------------------------------------------
Xanalys LispWorks: OK
Franz Allegro : fails
Corman Lisp : fails
...?
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) )
>
> (copy-readtable *scary-readtable* *readtable*) ; activates readtable
>
> ;;; following code modifies the *scary-readtable*
> (set-syntax-from-char #\} #\) ) ;
> (set-syntax-from-char #\{ #\( ) ;
Doing this does not (eql #\} #\)) make.
>
> {+ 3 2} ; => 5
> (+ 3 2) ; => 5
>
> (copy-readtable *backup-readtable* *readtable*) ; restore
>
> {+ 3 2} ; [original behaviour]
> (+ 3 2) ; => 5
> ;;;-----------------------------------------------------------------
> ilias - 2002-09-03 - #V0.1
> ;;;-----------------------------------------------------------------
>
> 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 <·······@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.
but ok, maybe i add an comment.
>>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) )
>>
>>(copy-readtable *scary-readtable* *readtable*) ; activates readtable
>>
>>;;; following code modifies the *scary-readtable*
>>(set-syntax-from-char #\} #\) ) ;
>>(set-syntax-from-char #\{ #\( ) ;
>
>
> Doing this does not (eql #\} #\)) make.
this would be an error.
what it does make is:
(eql (get-macro-character #\() (get-macro-character #\{) ) = T
>>{+ 3 2} ; => 5
>>(+ 3 2) ; => 5
>>
>>(copy-readtable *backup-readtable* *readtable*) ; restore
>>
>>{+ 3 2} ; [original behaviour]
>>(+ 3 2) ; => 5
>>;;;-----------------------------------------------------------------
>>ilias - 2002-09-03 - #V0.1
>>;;;-----------------------------------------------------------------
>>
>>Xanalys LispWorks: OK
>>Franz Allegro : fails
>>Corman Lisp : fails
>>
>>...?
>
>
> LispWorks's behavior is an extension to the specification.
just words? no proof? no link? no reference?
> 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.
reduce, don't rase complexity.
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 ······@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
From: Erik Naggum
Subject: Re: LISP - The Scary Readtable - () => {}
Date:
Message-ID: <3240071539475559@naggum.no>
* Fred Gilham
| (do ((firstchar (flush-whitespace stream) (flush-whitespace stream)))
Note that `flush-whitespace� may be portably done with (peek-char t stream).
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
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.
faa
Fred Gilham wrote:
> ilias wrote:
>>Matthew Danish wrote:
>>>>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).
no. here i mean't the article. in V0.2 i've clarified, that it is a
possible form.
> The standard allows a conforming implementation to look for the
> close-paren character.
yes, i know this. The main problem.
> 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)
...
> (setq listtail listobj))))))
will look at the full code at later time.
for now to complex.
> 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.
will try with CL functions or own code.
ilias wrote:
> 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
> ;;;---------------------------------------------------------------------
>
> ( ) => { } - [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.
Pascal
Pascal Costanza wrote:
> ilias wrote:
>
>> 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
>> ;;;---------------------------------------------------------------------
>>
>> ( ) => { } - [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.
Attack the proofing-line at a specific point.
What is your main interest?
The true/false state of the proof?
Or to be accepted by this community here?
You can have both.
Let us be gentleman!!!
ilias wrote:
> Pascal Costanza wrote:
>
>> ilias wrote:
>>
>>> 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
>>> ;;;---------------------------------------------------------------------
>>>
>>> ( ) => { } - [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.
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.
Pascal
Pascal Costanza wrote:
...
> If no, please explain what you are actually after.
i'll talk with you about ghosts.
be friendly.
than i'll conversate with you again.
From: Paul F. Dietz
Subject: Re: LISP - The Scary Readtable - () => {}
Date:
Message-ID: <3D74B144.D1B5B776@dls.net>
ilias wrote:
> i'll talk with you about ghosts.
>
> be friendly.
>
> than i'll conversate with you again.
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.
Paul
Paul F. Dietz wrote:
> ilias wrote:
>
>
>>i'll talk with you about ghosts.
>>
>>be friendly.
>>
>>than i'll conversate with you again.
>
>
> 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.
>
> Paul
you make a public call for spamming me?
bravo!
In article <·················@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."
--
This message was not sent to you unsolicited.
Takehiko Abe wrote:
> In article <·················@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?
Cool down.
Raise the quality of this group.
ilias wrote:
> 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?
> be friendly.
What makes you think I am not?
Pascal
Pascal Costanza wrote:
> ilias wrote:
>
>> 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.
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.
ilias wrote:
> Pascal Costanza wrote:
>
>> ilias wrote:
>>
>>> 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.
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.
Reduce, don't increase the complexity.
Pascal
Pascal Costanza wrote:
> ilias wrote:
>
>> Pascal Costanza wrote:
>>
>>> ilias wrote:
>>>
>>>> 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.
yes, use this for disproof.
> Reduce, don't increase the complexity.
i reduce.
cool down. i'll be there.
From: Alexey Dejneka
Subject: The origin of blindness (Was: Re: LISP - The Scary Readtable - () => {})
Date:
Message-ID: <m3n0qz9vkn.fsf_-_@comail.ru>
Pascal Costanza <········@web.de> writes:
> ilias wrote:
>
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).
--
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":-)
From: ilias
Subject: Re: The origin of blindness (Was: Re: LISP - The Scary Readtable - () => {})
Date:
Message-ID: <3D74B4B5.5050400@pontos.net>
Alexey Dejneka wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>ilias wrote:
>>
>
>
> 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
the correct line is:
(eql (get-macro-character #\) ) (get-macro-character #\} )) => T
in any conformat implementation of CL.
From: Alexey Dejneka
Subject: Re: The origin of blindness (Was: Re: LISP - The Scary Readtable - () => {})
Date:
Message-ID: <m3elcb114o.fsf@comail.ru>
ilias <·······@pontos.net> writes:
> Alexey Dejneka wrote:
> > Pascal Costanza <········@web.de> writes:
> >
> >>ilias wrote:
> >>
> > 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
Where do you see a mistake?
--
Regards,
Alexey Dejneka
From: ilias
Subject: Re: The origin of blindness (Was: Re: LISP - The Scary Readtable - () => {})
Date:
Message-ID: <3D74E881.6020405@pontos.net>
Alexey Dejneka 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
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
>
> Where do you see a mistake?
in the way i wrote. missleading.
take the new text. its more precise.
"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).
Correct.
> http://www.lispworks.com/reference/HyperSpec/Body/02_d.htm
> > The macro characters defined initially in a conforming implementation
> > include the following:
>
> > 2.4.2 Right-Parenthesis
>
> 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.
> 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.
"{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 :-).
> Lets look further:
>
> http://www.lispworks.com/reference/HyperSpec/Body/02_a.htm
> > The Lisp reader takes characters from a stream, interprets them as a
> > printed representation of an object, constructs that object, and
> > returns it.
>
> > 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.
I think this is where you have gone astray.
> 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.
>
> http://www.lispworks.com/reference/HyperSpec/Body/02_ac.htm
> > All implementations must support a character repertoire called
> > standard-char; characters that are members of that repertoire are
> > called standard characters.
>
> left & right parenthesis are included in the readtables.
> left & right braces are included in the readtables.
They are, yes.
> 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.)
[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 ················@pobox.com
.sig under construc
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).
>
> Correct.
OK.
>>http://www.lispworks.com/reference/HyperSpec/Body/02_d.htm
>> > The macro characters defined initially in a conforming implementation
>> > include the following:
>>
>> > 2.4.2 Right-Parenthesis
>>
>>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).
>>Lets look further:
>>
>>http://www.lispworks.com/reference/HyperSpec/Body/02_a.htm
>> > The Lisp reader takes characters from a stream, interprets them as a
>> > printed representation of an object, constructs that object, and
>> > returns it.
>>
>> > 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.
>>
>>http://www.lispworks.com/reference/HyperSpec/Body/02_ac.htm
>> > All implementations must support a character repertoire called
>> > standard-char; characters that are members of that repertoire are
>> > called standard characters.
>>
>>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.]
OK
>>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 #\{.
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.
OK
>>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.
'within their rights'
sounds ok.
many thanks for this thoroughly attack.
i'll rewrite the document now.
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.
...
i've concentrated on the points where you disagree.
for you convenience, i've copied the rationales out of
The Scary Readtable #V0.5.
>>http://www.lispworks.com/reference/HyperSpec/Body/02_d.htm
>> > The macro characters defined initially in a conforming implementation
>> > include the following:
>>
>> > 2.4.2 Right-Parenthesis
>>
>>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;
The specs says that:
*Rationale c)* - see section [derivation c]
" A *right-parenthesis* has an associated function called a reader macro
function that implements its specialized parsing behavior. [...] "
see Version 0.5 of "The Scary Readtable"
>>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.
see Version 0.5 of "The Scary Readtable"
>>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 :-).
*Rationale a)* - see section [derivation a]
" A *right-parenthesis* terminates any token, and the
*right-parenthesis-reader macro function* is called no matter where the
*right-parenthesis* appears."
*Rationale b)* - see section [derivation b]
"[...] Upon encountering a *right-parenthesis* the *function READ* calls
the *right-parenthesis-reader macro function*"
*Rationale c)* - see section [derivation c]
" A *right-parenthesis* has an associated function called a reader macro
function that implements its specialized parsing behavior. [...] "
see Version 0.5 of "The Scary Readtable"
>>Lets look further:
...
> 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 #\).
*Rationale a)* - see section [derivation a]
" A *right-parenthesis* terminates any token, and the
*right-parenthesis-reader macro function* is called no matter where the
*right-parenthesis* appears."
*Rationale b)* - see section [derivation b]
"[...] Upon encountering a *right-parenthesis* the *function READ* calls
the *right-parenthesis-reader macro function*"
*Rationale c)* - see section [derivation c]
" A *right-parenthesis* has an associated function called a reader macro
function that implements its specialized parsing behavior. [...] "
see Version 0.5 of "The Scary Readtable"
> 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.