#V0.2 after a few comments from Matthew Danish
#V0.1 fresh, fully unreviewed.
Please 'attack' the argumentation line.
Knock 'The Scary Readtable' out.
But with facts, please.
;;;---------------------------------------------------------------------
;;; The Scary Readtable #V0.2 - ilias - 2002-09-03
;;;---------------------------------------------------------------------
( ) => { } - [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 now possible 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.
They are fully integrated in the reader-system. Otherwise the
modification of the standardsyntax would be not possible:
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
(eql (get-macro-character #\() (get-macro-character #\{) ) ; =>T
(eql (get-macro-character #\)) (get-macro-character #\}) ) ; =>T
(eql #\) #\} ) ;;=> nil
(eql #\( #\{ ) ;;=> nil
(copy-readtable *backup-readtable* *readtable*) ; restore
{+ 3 2} ; [original behaviour]
(+ 3 2) ; => 5
(eql (get-macro-character #\() (get-macro-character #\{) ) ; => nil
(eql (get-macro-character #\)) (get-macro-character #\}) ) ; => nil
(eql #\) #\} ) ;;=> nil
(eql #\( #\{ ) ;;=> nil
;;;-----------------------------------------------------------------
;;;-----------------------------------------------------------------
Xanalys LispWorks: OK
Franz Allegro : fails
Corman Lisp : fails
....?
In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
> #V0.2 after a few comments from Matthew Danish
> #V0.1 fresh, fully unreviewed.
>
> Please 'attack' the argumentation line.
> Knock 'The Scary Readtable' out.
> But with facts, please.
Ilias,
This is a very well-reasoned line of argumentation, and I think it
deserves to be treated with much more respect than it has met with so
far. You have obviously done your homework and spent quite a bit of time
thinking about this. The fact that you have reached an erroneous
conclusion (and you have) I think points out a weakness in the pedagogy of
the spec. (BTW, Ilias, would you mind telling us what your native
language is? Do you understand words like "pedagogy"?)
What you haven't done, though, is carefully read the responses you've
gotten. The flaw in your argument is very simple, and many people have
pointed it out to you. The Spec says:
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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So when you do:
(set-syntax-from-char #\{ #\( )
what happens is that curly-brace now does *exactly* what left-paren used
to do, namely, read successive objects until a right parenthesis is
found. Note that the spec says that it has to be a right-paren, NOT a
character with the same syntax function as a right paren. This is your
mistake. You are assuming that setting the syntax for right-curly-brace
from right-paren makes right-curly-brace act in all respects like
right-paren. It doesn't. And the reason that it doesn't is because the
spec specifically mentions right-paren in section 2.4.1.
The reason that your example works in Lispworks is that Lispworks has
extended the spec so that its behavior matches your intuition (more or
less -- I think you will find that Lispworks will accept "{...)" after you
run your code.). It is in fact possible to modify the other
implementations so that they behave this way as well. You would have to
write a function that does what read-delimited-list does, except that it
takes a function as an argument instead of a character to specify where
the end of the list is. I won't do this for you since I believe you're
capable of figuring it out yourself. When you do, you will understand
this better than 99% of all Lisp programmers.
Erann Gat
···@jpl.nasa.gov
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@192.168.1.50>...
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>
> 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.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> So when you do:
>
> (set-syntax-from-char #\{ #\( )
>
How about this soltion:
He would have to define #\{ as a macro character, in which case its
function is fired when the reader encounters it. Then he can
recursively read the objects until a closing parenthesis is found.
Best regards...
Erann Gat wrote:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>
>
>>#V0.2 after a few comments from Matthew Danish
>>#V0.1 fresh, fully unreviewed.
>>
>>Please 'attack' the argumentation line.
>>Knock 'The Scary Readtable' out.
>>But with facts, please.
>
>
> Ilias,
>
> This is a very well-reasoned line of argumentation, and I think it
> deserves to be treated with much more respect than it has met with so
> far. You have obviously done your homework and spent quite a bit of time
> thinking about this. The fact that you have reached an erroneous
> conclusion (and you have) I think points out a weakness in the pedagogy of
> the spec. (BTW, Ilias, would you mind telling us what your native
> language is? Do you understand words like "pedagogy"?)
i understand nearly all words that came from Greek.
but somehow my native language is German.
> What you haven't done, though, is carefully read the responses you've
> gotten.
> The flaw in your argument is very simple, and many people have
> pointed it out to you. The Spec says:
>
> 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.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> So when you do:
>
> (set-syntax-from-char #\{ #\( )
>
> what happens is that curly-brace now does *exactly* what left-paren used
> to do, namely, read successive objects until a right parenthesis is
> found. Note that the spec says that it has to be a right-paren, NOT a
> character with the same syntax function as a right paren. This is your
> mistake. You are assuming that setting the syntax for right-curly-brace
> from right-paren makes right-curly-brace act in all respects like
> right-paren. It doesn't. And the reason that it doesn't is because the
> spec specifically mentions right-paren in section 2.4.1.
>
> The reason that your example works in Lispworks is that Lispworks has
> extended the spec so that its behavior matches your intuition (more or
> less -- I think you will find that Lispworks will accept "{...)" after you
> run your code.).
yes it does
> It is in fact possible to modify the other
> implementations so that they behave this way as well. You would have to
> write a function that does what read-delimited-list does, except that it
as i stated very early, read-delimited-list is not the right way.
it think you have seen that in another discussions.
> takes a function as an argument instead of a character to specify where
> the end of the list is. I won't do this for you since I believe you're
> capable of figuring it out yourself. When you do, you will understand
> this better than 99% of all Lisp programmers.
>
> Erann Gat
> ···@jpl.nasa.gov
thanks for your nice words.
for me its clear: something does not fit in all this.
the new text follows.
ilias wrote:
>
> i understand nearly all words that came from Greek.
> but somehow my native language is German.
>
You writing style is highly inconsistent with that of a native speaker of
German. Also, you post from a Greek ISP.
"Have You your Coat to put onforgotten?" - that would have fooled me... :)
Oleg
Oleg <············@myrealbox.com> writes:
> ilias wrote:
>
> >
> > i understand nearly all words that came from Greek.
> > but somehow my native language is German.
> >
>
> You writing style is highly inconsistent with that of a native speaker of
> German. Also, you post from a Greek ISP.
My native language is Swedish -- yet I am more fluent and literate in
English. Also, I post from a United States ISP. Perhaps he moved
from Germany to Greece at a young age.
--
Johan KULLSTAM
Johan Kullstam wrote:
> My native language is Swedish -- yet I am more fluent and literate in
> English.
So the way I see it, there are two possibilities if you are a native
speaker of German (and anything in between the two): your English is good
or, alternatively, it has a trace of German. I'm not detecting it in
Ilias's writing (Not that I'm a big expert, but I saw that Simpsons episode
where a German pretends to be Homer, fooling Homer's wife and kids ;-)
> Also, I post from a United States ISP. Perhaps he moved
> from Germany to Greece at a young age.
Does that happen?!
Cheers,
Oleg
Oleg wrote:
> ilias wrote:
>
>>i understand nearly all words that came from Greek.
>>but somehow my native language is German.
>
> You writing style is highly inconsistent with that of a native speaker of
> German. Also, you post from a Greek ISP.
>
> "Have You your Coat to put onforgotten?" - that would have fooled me... :)
>
> Oleg
Dies trifft nicht zu.
That strike not to.
Vielleicht mache ich ja nur Urlaub in Griechenland.
Maybe make i yes only vacation in Greece.
privacy!
no further comments.
In article <··············@pontos.net>,
ilias <·······@pontos.net> writes:
> ...
> Dies trifft nicht zu.
> That strike not to.
>
> Vielleicht mache ich ja nur Urlaub in Griechenland.
> Maybe make i yes only vacation in Greece.
did you do these translations yourself or did you get the help of
babelfish?
hs
--
don't use malice as an explanation when stupidity suffices
Hartmann Schaffer wrote:
> In article <··············@pontos.net>,
> ilias <·······@pontos.net> writes:
>
>>...
>>Dies trifft nicht zu.
>>That strike not to.
>>
>>Vielleicht mache ich ja nur Urlaub in Griechenland.
>>Maybe make i yes only vacation in Greece.
>
>
> did you do these translations yourself or did you get the help of
> babelfish?
>
> hs
>
see in topic:
"LISP - Garbage Collector - [off topic]"
This is an metaphor, not an insult.
Still don't know how to post links to other topics.
There's Google. But Google is Google.
Not Usenet.
How do you like my Scary Readtable?
Some people say i'm an undereducated illiterate psychopath (summary).
I've the proof ready.
Will post it in an hour.
Proofing the obvious.
Difficult.
Erann Gat wrote:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>
>
>>#V0.2 after a few comments from Matthew Danish
>>#V0.1 fresh, fully unreviewed.
>>
>>Please 'attack' the argumentation line.
>>Knock 'The Scary Readtable' out.
>>But with facts, please.
>
>
> Ilias,
>
> This is a very well-reasoned line of argumentation, and I think it
if your words were true, then why don't you comment the V0.5 version,
which is much better that the V0.2 ???
> What you haven't done, though, is carefully read the responses you've
> gotten. The flaw in your argument is very simple, and many people have
> pointed it out to you. The Spec says:
i've done this now.
see V0.5
> 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.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
i have a direct and an indirect argumentation-line against this.
see document V0.5
> So when you do:
>
> (set-syntax-from-char #\{ #\( )
>
> what happens is that curly-brace now does *exactly* what left-paren used
> to do, namely, read successive objects until a right parenthesis is
> found. Note that the spec says that it has to be a right-paren, NOT a
> character with the same syntax function as a right paren. This is your
> mistake. You are assuming that setting the syntax for right-curly-brace
> from right-paren makes right-curly-brace act in all respects like
> right-paren. It doesn't. And the reason that it doesn't is because the
> spec specifically mentions right-paren in section 2.4.1.
see V0.5 of the document.
> The reason that your example works in Lispworks is that Lispworks has
> extended the spec so that its behavior matches your intuition
Implementation-specific behaviour?
Look at the lines again:
(set-syntax-from-char #\] #\) ) ; => T
(set-syntax-from-char #\[ #\( ) ; => T
Essential core functionality.
There is no tolerance.
> the end of the list is. I won't do this for you since I believe you're
> capable of figuring it out yourself. When you do, you will understand
> this better than 99% of all Lisp programmers.
>
> Erann Gat
> ···@jpl.nasa.gov
of course i can do this.
But the implementations have to.
see document V0.5
On Tue, Sep 03, 2002 at 05:26:23PM +0300, ilias wrote:
> ( ) => { } - [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.
The functionality of the right parenthesis as regarding it's
terminating-token status and error contexts is defined by its
macro-character-function (well, it often is). There is no requirement
that those functionalities nor the end-of-list functionality be
implemented by its macro-character-function, however. Notice how
left-parenthesis has very well defined behavior but right-parenthesis
has very little.
>
> 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,
set-syntax-from-char I presume.
>
> but the now possible form: {a b c) is not!
You are correct. {a b c) is not standard syntax. It is an extension.
>
> but after the second conforming call
> (set-syntax-of-char #\} #\) )
>
> {a b c}
> becomes valid...
This is not any more valid than {a b c). Again it is not standard
syntax. But not only that---it is an extension that depends upon
another extension! Since the macro-character-function of #\) is not
well defined (and left to the implementation) then the way that #\) is
handled is an extension. Depending on the method that #\) is handled to
set the behavior of #\} is therefore an extension of an extension, and
is not guarenteed to work in other conforming ANSI CL implementations.
(Yes, your changes are not "available upon startup" of LispWorks but
presumably you would load them in order to create "ilias" Common Lisp
before loading any of your Lisp files. So they are effectively
extensions. And still nonetheless, you are dependent upon the behavior
of other extensions.) (See chapter 1.6 about extensions).
> 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.
I have read the references you provided. I have looked at the code you
provided. I do not see where you refute this weak point. Please
explain it plainly and simply to me.
The question is: "Is the following implementation of the
macro-character-function of #\( a standard conforming implementation?
Why, or why not?"
(defun read-list (stream char)
(declare (ignore char))
(read-delimited-list #\) stream))
--
; 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."
I will answer my own question (partially): as Tim Bradshaw pointed out
to me, my function is not conforming because it does not handle
consing-dot. However he goes into a much better formulation of the
whole issue so I recommend reading the thread "Why syntax-copying cannot
work".
--
; 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."
>>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 functionality of the right parenthesis as regarding it's
> terminating-token status and error contexts is defined by its
> macro-character-function (well, it often is). There is no requirement
> that those functionalities nor the end-of-list functionality be
> implemented by its macro-character-function, however. Notice how
> left-parenthesis has very well defined behavior but right-parenthesis
> has very little.
ok, were are on the best way to a
[consens: implementation of left-parenthesis, how?]
i hope that noone interupts this by offtopic posts.
we are discussing technically, in-topic 'in-group', an quite cool.
>>{a b c}
>>becomes valid...
>
> This is not any more valid than {a b c). Again it is not standard
> syntax.
it is not standard-syntax, that is correct.
i claim, that i reached this point with conforming standard-syntax.
thus a a conforming implementation must process this scary-syntax.
but lets concentrate on our [consens]
> But not only that---it is an extension that depends upon
> another extension! Since the macro-character-function of #\) is not
> well defined (and left to the implementation) then the way that #\) is
> handled is an extension. Depending on the method that #\) is handled to
> set the behavior of #\} is therefore an extension of an extension, and
> is not guarenteed to work in other conforming ANSI CL implementations.
here again:
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
u must agree, that it is definitely not an extension.
> (Yes, your changes are not "available upon startup" of LispWorks but
> presumably you would load them in order to create "ilias" Common Lisp
> before loading any of your Lisp files. So they are effectively
> extensions. And still nonetheless, you are dependent upon the behavior
> of other extensions.) (See chapter 1.6 about extensions).
so libraries are extensions, and thus non-conforming?
this is not true.
>>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.
>
>
> I have read the references you provided. I have looked at the code you
> provided. I do not see where you refute this weak point. Please
> explain it plainly and simply to me.
it is the whole of the argumentation line.
- The Lisp-reader relies on the readtable.
- () have read-macros & are in the readtable.
- syntax must changeable via readtables.
a clear implementation would not 'violate' this *excellent* design.
- But i,ve found no concrete remark
I'll try to find a more specific point, and i'll may clarify the text again
but first i have to sleep. 22h on the screen.
after sleep picture is clearer.
> The question is: "Is the following implementation of the
> macro-character-function of #\( a standard conforming implementation?
> Why, or why not?"
>
> (defun read-list (stream char)
> (declare (ignore char))
> (read-delimited-list #\) stream))
>
you anwsered this.
ilias <·······@pontos.net> writes:
> #V0.2 after a few comments from Matthew Danish
> #V0.1 fresh, fully unreviewed.
>
> Please 'attack' the argumentation line.
> Knock 'The Scary Readtable' out.
> But with facts, please.
You've done a lot of work constructing a proof. And you're asking
someone to knock holes in it. OK. And since you are using the
Lispworks version of the hyperspec, I'll use that one, too.
Your proof is lacking in two ways:
1. You have done extensive quoting from Sections 2.1 and 2.4, but
have failed to consider the actual Reader Algorithm (section 2.2,
http://www.lispworks.com/reference/HyperSpec/Body/02_b.htm)
carefully enough, as is borne out by the lack of any reference to it
in your proof.
2. You have confused read (which implements the Reader Algorithm) with
read-char.
I'll start with #2 first, even though it may not be immediately apparent
what the relevance is to the discussion. The read function is the
function which implements the Reader Algorithm (note that the next-to-last
"See Also" link in http://www.lispworks.com/reference/HyperSpec/Body/f_rd_rd.htm
points back to Section 2, which is what we are interested in here). The
read function constructs complete tokens from the input stream, according
to the syntax given in Section 2.
In contrast, read-char is a low-level function, which gets the next character
from the specified input stream. No syntax interpretation is attributed to
read-char. See http://www.lispworks.com/reference/HyperSpec/Body/f_rd_cha.htm
Now, to deal with #1, first note from
http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm that #\) is
a terminating macro character. Now, as you have said:
> ;;;---------------------------------------------------------------------
> ;;; The Scary Readtable #V0.2 - ilias - 2002-09-03
> ;;;---------------------------------------------------------------------
>
> ( ) => { } - [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).
So, in Section 2.2 which describes the action of read
(http://www.lispworks.com/reference/HyperSpec/Body/02_b.htm), let's
go through it, starting form the point where we are just reading a
#\) character. For this, I'll use an example, the input
(a b c)
Let's assume that according to the left-parenthesis description, we've
called read successively to gather the tokens a and b, and now we are
in the middle of reading the c. In the Reader Algorithm, this is
step 8. A token is being accumulated, and an even number of multiple-escape
characters have been accumulated (0, in this case). Since we are not yet
at end-of-file, the next character is read, which is the #\). Note that the
hyperlink to character shows the glossary entry to character,
http://www.lispworks.com/reference/HyperSpec/Body/26_glo_c.htm#character,
which among other things states that the fundamental operation on a character
input stream (that is, the fundamental way to get a character from a stream)
is read-char. We'll come back to that later.
According to step 8, since #\) is a terminating macro character, it is unread
and the token being accumulated (c, in this case) is returned from that read
operation.
Next, we might enter another read operation (due to the loop that #\( has
dictated). The method of determining whether the next operation will read
a #\) or not is unspecified (i.e. What does it mean to be "found in the input
stream?" according to http://www.lispworks.com/reference/HyperSpec/Body/02_da.htm;
some lisps use peek-char to see what's ahead. Others may call read specifically.
I think that the peek-char interpretation is the more obvious and at least the
most efficient, and that is what my product does, but let's assume that the
"correct" interpretation is to call read again and receive the right parenthesis:
Step 1 says that we read one character (again via read-char) and thus we read
for the second time the #\) character, and dispatched according to its syntax
type. Note that #\) is not an invalid character according to the definition
of invalid (http://www.lispworks.com/reference/HyperSpec/Body/26_glo_i.htm#invalid)
and according to the table of constyituent traits that #\) carries with it
(http://www.lispworks.com/reference/HyperSpec/Body/02_adb.htm). So step 2 does
not apply. And of course, step 3 does not apply (hopefully for obvious reasons).
So step 4 is the applicable step, because #\) is a terminating macro-character.
The reader macro for #\) may do anything it wants to do, and may return either
0 or one value. The standard #\) reader macro must be able in some way
to communicate back to the #\( reader-macro that the #\) has been seen, otherwise
the #\( reader macro specification would be thwarted.
At no point in this process have we encountered any error situation. Now, you
do bring up a couple of interesting points:
> 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.
You should not read too much into this. In some systems, the #\) reader-macro
simply presents a warning that a right parenthesis is being ignored because
it is extra (i.e. it is not being explicitly looked for in conjunction with
a left paren).
> 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).
Yes, precisely. Note that this definition is part of the whole read syntax
system, and has nothing to do with read-char. If ")" is read by read-char
or peek-char, there is no connection to a reader-macro and a #\) is returned
from read-char. This paragraph you quoted means that a right paren encountered
by _read_ must be paired off with a left paren, or it is invalid. Thus, the
reader-macro for right-paren is free to ignore it, warn about it, or shut down
your machine for you (i.e. is is completely unspecified as to what the
implementation will do). But if the left-paren reader-macro doesn't even use
read to discover that a #\) is next, then no #\) reader macro is called anyway.
> the call (set-syntax-of-char #\{ #\( ) is conforming,
>
> but the now possible form: {a b c) is not!
>
> but after the second conforming call
> (set-syntax-of-char #\} #\) )
>
> {a b c}
> becomes valid...
Your conclusion is faulty based on my argument 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.
Yes, the ability of the #\( reader-macro to use read-char is at the
crux of the issue.
> 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.
Yes, the lisp reader. Not read-char. At the point where the ")" is being
read, read-char may be being used.
> > 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.
Yes, for read, but not for read-char.
> 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.
Yes, for read, but not for read-char.
> 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 fully integrated in the reader-system. Otherwise the
> modification of the standardsyntax would be not possible:
>
>
> 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
All of this mention of the readtable assumes that read is being called.
But as others have pointed out, it is not relevant, because read may not
be the function that is being called.
> 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
>
> (eql (get-macro-character #\() (get-macro-character #\{) ) ; =>T
> (eql (get-macro-character #\)) (get-macro-character #\}) ) ; =>T
>
> (eql #\) #\} ) ;;=> nil
> (eql #\( #\{ ) ;;=> nil
>
> (copy-readtable *backup-readtable* *readtable*) ; restore
>
> {+ 3 2} ; [original behaviour]
> (+ 3 2) ; => 5
Thus, your conclusions about this "requirement" are incorrect.
> (eql (get-macro-character #\() (get-macro-character #\{) ) ; => nil
> (eql (get-macro-character #\)) (get-macro-character #\}) ) ; => nil
>
> (eql #\) #\} ) ;;=> nil
> (eql #\( #\{ ) ;;=> nil
This is an interesting claim; one which could be explored as a separate
discussion, but I will not go into detail here. Suffice it to say that
if you are trying to argue that characters should be treated according
to their syntax and not according to their identity, then your reader
would have to accept a right-paren as well as a right-brace to close off
a left-brace, because its syntax is the same. You should follow your
logic to its own (contradictory) conclusion.
> ;;;-----------------------------------------------------------------
> ;;;-----------------------------------------------------------------
>
> Xanalys LispWorks: OK
> Franz Allegro : fails
> Corman Lisp : fails
None fail. The test is flawed; It assumes that the reader is called
instead of read-char in a critical place.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Sorry for the late response.
Many facts & interconnections.
Needs time to ripe.
So i start:
Duane Rettig wrote:
> ilias <·······@pontos.net> writes:
>
>>#V0.2 after a few comments from Matthew Danish
>>#V0.1 fresh, fully unreviewed.
>>
>>Please 'attack' the argumentation line.
>>Knock 'The Scary Readtable' out.
>>But with facts, please.
>
> You've done a lot of work constructing a proof. And you're asking
> someone to knock holes in it. OK. And since you are using the
> Lispworks version of the hyperspec, I'll use that one, too.
ok.
> Your proof is lacking in two ways:
>
> 1. You have done extensive quoting from Sections 2.1 and 2.4, but
> have failed to consider the actual Reader Algorithm (section 2.2,
> http://www.lispworks.com/reference/HyperSpec/Body/02_b.htm)
> carefully enough, as is borne out by the lack of any reference to it
> in your proof.
your conclusion is wrong.
> 2. You have confused read (which implements the Reader Algorithm)
> with read-char.
the difference is clear.
> I'll start with #2 first, even though it may not be immediately
> apparent what the relevance is to the discussion.
the relevance is clear.
> The read function is the
> function which implements the Reader Algorithm (note that the
> next-to-last "See Also" link in
> http://www.lispworks.com/reference/HyperSpec/Body/f_rd_rd.htm
> points back to Section 2, which is what we are interested in here).
> The read function constructs complete tokens from the input stream,
> according to the syntax given in Section 2.
clarification for readers: read constructs a token internally, validates
it, constructs the object and returns this.
so the term "token" is valid.
> In contrast, read-char is a low-level function, which gets the next
> character from the specified input stream.
ok.
> No syntax interpretation is attributed to
> read-char. See
http://www.lispworks.com/reference/HyperSpec/Body/f_rd_cha.htm
ok
> Now, to deal with #1, first note from
> http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm that
> #\) is
> a terminating macro character. Now, as you have said:
>
>>;;;---------------------------------------------------------------------
>>;;; The Scary Readtable #V0.2 - ilias - 2002-09-03
>>;;;---------------------------------------------------------------------
>>
>>( ) => { } - [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).
> So, in Section 2.2 which describes the action of read
> (http://www.lispworks.com/reference/HyperSpec/Body/02_b.htm), let's
> go through it, starting form the point where we are just reading a
> #\) character. For this, I'll use an example, the input
>
> (a b c)
>
> Let's assume that according to the left-parenthesis description, we've
> called read successively to gather the tokens a and b, and now we are
> in the middle of reading the c.
> In the Reader Algorithm, this is step 8. A token is being
> accumulated, and an even number of multiple-escape
> characters have been accumulated (0, in this case).
> Since we are not yet at end-of-file, the next character is read,
> which is the #\). Note that the hyperlink to character shows the
> glossary entry to character,
> http://www.lispworks.com/reference/HyperSpec/Body/26_glo_c.htm#character,
> which among other things states that the fundamental operation on a
> character input stream (that is, the fundamental way to get a
> character from a stream) is read-char. We'll come back to that later.
correct quote: the " *most* funddamental operation".
> According to step 8, since #\) is a terminating macro character, it is
> unread and the token being accumulated (c, in this case) is returned
> from that read operation.
> Next, we might enter another read operation (due to the loop that #\(
> has dictated). The method of determining whether the next operation
> will read a #\) or not is
[undefined: the method of determining the *is it to read* ]
> unspecified (i.e. What does it mean to be "found in the input stream?"
> according to
> http://www.lispworks.com/reference/HyperSpec/Body/02_da.htm;
> some lisps use peek-char to see what's ahead. Others may call read
> specifically. I think that the peek-char interpretation is the more
> obvious and at least the
> most efficient, and that is what my product does, but let's assume
> that the "correct" interpretation is to call read again and receive
> the right parenthesis:
> Step 1 says that we read one character (again via read-char) and thus
> we read for the second time the #\) character, and dispatched
> according to its syntax type. Note that #\) is not an invalid
> character according to the definition of invalid
> (http://www.lispworks.com/reference/HyperSpec/Body/26_glo_i.htm#invalid)
> and according to the table of constyituent traits that #\) carries
> with it
> (http://www.lispworks.com/reference/HyperSpec/Body/02_adb.htm).
> So step 2 does not apply. And of course, step 3 does not apply
> (hopefully for obvious reasons).
ok.
> So step 4 is the applicable step, because #\) is a terminating
> macro-character.
>
> The reader macro for #\) may do anything it wants to do, and may
> return either 0 or one value. The standard #\) reader macro must be
> able in some way to communicate back to the #\( reader-macro that the
> #\) has been seen, otherwise the #\( reader macro specification would
> be thwarted.
[reader-macro #\) action is unspecified]
> At no point in this process have we encountered any error situation.
> Now, you do bring up a couple of interesting points:
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.
>
> You should not read too much into this.
sorry, it was missleading: this was my interpretation.
> In some systems, the #\) reader-macro
> simply presents a warning that a right parenthesis is being ignored
> because it is extra (i.e. it is not being explicitly looked for in
> conjunction with a left paren).
ok.
>>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).
>
> Yes, precisely.
ok
> Note that this definition is part of the whole read syntax
> system, and has nothing to do with read-char.
of course.
> If ")" is read by read-char
> or peek-char, there is no connection to a reader-macro and a #\) is
> returned from read-char.
of course.
> This paragraph you quoted means that a right paren encountered
> by _read_ must be paired off with a left paren, or it is invalid.
clear.
[parens must be pairs]
> Thus, the
> reader-macro for right-paren is free to ignore it, warn about it, or
> shut down your machine for you (i.e. is is completely unspecified as
> to what the implementation will do).
[reader-macro #\) action is unspecified]
> But if the left-paren reader-macro doesn't even use
> read to discover that a #\) is next, then no #\) reader macro is
> called anyway.
[ *ilias claim 1* : the #\) reader macro *must* be called. ]
>>the call (set-syntax-of-char #\{ #\( ) is conforming,
>>
>>but the now possible form: {a b c) is not!
>>
>>but after the second conforming call
>>(set-syntax-of-char #\} #\) )
>>
>>{a b c}
>>becomes valid...
>
> Your conclusion is faulty based on my argument above.
ok
>>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.
>
> Yes, the ability of the #\( reader-macro to use read-char is at the
> crux of the issue.
[ *ilias claim 2* : the #\) reader macro *must* be used to signal its
ocourence to the #\( reader-macro]
>>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.
> Yes, the lisp reader. Not read-char. At the point where the ")" is
> being read, read-char may be being used.
[read / read-char
[ *ilias claim 3* : read *is* the function that *must* be used for
reading in the right paren ]
>> > 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.
>
> Yes, for read, but not for read-char.
(statement is independent of read/read-char)
[read / not read-char]
>>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.
>
> Yes, for read, but not for read-char.
[read / not read-char]
>>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 fully integrated in the reader-system. Otherwise the
>>modification of the standardsyntax would be not possible:
>>
>>
>>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
>
> All of this mention of the readtable assumes that read is being
> called. But as others have pointed out, it is not relevant, because
> read may not be the function that is being called.
[read / not read-char]
>>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
>>
>>(eql (get-macro-character #\() (get-macro-character #\{) ) ; =>T
>>(eql (get-macro-character #\)) (get-macro-character #\}) ) ; =>T
>>
>>(eql #\) #\} ) ;;=> nil
>>(eql #\( #\{ ) ;;=> nil
>>
>>(copy-readtable *backup-readtable* *readtable*) ; restore
>>
>>{+ 3 2} ; [original behaviour]
>>(+ 3 2) ; => 5
>
>
> Thus, your conclusions about this "requirement" are incorrect.
see below.
>>(eql (get-macro-character #\() (get-macro-character #\{) ) ; => nil
>>(eql (get-macro-character #\)) (get-macro-character #\}) ) ; => nil
>>
>>(eql #\) #\} ) ;;=> nil
>>(eql #\( #\{ ) ;;=> nil
>
>
> This is an interesting claim; one which could be explored as a
> separate discussion, but I will not go into detail here. Suffice it
> to say that
> if you are trying to argue that characters should be treated according
> to their syntax and not according to their identity, then your reader
> would have to accept a right-paren as well as a right-brace to close
> off a left-brace, because its syntax is the same. You should follow
> your logic to its own (contradictory) conclusion.
these were to demonstrate, that set-syntax-from-char does *not* alter
the identity of the char, which of course is correct and conforming
behaviour.
>
>
>>;;;-----------------------------------------------------------------
>>;;;-----------------------------------------------------------------
>>
>>Xanalys LispWorks: OK
>>Franz Allegro : fails
>>Corman Lisp : fails
>
> None fail. The test is flawed; It assumes that the reader is called
> instead of read-char in a critical place.
They fail.
[ *ilias claim 1* : the #\) reader macro *must* be called. ]
[ *ilias claim 2* : the #\) reader macro *must* be used to signal its
ocourence to the #\( reader-macro]
[ *ilias claim 3* : read *is* the function that *must* be used for
reading in the right paren ]
I'll proof the claims in the following version of "The Scary Readtable"
From: Joe Marshall
Subject: Re: LISP - The Scary Readtable - () => {} [#V0.2]
Date:
Message-ID: <n0qvumid.fsf@ccs.neu.edu>
ilias <·······@pontos.net> writes:
>
> [ *ilias claim 1* : the #\) reader macro *must* be called. ]
>
> [ *ilias claim 2* : the #\) reader macro *must* be used to signal its
> ocourence to the #\( reader-macro]
>
> [ *ilias claim 3* : read *is* the function that *must* be used for
> reading in the right paren ]
>
jrm's observation: No existing Common Lisp implementation does this.
ilias and the rest of the Common Lisp community cannot *both* be correct.
Joe Marshall wrote:
> jrm's observation: No existing Common Lisp implementation does this.
>
> ilias and the rest of the Common Lisp community cannot *both* be correct.
Unless there really are chrono-synclastic infundibula. (Roll on the
Church of God the Utterly Indifferent...)
;)w
ilias <·······@pontos.net> writes:
> >>;;;-----------------------------------------------------------------
> >>;;;-----------------------------------------------------------------
> >>
> >>Xanalys LispWorks: OK
> >>Franz Allegro : fails
> >>Corman Lisp : fails
> >
> > None fail. The test is flawed; It assumes that the reader is called
> > instead of read-char in a critical place.
>
> They fail.
We disagree, and I'm through trying to reason with you. You completely
ignored Pascal Costanza's discovery that your _very_ case is coverd
specifically in the spec:
! The attack is simple: See section 23.2 of the HyperSpec, function
! set-syntax-from-char
! (http://www.lispworks.com/reference/HyperSpec/Body/f_set_sy.htm),
! third paragraph in section "Description":
!
!
! "[...] The definition of ( can not be meaningfully copied to {, on the
! other hand. The result is that lists are of the form {a b c), not {a b
! c}, because the definition always looks for a closing parenthesis, not
! a closing brace."
This makes all three of these claims false:
> [ *ilias claim 1* : the #\) reader macro *must* be called. ]
>
> [ *ilias claim 2* : the #\) reader macro *must* be used to signal its
> ocourence to the #\( reader-macro]
>
>
> [ *ilias claim 3* : read *is* the function that *must* be used for
> reading in the right paren ]
>
>
>
>
> I'll proof the claims in the following version of "The Scary Readtable"
Don't bother for my sake; I won't be responding anymore unless you reset
your thinking to start matching the spec.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> ilias <·······@pontos.net> writes:
>
>> >>;;;-----------------------------------------------------------------
>> >>;;;-----------------------------------------------------------------
>> >>
>> >>Xanalys LispWorks: OK
>> >>Franz Allegro : fails
>> >>Corman Lisp : fails
>> >
>> > None fail. The test is flawed; It assumes that the reader is called
>> > instead of read-char in a critical place.
>>
>>They fail.
>
> We disagree,
ok.
> and I'm through trying to reason with you. You completely
> ignored Pascal Costanza's discovery that your _very_ case is coverd
> specifically in the spec:
i've not ignored it.
i've replied.
> ! The attack is simple: See section 23.2 of the HyperSpec, function
> ! set-syntax-from-char
> ! (http://www.lispworks.com/reference/HyperSpec/Body/f_set_sy.htm),
> ! third paragraph in section "Description":
> !
> ! "[...] The definition of ( can not be meaningfully copied to {, on the
> ! other hand. The result is that lists are of the form {a b c), not {a b
> ! c}, because the definition always looks for a closing parenthesis, not
> ! a closing brace."
>
> This makes all three of these claims false:
claim 1 has no relation to the above paragraph.
the above paragraph *canot* disproof:
>>[ *ilias claim 1* : the #\) reader macro *must* be called. ]
claim 2 has a relation.
the above paragraph *does not* disproof:
>>[ *ilias claim 2* : the #\) reader macro *must* be used to signal its
>>ocourence to the #\( reader-macro]
claim 2 has a relation.
the above paragraph *does not* disproof:
>>[ *ilias claim 3* : read *is* the function that *must* be used for
>>reading in the right paren ]
>>I'll proof the claims in the following version of "The Scary Readtable"
hopefully i finish in ... 5 hours.
> Don't bother for my sake; I won't be responding anymore unless you reset
> your thinking to start matching the spec.
I will write the same:
Attack the Scary Readtable.
everyone is free to ignore.
everyone is free to answer.
ilias wrote:
> Duane Rettig wrote:
>> We disagree,
> ok.
>> and I'm through trying to reason with you. You completely
>> ignored Pascal Costanza's discovery that your _very_ case is coverd
>> specifically in the spec:
>
>
> i've not ignored it.
> i've replied.
this here i've replied:
> if i remember right, this paragraph starts the desaster.
>
> i'll correct this in the next version.
>
> the argumentation-line tries to claim that there are higher-priority-definitions in the standard.
>
> i place this paragraph in the next version as starting point. So it gets clearer.
In the last exciting episode, Duane Rettig <·····@franz.com> wrote::
> ilias <·······@pontos.net> writes:
>
>> >>;;;-----------------------------------------------------------------
>> >>;;;-----------------------------------------------------------------
>> >>
>> >>Xanalys LispWorks: OK
>> >>Franz Allegro : fails
>> >>Corman Lisp : fails
>> >
>> > None fail. The test is flawed; It assumes that the reader is called
>> > instead of read-char in a critical place.
>>
>> They fail.
>
> We disagree, and I'm through trying to reason with you. You completely
> ignored Pascal Costanza's discovery that your _very_ case is covered
> specifically in the spec:
People may find it _really_ worthwhile consulting the "Timothy Rue
FAQ"
Big long Google Groups URL shortened to...
<http://makeashorterlink.com/?A130148B1>
Part of it presents that there are two basic answers to the "attack of
the deranged news poster:"
a) Flame back. Unfortunately deranged posters are liable to consider
this encouragement.
b) Passive aggression. Don't respond. Add the deranged poster to
your "kill file" or give a Large Negative Score. Tell (preferably via
email) those that _do_ respond to The Deranged Ones that they're
merely feeding the flames.
There are newsgroups out there that could use a LOT more "passive
aggression" of this sort.
Heavens; there's one fellow that visits can.taxes that apparently does
regular searches on Usenet for references to his name. ******l
L*v**n* (letters omitted to avoid a visit here, although rather like
"Superman versus Batman" or "Alien versus Predator," it might be
entertaining to see what would happen if some of the more aggressive
denizens of comp.lang.lisp came up against him...) has been known to
add newsgroups to his deranged ranting because someone mentioned his
name in the wrong place.
--
(reverse (concatenate 'string ····················@" "454aa"))
http://cbbrowne.com/info/ifilter.html
The meta-Turing test counts a thing as intelligent if it seeks to
apply Turing tests to objects of its own creation.
Christopher Browne wrote:
...
> People may find it _really_ worthwhile consulting the "Timothy Rue
> FAQ"
...
interesting.
have you anything about off-topic-posters?
would interest me, too.
ilias wrote:
> Sorry for the late response.
>
> Many facts & interconnections.
>
> Needs time to ripe.
>
> So i start:
>
> Duane Rettig wrote:
...
i've commented only the critical points where you disagree.
> > According to step 8, since #\) is a terminating macro character, it is
> > unread and the token being accumulated (c, in this case) is returned
> > from that read operation.
>
> > Next, we might enter another read operation (due to the loop that #\(
> > has dictated). The method of determining whether the next operation
> > will read a #\) or not is
>
> [undefined: the method of determining the *is it to read* ]
>
> > unspecified (i.e. What does it mean to be "found in the input stream?"
> > according to
> > http://www.lispworks.com/reference/HyperSpec/Body/02_da.htm;
> > some lisps use peek-char to see what's ahead. Others may call read
> > specifically. I think that the peek-char interpretation is the more
> > obvious and at least the
> > most efficient, and that is what my product does,
What *your* product Franz Allegro does, is not conforming to the ANSI
Standard.
*Rationales* (shortforms, see sections [derivation <x>] for details):
The standard document defines explicitly:
*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 the version #V0.5 for details
> > but let's assume
> > that the "correct" interpretation is to call read again and receive
> > the right parenthesis:
>
> > Step 1 says that we read one character (again via read-char) and thus
> > we read for the second time the #\) character, and dispatched
...
> > So step 4 is the applicable step, because #\) is a terminating
> > macro-character.
> >
> > The reader macro for #\) may do anything it wants to do, and may
> > return either 0 or one value. The standard #\) reader macro must be
> > able in some way to communicate back to the #\( reader-macro that the
> > #\) has been seen, otherwise the #\( reader macro specification would
> > be thwarted.
The standard document defines explicitly:
*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 the version #V0.5 for details
> > Thus, the
> > reader-macro for right-paren is free to ignore it, warn about it, or
> > shut down your machine for you (i.e. is is completely unspecified as
> > to what the implementation will do).
this is wrong:
The standard document defines explicitly:
*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 the version #V0.5 for details
> > But if the left-paren reader-macro doesn't even use
> > read to discover that a #\) is next, then no #\) reader macro is
> > called anyway.
The standard document defines explicitly:
*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 the version #V0.5 for details
> >>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.
> >
> > Yes, the ability of the #\( reader-macro to use read-char is at the
> > crux of the issue.
This is false. see above.
> >>;;;-----------------------------------------------------------------
> >>;;;-----------------------------------------------------------------
> >>
> >>Xanalys LispWorks: OK
> >>Franz Allegro : fails
> >>Corman Lisp : fails
> >
> > None fail. The test is flawed; It assumes that the reader is called
> > instead of read-char in a critical place.
It does not assume this simply.
It is backuped by the specs:
What *your* product Franz Allegro does, is not conforming to the ANSI
Standard.
*Rationales* (shortforms, see sections [derivation <x>] for details):
The standard document defines explicitly:
*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 the version #V0.5 for details
ilias wrote:
> #V0.2 after a few comments from Matthew Danish
> #V0.1 fresh, fully unreviewed.
>
> Please 'attack' the argumentation line.
> Knock 'The Scary Readtable' out.
> But with facts, please.
>
> ;;;---------------------------------------------------------------------
> ;;; The Scary Readtable #V0.2 - ilias - 2002-09-03
> ;;;---------------------------------------------------------------------
>
> ( ) => { } - [with CommonLisp conforming code]
The attack is simple: See section 23.2 of the HyperSpec, function
set-syntax-from-char
(http://www.lispworks.com/reference/HyperSpec/Body/f_set_sy.htm), third
paragraph in section "Description":
"[...] The definition of ( can not be meaningfully copied to {, on the
other hand. The result is that lists are of the form {a b c), not {a b
c}, because the definition always looks for a closing parenthesis, not a
closing brace."
Pascal
Pascal Costanza wrote:
> ilias wrote:
>> Please 'attack' the argumentation line.
> The attack is simple: See section 23.2 of the HyperSpec, function
> set-syntax-from-char
> (http://www.lispworks.com/reference/HyperSpec/Body/f_set_sy.htm), third
> paragraph in section "Description":
>
> "[...] The definition of ( can not be meaningfully copied to {, on the
> other hand. The result is that lists are of the form {a b c), not {a b
> c}, because the definition always looks for a closing parenthesis, not a
> closing brace."
if i remember right, this paragraph starts the desaster.
i'll correct this in the next version.
the argumentation-line tries to claim that there are
higher-priority-definitions in the standard.
i place this paragraph in the next version as starting point. So it gets
clearer.