LISP - The Scary Readtable - () => [] - [#V0.4]
ilias
#V0.3 after many comments, see forum discussion
#V0.2 after few comments, see forum discussion
#V0.1 fresh, fully unreviewed.
Please 'attack' the argumentation line.
=> not my undereducation
Knock 'The Scary Readtable' out.
=> not my 'psychological damages'
But with facts, please.
If possible write like this:
- Link to CLHS, quote, conclusion.
- Statement, link to CLHS, quote
- Avoid out of context information and rhetoric comments.
(this writing-style enables readers to follow easily the 'lines')
I don't use scientific notation. So it can be understood by everyone.
This is good for me, too. As i don't know scientific notation.
I've changed {} to [] so everything is more readable.
http://www.lispworks.com/reference/HyperSpec/Body/02_a.htm
"Except as explicitly stated otherwise, the syntax used throughout this
document is standard syntax."
Same for this Document. The remark 'ncs' means non-conforming-syntax
;;;-----------------------------------------------------------------
;;; The Scary Readtable #V0.4 - ilias - 2002-09-09
;;;-----------------------------------------------------------------
( ) => [ ] - with CommonLisp conforming code
:::short-form of claim (see end of text for the full version):
(set-syntax-from-char #\] #\) ) ; => T
(set-syntax-from-char #\[ #\( ) ; => T
[+ 3 2] ;ncs => 5
The main arguments that [+ 3 2] *can* but *must not* be executed by a
Conforming Implementation starts with...
The definition of left-parenthesis:
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. "
The definition is then used in set-syntax-from-char:
http://www.lispworks.com/reference/HyperSpec/Body/f_set_sy.htm
" 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."
[Remark: the text in CLHS refers to {} but can be applied identical to
the [] pair, which I've chosen for better visibility ]
This sounds clear!
That's why different people claiming:
"until the right parenthesis is found". This refers to the char #\).
The #\) can be read via 'read-char', so bypassing read function
The #\)-reader-macro must not be called
The #\)-reader-macro must not interact with the #\)-reader macro
*Ilias claims:*
[ *claim 1* : the #\) reader macro function *must* be called. ]
[ *claim 2* : READ *is* the function that *must* be used for reading in
the right paren ]
[ *claim 3* : the #\) reader macro *must* be used to signal its
occurrence to the #\( reader-macro]
=====================================================================
*proofs*:
*initial definitions*:
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
[...] "
=> *Right-Parenthesis* is defined as *macro character*.
http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm
"[...] ) terminating macro char [...] "
=> *Right-Parenthesis* is defined as *terminating* macro character
http://www.lispworks.com/reference/HyperSpec/Body/26_glo_l.htm#lisp_reader
"Lisp reader n. Trad. the procedure that parses character
representations of objects from a stream, producing objects. (This
procedure is implemented by the function read.)"
=> The *Lisp reader* is implemented by the *function READ*
The definition of the macro character / terminating macro character:
http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
3rd paragraph:
"[...] Upon encountering a macro character, the Lisp reader calls its
reader macro function, which parses one specially formatted object from
the input stream. The function either returns the parsed object, or else
it returns no values to indicate that the characters scanned by the
function are being ignored (e.g., in the case of a comment). Examples of
macro characters are backquote, single-quote, left-parenthesis, and
right-parenthesis. [...]"
4th paragraph, at the end:
"[...] A terminating macro character terminates any token, and its
associated reader macro function is called no matter where the character
appears. [...]"
Now quoting the original text while replacing the terms of the
*initial-definitions*:
macro character => right-parenthesis
terminating macro => right-parenthesis
Lisp reader => function READ
"[...] Upon encountering a *right-parenthesis* the *function READ* calls
the *right-parenthesis-reader macro function*"
This poofs: [ *claim 2* : READ *is* the function that *must* be used for
reading in the right paren ]
" A *right-parenthesis* terminates any token, and the
*right-parenthesis-reader macro function* is called no matter where the
*right-parenthesis* appears."
This proofs: [ *claim 1* : the #\) reader macro function *must* be called. ]
========================================================================
http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
2nd paragraph
" A macro character has an associated function called a reader macro
function that implements its specialized parsing behavior. An
association of this kind can be established or modified under control of
a conforming program by using the functions set-macro-character and
set-dispatch-macro-character."
Again, quoting the original text while replacing the terms of the
*initial-definitions*:
" A *right-parenthesis* has an associated function called a reader macro
function that implements its specialized parsing behavior. [...] "
this proofs: [ *claim 3* : the #\) reader macro *must* be used to signal
its occurrence to the #\( reader-macro]
-
=========================================================================
http://www.lispworks.com/reference/HyperSpec/Body/01_eada.htm
"1.5.1.4.1 Resolution of Apparent Conflicts in Exceptional Situations"
" If more than one passage in this specification appears to apply to the
same situation but in conflicting ways, the passage that appears to
describe the situation in the most specific way (not necessarily the
passage that provides the most constrained kind of error detection)
takes precedence. "
=========================================================================
A major part of the reader-concept vs. the right-paren.
A conforming Common Lisp implementation *must* execute:
;;;;----------------------------------------------------------------
;;;; The Scary Readtable #V0.4 - ilias - 2002-09-09
;;;;----------------------------------------------------------------
;;;definitive starting state
;;;activate a fresh standard-readtable
(setq *readtable* (copy-readtable nil) )
;;;create a new readtable, with a fresh standard readtable
(setq *scary-readtable* (copy-readtable nil) )
;;; activate *scary-readtable*
(copy-readtable *scary-readtable* *readtable*) ; activates readtable
;;; following code modifies the *scary-readtable*
(set-syntax-from-char #\] #\) ) ;
(set-syntax-from-char #\[ #\( ) ;
;;; syntax in now non-conforming (but legal)
(+ 3 2) ; => 5
[+ 3 2] ; => 5
(eql (get-macro-character #\() (get-macro-character #\[) ) ; =>T
(eql (get-macro-character #\)) (get-macro-character #\]) ) ; =>T
;;; the char-code muste be still different
(eql #\) #\] ) ;;=> nil
(eql #\( #\[ ) ;;=> nil
(setq *readtable* (copy-readtable nil)) ; restore standard-syntax
;;; syntax is conforming again
(+ 3 2) ; => 5
[+ 3 2] ; [original behaviour]
(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
.....?
Please let me know your test results.
I cannot reach unix-versions / MAC-Versions.
-
Please don't feel offended. We're humans, not gods.
(i just found a minimalistic proof. but now is time to sleep)
ilias
> ;;; The Scary Readtable #V0.4 - ilias - 2002-09-09
> ;;;-----------------------------------------------------------------
>
> ( ) => [ ] - with CommonLisp conforming code
>
> :::short-form of claim (see end of text for the full version):
>
> (set-syntax-from-char #\] #\) ) ; => T
> (set-syntax-from-char #\[ #\( ) ; => T
> [+ 3 2] ;ncs => 5
>
> The main arguments that [+ 3 2] *can* but *must not* be executed by a
> Conforming Implementation starts with...
this is a little bit missleading, especially when someone stops reading
at this point. i try to clarify:
The main arguments *against* the claim that [+ 3 2] *must be* executed
by a(n) {ANSI <spec. no.> Conforming LISP Implementation} #- todo:
insert ANSI terminology #+ starts with...
=======================================================================
ilias
Things stuck.
At this point i'd like to ask you to *confirm* my proof, if you think
that i'm right.
Joe Marshall
> At this point i'd like to ask you to *confirm* my proof, if you think
> that i'm right.
No one here thinks you are right.
Joel Ray Holveck
Ignoring any other fallacies, here's a few:
"[...] Upon encountering a *right-parenthesis* the *function READ*
calls the *right-parenthesis-reader macro function*"
This poofs: [ *claim 2* : READ *is* the function that *must* be used
for reading in the right paren ]
Your constructed specifies what must happen when READ encounters a
#\). It doesn't specify that the #\( function can't use another
technique to scan for it, eg, read-delimited-list (which scans for the
terminator as if with peek-char, not read). I see nothing in your
article that does.
Additionally, I see no reason that I see that the #\) dispatch
function cannot throw its second argument up the stack. The #\( may
be looking at that argument, and let the throw continue if it doesn't
match #\).
joelh
PS: My willingness to post this article does not constitute an
assertion of my willingness to discuss the matter further.
ilias
don't worry.
that's a common manner hier in c.l.l.
to make it easy for you, i will not comment your post.
ilias
I'm scared.
The Herd of Savages.
They don't care.
The Spirit of Lisp.
Violated.
ilias
"
[...]
Future Work
Let me be clear: I'm not saying the specification couldn't be trimmed
here and there. There are definitely some inconsistencies that could be
ironed out.
[...]
"
iron.
ilias
20 lines shortform
--------------------------------------------------------------------
*Claim* (shortform, see section [claim] for details):
An ANSI Conforming Common Lisp implementation *must* execute:
(set-syntax-from-char #\] #\) ) ; => T
(set-syntax-from-char #\[ #\( ) ; => T
[+ 3 2] ; => 5
*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. [...] "
--------------------------------------------------------------------
[claim]
;;;;----------------------------------------------------------------
;;;; The Scary Readtable #V0.5 - ilias - 2002-09-12
;;;;----------------------------------------------------------------
;;; ( ) => [ ] - with CommonLisp conforming code
;;; definitive starting state
;;; activate a fresh standard-readtable
(copy-readtable nil *readtable*)
;;; (copy-readtable nil) creates a fresh standard-readtable
(setq *scary-readtable* (copy-readtable nil) )
;;; activate *scary-readtable*
;;; notice the direction: from-readtable -> to-readtable
(copy-readtable *scary-readtable* *readtable*) ; activates readtable
;;; following code modifies the *scary-readtable*
(set-syntax-from-char #\] #\) ) ;
(set-syntax-from-char #\[ #\( ) ;
;;; syntax is now non-conforming (but legal)
(+ 3 2) ; => 5
[+ 3 2] ; => 5 [the main point]
(eql (get-macro-character #\() (get-macro-character #\[) ) ; =>T
(eql (get-macro-character #\)) (get-macro-character #\]) ) ; =>T
;;; the char-code muste be still different
(eql #\) #\] ) ;;=> nil
(eql #\( #\[ ) ;;=> nil
(copy-readtable nil *readtable*) ; restore standard-syntax
;;; syntax is conforming again
(+ 3 2) ; => 5
[+ 3 2] ; [original behaviour], some error
(eql (get-macro-character #\() (get-macro-character #\[) ) ; => nil
(eql (get-macro-character #\)) (get-macro-character #\]) ) ; => nil
(eql #\) #\] ) ;;=> nil
(eql #\( #\[ ) ;;=> nil
;;;-----------------------------------------------------------------
[ *claim 1* : the #\) reader macro function *must* be called. ]
[ *claim 2* : READ *is* the function that *must* be used for
reading in the right paren ]
[ *claim 3* : the #\) reader macro *must* be used to signal
its occurrence to the #\( reader-macro]
;;;-----------------------------------------------------------------
=====================================================================
[derivations]:
=====================================================================
---------------------------------------------------------------------
*initial definitions*:
---------------------------------------------------------------------
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
[...] "
=> *Right-Parenthesis* is defined as *macro character*.
http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm
"[...] ) terminating macro char [...] "
=> *Right-Parenthesis* is defined as *terminating* macro character
http://www.lispworks.com/reference/HyperSpec/Body/26_glo_l.htm#lisp_reader
"Lisp reader n. Trad. the procedure that parses character
representations of objects from a stream, producing objects. (This
procedure is implemented by the function read.)"
=> The *Lisp reader* is defined to be implemented by the *function READ*
---------------------------------------------------------------------
Some of the many resulting possible concretisations:
a macro character =>a right-parenthesis
a terminating macro character => a right-parenthesis
the Lisp reader => the function READ
---------------------------------------------------------------------
*[derivation a]*
---------------------------------------------------------------------
*The general definition of the terminating macro characters:*
http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
4th paragraph, at the end:
"[...] A terminating macro character terminates any token, and its
associated reader macro function is called no matter where the character
appears. [...]"
concretisation to right-parenthesis:
" A *right-parenthesis* terminates any token, and the
*right-parenthesis-reader macro function* is called no matter where the
*right-parenthesis* appears."
This proofs: [ *claim 1* : the #\) reader macro function *must* be called. ]
---------------------------------------------------------------------
*[derivation b]*
---------------------------------------------------------------------
*The general definition of the macro characters:*
http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
3rd paragraph:
"[...] Upon encountering a macro character, the Lisp reader calls its
reader macro function, which parses one specially formatted object from
the input stream. The function either returns the parsed object, or else
it returns no values to indicate that the characters scanned by the
function are being ignored (e.g., in the case of a comment). Examples of
macro characters are backquote, single-quote, left-parenthesis, and
right-parenthesis. [...]"
*concretisation to right-parenthesis:*
"[...] Upon encountering a *right-parenthesis* the *function READ* calls
the *right-parenthesis-reader macro function*"
This poofs: [ *claim 2* : READ *is* the function that *must* be used for
reading in the right paren ]
---------------------------------------------------------------------
*[derivation c]*
---------------------------------------------------------------------
*The general definition of the macro characters:*
http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
2nd paragraph
" A macro character has an associated function called a reader macro
function that implements its specialized parsing behavior. An
association of this kind can be established or modified under control of
a conforming program by using the functions set-macro-character and
set-dispatch-macro-character."
*concretisation to right-parenthesis:*
" A *right-parenthesis* has an associated function called a reader macro
function that implements its specialized parsing behavior. [...] "
this proofs: [ *claim 3* : the #\) reader macro *must* be used to signal
its occurrence to the #\( reader-macro]
-
=========================================================================
The main arguments *against* the claim:
=========================================================================
*The definition of left-parenthesis:*
*[rejoinder a]*
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 definition of left-parenthesis is then referenced in...
*The definition of set-syntax-from-char:*
[Remark: the text in the specs refers to {} but can be applied identical
to the [] pair, which has been chosen for better visibility ]
*[rejoinder b]*
http://www.lispworks.com/reference/HyperSpec/Body/f_set_sy.htm
" 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."
"[..] because the *definition* always looks[...]" refers to the
definition of left-parenthesis.
[rejoinder b] depends on [rejoinder a].
So i focus on [rejoinder a].
=========================================================================
"1.5.1.4.1 Resolution of Apparent Conflicts in Exceptional Situations"
=========================================================================
http://www.lispworks.com/reference/HyperSpec/Body/01_eada.htm
" If more than one passage in this specification appears to apply to the
same situation but in conflicting ways, the passage that appears to
describe the situation in the most specific way (not necessarily the
passage that provides the most constrained kind of error detection)
takes precedence. "
=========================================================================
The passages under [Rationale a,b,c] describe the situation in the most
specific way. They define explicitly and undoubtable.
Whereas the passage under [rejoinder a] is unspecific.
But even if you take [rejoinder a]:
[rejoinder a]
" 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. "
The term *left-parenthesis* refers to the *definition of
left-parenthesis* or more precise to the
*syntax-definition-of-left-parenthesis*.
Simple Rationale:
The *syntax-definition-of-left-parenthesis* initiates the reading of a
list *not* the character *left-parenthesis* itself.
Conclusion:
The term *right parenthesis* in the same sentence refers to
*syntax-definition-of-right-parenthesis* and not to the character
*right-parenthesis*.
Simple Backup:
http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm
[...] The syntax type of a character in a readtable determines how that
character is interpreted by the Lisp reader [...]
-------------------------------------------------------------------------
I think i've done it.
-------------------------------------------------------------------------
Please let me know your test results.
I cannot reach unix-versions / MAC-Versions.
====================================================================
#V0.5 after lots of silence, see forum 'discussion'
#V0.4 after some attacks to my person, see forum 'discussion'
http://groups.google.com/groups?selm=3D7BFA52...@pontos.net
#V0.3 after many comments, see forum discussion
http://groups.google.com/groups?selm=3D795720...@pontos.net
#V0.2 after few comments, see forum discussion
http://groups.google.com/groups?selm=3D74C68F...@pontos.net
#V0.1 fresh, fully unreviewed.
http://groups.google.com/groups?selm=3D748692...@pontos.net
ilias
> --------------------------------------------------------------------
> 20 lines shortform
> --------------------------------------------------------------------
i make a 20 lines shortform.
is here really *not one* person, which has the gentleness to respond to
this assertion?
now, where i've spent very much time to clarify my words and my
argumentation-lines.
now, where it is easy for the reader to read-trough?
This is c.l.l.
Where are the scientists?
These, who have science in their heart.
Teach. Learn. Impeach. Claim. Proof. Rejoin.
...
Espen Vestre
> is here really *not one* person, which has the gentleness to respond
> to this assertion?
Can't catch me
I'm syntax-free
-- Sonic Youth
--
(espen)
Will Deakin
> Teach. Learn. Impeach. Claim. Proof. Rejoin.
;)w
Coby Beck
"ilias" <at_...@pontos.net> wrote in message
news:alrd14$58$1...@usenet.otenet.gr...
> ilias wrote:
> > ------------------------------------------------
> > 20 lines shortform
> > ------------------------------------------------
>
> i make a 20 lines shortform.
>
> is here really *not one* person, which has the gentleness
> to respond to this assertion?
ilias, you have had *many* people respond to your assertion. You have not
had the "gentleness" to understand what they have written.
>
> now, where i've spent very much time to clarify my words and my
> argumentation-lines.
>
> now, where it is easy for the reader to read-trough?
>
> This is c.l.l.
>
> Where are the scientists?
>
> These, who have science in their heart.
>
> Teach. Learn. Impeach. Claim. Proof. Rejoin.
Your argument fails on two points: the definition of the #\( reader macro,
and the defintion of the #\) reader macro. I also note that you do not ever
refer to the #\) reader macro description in your scary Scary Readtable
versions.
You claim that setting the syntax from #\( to #\[ means that the lisp reader
must call this reader macro when it finds a #\[. This is correct.
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."
It looks for a right parenthesis, not a character with the same syntax as a
right parenthesis. That is clear, simple and specific.
You also rest your assertion on the calling of the #\) reader macro. You
are correct that it must be called when a #\] is found but never quote what
that actually is.
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."
Nothing there about "signalling to the left-parenthesis reader macro"
Sorry, but it is that simple. More of your own writing gives another clear
justification for a conforming implimentation to not support your desired
syntax extension:
> =========================================================================
> "1.5.1.4.1 Resolution of Apparent Conflicts in Exceptional Situations"
> =========================================================================
>
> http://www.lispworks.com/reference/HyperSpec/Body/01_eada.htm
>
> " If more than one passage in this specification appears
> to apply to the same situation but in conflicting ways,
> the passage that appears to describe the situation in the
> most specific way (not necessarily the passage that provides
> the most constrained kind of error detection) takes precedence. "
Your argument is involved and references many separate parts of the
standard.
" 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. "
The above is very clear.
> =================================================
> " 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. "
>
> The term *left-parenthesis* refers to the *definition of
> left-parenthesis* or more precise to the
> *syntax-definition-of-left-parenthesis*.
This is your over-extended interpretation and is not correct. It is simply
distorting otherwise clear text.
> Simple Rationale:
> The *syntax-definition-of-left-parenthesis* initiates the reading of a
> list *not* the character *left-parenthesis* itself.
This is an obvious contradiction of the plain and simple original text.
> Conclusion:
> The term *right parenthesis* in the same sentence refers to
> *syntax-definition-of-right-parenthesis* and not to the character
> *right-parenthesis*.
This is not supported by any of your arguments. It is simply distorting
otherwise clear text.
> Simple Backup:
> http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm
> [...] The syntax type of a character in a readtable determines how that
> character is interpreted by the Lisp reader [...]
Yes, and encountering a #\] character will cause the macro function of #\)
to be called as you have shown. It is *not* specified what that function
must do.
>
> I think i've done it.
Sorry, but you havn't, you should accept it and learn. The very
knowledgable and intelligent people who have tried to help you deserve
better treatment than what you have given them in your flat out rejections
of what they have said.
Remember also " `,', ". You said ,' equals nothing. Joe Marshal corrected
you and tested it and you still insisted. You were wrong there too, weren't
you?
Coming to a forum like this and spurning the advice and assistance of
experts is very bad way to try to learn. You have to accept more
responsibility for all the hostility and now the cold shoulder you are
getting. You should also try to avoid spreading confusion by speaking so
confidently before you really know what you are talking about, this is
detrimental to lurking newbies.
I did learn alot about the lisp reader though....
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
ilias
> "ilias" <at_...@pontos.net> wrote in message
> news:alrd14$58$1...@usenet.otenet.gr...
>
>>ilias wrote:
>>
>>>------------------------------------------------
>>>20 lines shortform
>>>------------------------------------------------
>>
>>i make a 20 lines shortform.
>>
>>is here really *not one* person, which has the gentleness
>>to respond to this assertion?
>
> ilias, you have had *many* people respond to your assertion.
This is wrong.
Many responses of savages.
Some responses from people.
> You have not
> had the "gentleness" to understand what they have written.
This is wrong.
There are mostly re-rejoinders in #V0.5.
I've additionally responded *directly* to 3 of the older responses
whilst inserting my rationales from #V0.5 in the relevant places.
You'll see, that i've noticed the rejoinders.
>>now, where i've spent very much time to clarify my words and my
>>argumentation-lines.
>>
>>now, where it is easy for the reader to read-trough?
>>
>>This is c.l.l.
>>
>>Where are the scientists?
>>
>>These, who have science in their heart.
>>
>>Teach. Learn. Impeach. Claim. Proof. Rejoin.
>
> Your argument fails on two points: the definition of the #\( reader macro,
> and the defintion of the #\) reader macro.
Now you pick fragments of the whole work and comment it.
please show me the point where i fail, directly .
> I also note that you do not ever
> refer to the #\) reader macro description in your scary Scary Readtable
> versions.
simple: it is underspecified. infromation not relevant for this stage.
raises only confusion. see yourself:
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). "
but this here is more clear:
---------------------------------------------------------------------------
*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 #V0.5 for derivation
---------------------------------------------------------------------------
Should I clarify in the document what the "specialized parsing behavior"
of the right-parenthesis is?
And i maybe quote the #\)-reader-macro description.
> You claim that setting the syntax from #\( to #\[ means that the lisp reader
> must call this reader macro when it finds a #\[. This is correct.
> 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."
>
> It looks for a right parenthesis, not a character with the same syntax as a
> right parenthesis. That is clear, simple and specific.
I invest 100+ hours to work-out and write an argumentation-line and now
you came here, ignore *fully* my argumentation-line and simply state this?
I don't know which sense this makes, when you start the game from the
beginning.
This makes no sense, except of exhausting me.
Why don't you pick the document #V0.5 and disproof *any* of the
statements which are there?
There are many.
Definitions.
Generalizations.
Concretizations.
Rationales 1 - 3.
Claims 1 - 3.
Where is my error?
Are every 3 claims wrong?
Is my terminology unclear or wrong?
Reply to the document.
Disproof claim 1, 2, 3.
Or confirm claim 1, 2 and disproof claim 3.
Should i change a little the style?
Please be so kindly and respond directly to the document.
But i'll try to answer you here.
> You also rest your assertion on the calling of the #\) reader macro. You
> are correct that it must be called when a #\] is found but never quote what
> that actually is.
You are right.
I should clarify what "set-syntax-from-char" copies.
> 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."
>
> Nothing there about "signalling to the left-parenthesis reader macro"
You don't find all the definitions about one entity in one point in the
specs. Look here:
---------------------------------------------------------------------------
*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 #V0.5 for derivation
---------------------------------------------------------------------------
It is a simple logical conclusion, which i've not written down to reduce
(the possible resulting) complexity of the discussion.
> Sorry, but it is that simple. More of your own writing gives another clear
> justification for a conforming implimentation to not support your desired
> syntax extension:
i don't think so.
>
>>=========================================================================
>>"1.5.1.4.1 Resolution of Apparent Conflicts in Exceptional Situations"
>>=========================================================================
>>
>>http://www.lispworks.com/reference/HyperSpec/Body/01_eada.htm
>>
>>" If more than one passage in this specification appears
>>to apply to the same situation but in conflicting ways,
>>the passage that appears to describe the situation in the
>>most specific way (not necessarily the passage that provides
>>the most constrained kind of error detection) takes precedence. "
>
> Your argument is involved and references many separate parts of the
> standard.
The right-parenthesis is involved in many 'separate parts' of the
standard. So is my argument.
It references the *right-parenthesis*!
its *syntax*
its *reader-macro-function*
its *parsing behaviour*
---------------------------------------------------------------------------
*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 #V0.5 for derivation
---------------------------------------------------------------------------
>
> " 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. "
>
> The above is very clear.
The above paragraph cannot supersede the three Rationales i've derived
out of the specs.
---------------------------------------------------------------------------
END OF IN CONTEXT REPLY
---------------------------------------------------------------------------
The following texts are not relevant to the Rationales and the claims.
I'll avoid commenting, to avoid further increase of complexity.
I've made the statements to show that the definition of ( is unprecise.
Thats the reason why I wrote *Simple* Rationale.
I could analyze and proof this, but i loose to much time. It makes no
sense if i make this work alone and without feedback.
It was wrong to insert this in V0.5. I had better wait for the replies.
>>=================================================
>>" 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. "
>>
>>The term *left-parenthesis* refers to the *definition of
>>left-parenthesis* or more precise to the
>>*syntax-definition-of-left-parenthesis*.
>
> This is your over-extended interpretation and is not correct. It is simply
> distorting otherwise clear text.
This maybe.
but this is *not* the main argumentation-line, which you've not
disproofed directly.
>>Simple Rationale:
>>The *syntax-definition-of-left-parenthesis* initiates the reading of a
>>list *not* the character *left-parenthesis* itself.
>
> This is an obvious contradiction of the plain and simple original text.
This maybe.
but this is *not* the main argumentation-line, which you've not
disproofed directly.
>>Conclusion:
>>The term *right parenthesis* in the same sentence refers to
>>*syntax-definition-of-right-parenthesis* and not to the character
>>*right-parenthesis*.
>
> This is not supported by any of your arguments. It is simply distorting
> otherwise clear text.
This maybe.
but this is *not* the main argumentation-line, which you've not
disproofed directly.
>>Simple Backup:
>>http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm
>>[...] The syntax type of a character in a readtable determines how that
>>character is interpreted by the Lisp reader [...]
>
> Yes, and encountering a #\] character will cause the macro function of #\)
> to be called as you have shown. It is *not* specified what that function
> must do.
---------------------------------------------------------------------------
*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 #V0.5 for derivation
---------------------------------------------------------------------------
but this is *not* the main argumentation-line, which you've not
disproofed directly.
>>I think i've done it.
>
> Sorry, but you havn't, you should accept it and learn.
didaktically.
rejected.
> The very
> knowledgable and intelligent people
knowledgable and intelligent people.
control of egoism.
weakness.
savages.
> who have tried to help you deserve
> better treatment than what you have given them in your flat out rejections
> of what they have said.
action.
reaction.
> Remember also " `,', ". You said ,' equals nothing. Joe Marshal corrected
> you and tested it and you still insisted. You were wrong there too, weren't
> you?
Out of context.
Please write in the other topic.
> Coming to a forum like this and spurning the advice and assistance of
> experts is very bad way to try to learn.
didaktically.
rejected.
> You have to accept more
I have to became part of the falling rain.
> responsibility for all the hostility and now the cold shoulder you are
> getting.
The Scary Readtable.
Scare.
Raises coldness.
> You should also try to avoid spreading confusion by speaking so
> confidently before you really know what you are talking about, this is
> detrimental to lurking newbies.
The Pressure of The Group.
A member is back.
A savage?
> I did learn alot about the lisp reader though....
"The Scary Readtable V0.5"
Open your mind.
learn more.
ilias
Definitions, derivation, the text-replacements, general definitions,
writing-style etc.
Which is the notation usually used by e.g. standards-organizations?
e.g "{}" for marking an altered text (where the specialized words are
inserted, e.g.
{ID1}{left-parenthesis}
e.g.: i've stated: *definition a)* although it is not the *direct* text
of the standard-document. How is this called? "derived definition"?
"derived specialized definition"? etc.
I'd like to write a document with clear terminology.
If you prefere, you can sent me something via email. I learn very quick
& easy from examples. but please only if you have *concrete* knowledge
or *concrete* pointers.
--------------------------------------------------------------------
20 lines shortform
--------------------------------------------------------------------
*Claim* (shortform, see full code below for details):
An ANSI Conforming Common Lisp implementation *must* execute:
(set-syntax-from-char #\] #\) ) ; => T
(set-syntax-from-char #\[ #\( ) ; => T
[+ 3 2] ; => 5
*Derived Definitions* (shortforms, see sections [derivation <x>] for
detailed derivations):
The standard document defines explicitly[should change this sentence]:
*Derived Definition 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."
*Derived Definition b)* - see section [derivation b]
"[...] Upon encountering a *right-parenthesis* the *function READ* calls
the *right-parenthesis-reader macro function*"
*Derived Definition c)* - see section [derivation c]
" A *right-parenthesis* has an associated function called a reader macro
function that implements its specialized parsing behavior. [...] "
--------------------------------------------------------------------
;;;;----------------------------------------------------------------
;;;; The Scary Readtable #V0.6 - ilias - 2002-09-25
;;;;----------------------------------------------------------------
;;; ( ) => [ ] - with CommonLisp conforming code
;;; definitive starting state
;;; activate a fresh standard-readtable
(copy-readtable nil *readtable*)
;;; (copy-readtable nil) creates a fresh standard-readtable
(setq *scary-readtable* (copy-readtable nil) )
;;; activate *scary-readtable*
;;; notice the direction: from-readtable -> to-readtable
(copy-readtable *scary-readtable* *readtable*) ; activates readtable
;;; following code modifies the *scary-readtable*
(set-syntax-from-char #\] #\) ) ;
(set-syntax-from-char #\[ #\( ) ;
;;; syntax is now non-conforming (but legal)
(+ 3 2) ; => 5
[+ 3 2] ; => 5 [the main point]
(eql (get-macro-character #\() (get-macro-character #\[) ) ; =>T
(eql (get-macro-character #\)) (get-macro-character #\]) ) ; =>T
;;; the char-code muste be still different
(eql #\) #\] ) ;;=> nil
(eql #\( #\[ ) ;;=> nil
(copy-readtable nil *readtable*) ; restore standard-syntax
;;; syntax is conforming again
(+ 3 2) ; => 5
[+ 3 2] ; [original behaviour], some error
(eql (get-macro-character #\() (get-macro-character #\[) ) ; => nil
(eql (get-macro-character #\)) (get-macro-character #\]) ) ; => nil
(eql #\) #\] ) ;;=> nil
(eql #\( #\[ ) ;;=> nil
;;;-----------------------------------------------------------------
=====================================================================
[derivations]:
=====================================================================
---------------------------------------------------------------------
*initial definitions* (ID):
---------------------------------------------------------------------
---------------------------------------------------------------------
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
[...] "
=====================================================================
{ID1} => *Right-Parenthesis* is defined as *macro character*.
=====================================================================
---------------------------------------------------------------------
http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm
"[...] ) terminating macro char [...] "
=====================================================================
{ID2} => *Right-Parenthesis* is defined as *terminating* macro character
=====================================================================
---------------------------------------------------------------------
http://www.lispworks.com/reference/HyperSpec/Body/26_glo_l.htm#lisp_reader
"Lisp reader n. Trad. the procedure that parses character
representations of objects from a stream, producing objects. (This
procedure is implemented by the function read.)"
=====================================================================
{ID3} => The *Lisp reader* is defined to be implemented by the *function
READ*
=====================================================================
---------------------------------------------------------------------
The *specialized parsing behavior* of the right-parenthesis
---------------------------------------------------------------------
right-parenthesis is underspecified:
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 concrete definition is in the *left-parenthesis* definition.
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.[...]
=====================================================================
{ID4} => the *specialized parsing behaviour* of the *right-parenthesis*
is *terminating reading of a list*
=====================================================================
---------------------------------------------------------------------
*[derivation a]*
---------------------------------------------------------------------
*The general definition of terminating macro characters:*
http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
4th paragraph, at the end:
"[...] A *terminating macro character* terminates any token, and *its*
associated reader macro function is called no matter where the
*character* appears. [...]"
ID1 => *Right-Parenthesis* is defined as *macro character*.
ID2 => *Right-Parenthesis* is defined as *terminating macro character*
=====================================================================
" A *right-parenthesis* terminates any token, and *the*
*right-parenthesis reader macro function* is called no matter where the
*right-parenthesis* appears."
=====================================================================
---------------------------------------------------------------------
*[derivation b]*
---------------------------------------------------------------------
*The general definition of the macro characters:*
http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
3rd paragraph:
"[...] Upon encountering a *macro character*, the *Lisp reader* calls
*its reader macro function*[...]
[...] Examples of macro characters are backquote, single-quote,
left-parenthesis, and right-parenthesis. [...]"
ID1 => *Right-Parenthesis* is defined as *macro character*.
ID3 => The *Lisp reader* is defined to be implemented by the *function READ*
=====================================================================
"[...] Upon encountering a *right-parenthesis* the *function READ* calls
*the right-parenthesis reader macro function*"
=====================================================================
---------------------------------------------------------------------
*[derivation c]*
---------------------------------------------------------------------
*The general definition of the macro characters:*
http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
2nd paragraph
" A *macro character* has an associated function called a reader macro
function that implements *its specialized parsing behavior*. An
association of this kind can be established or modified under control of
a conforming program by using the functions set-macro-character and
set-dispatch-macro-character."
ID1 => *Right-Parenthesis* is defined as *macro character*.
ID4 => the *specialized parsing behaviour* of the *right-parenthesis* is
*terminating reading of a list*
=====================================================================
" A *right-parenthesis* has an associated function called a reader macro
function that implements *"terminating reading of a list"*. [...] "
=====================================================================
(set-syntax-from-char #\] #\) ) ; => T
(set-syntax-from-char #\[ #\( ) ; => T
the above lines copy the syntax-definitions of () to [].
everything would be clear, if there were not...
---------------------------------------------------------------------
*The definition of set-syntax-from-char:*
[Remark: the text in the specs refers to {} but can be applied identical
to the [] pair, which has been chosen for better visibility ]
http://www.lispworks.com/reference/HyperSpec/Body/f_set_sy.htm
" 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."
"[..] because the *definition* always looks[...]" refers to the
definition of left-parenthesis:
---------------------------------------------------------------------
*The definition of left-parenthesis:*
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. "
---------------------------------------------------------------------
*The definition of set-syntax-from-char:*
depends on the
*The definition of left-parenthesis:*
We take this *one* definition, and go for...
=========================================================================
"1.5.1.4.1 Resolution of Apparent Conflicts in Exceptional Situations"
=========================================================================
http://www.lispworks.com/reference/HyperSpec/Body/01_eada.htm
" If more than one passage in this specification appears to apply to the
same situation but in conflicting ways, the passage that appears to
describe the situation in the most specific way (not necessarily the
passage that provides the most constrained kind of error detection)
takes precedence. "
=========================================================================
The passages under [Derived Definition a,b,c] describe the situation in
the most specific way.
They define explicitly and undoubtable in different locations of the
specification a central part of the Common Lisp Design:
The reader and the reader-macro-characters (to which right parenthesis
belongs).
Whereas *The definition of left-parenthesis:* is unspecific.
To supercede the *whole* general definitions [Definition a,b,c and many
others in the specs] the passage about right-parenthesis must include an
explicit superceding statement in its definition.
This is not the case.
=========================================================================
END
=========================================================================
-
The following is for clarification reasons only.
It demostrates how fuzzy this 'definition' of left-parenthesis is.
[rejoinder a]
" 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. "
The term *left-parenthesis* refers to the *definition of
left-parenthesis* or more precise to the
*syntax-definition-of-left-parenthesis*.
Simple Rationale:
The *syntax-definition-of-left-parenthesis* initiates the reading of a
list *not* the character *left-parenthesis* itself.
Simple Backup:
You can copy the syntaxdefinition to [. After that [ behaves like a (
when found in the input-stream.
Simple Conclusion:
The term *right parenthesis* in the same sentence refers to
*syntax-definition-of-right-parenthesis* and not to the character
*right-parenthesis*.
-------------------------------------------------------------------------
Please let me know your test results.
I cannot reach unix-versions / MAC-Versions.
====================================================================
#V0.6 after a long break, see forum discussion
#V0.5 after lots of silence, see forum 'discussion'
http://groups.google.com/groups?selm=alot2c$pkv$1...@usenet.otenet.gr
#V0.4 after some attacks to my person, see forum 'discussion'
http://groups.google.com/groups?selm=3D7BFA52...@pontos.net
#V0.3 after many comments, see forum discussion
http://groups.google.com/groups?selm=3D795720...@pontos.net
#V0.2 after few comments, see forum discussion
ilias
it would helped me much more, if you had sent me an answer to this here
(information i have requested) instead of telling me thing about my
*personal* style of writing in the news (information i have not requested).
this is simply ungentle if not rude.
of course you're free to correct your fault.
ilias
LISP - The Scary Readtable - () => {} [#V0.6]
http://groups.google.com/groups?selm=amsq4a$cra$1...@usenet.otenet.gr
ilias
LISP - The Scary Readtable - () => {} [#V0.5]
http://groups.google.com/groups?selm=alot2c$pkv$1...@usenet.otenet.gr