#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.
Knock 'The Scary Readtable' out.
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')
Note: 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 remarks 'nc' means non-conforming-syntax
;;;-----------------------------------------------------------------
;;; The Scary Readtable #V0.3 - ilias - 2002-09-06
;;;-----------------------------------------------------------------
( ) => [ ] - 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] ;nc => 5
The main arguments that [+ 3 2] *can* but *must not* be executed by a
Conforming Implementation were:
Starting with a paragraph out of set-syntax-from-char:
(Remark: the text in CLHS refers to {} but can be applied identical to
the [] pair, which I've 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."
The definition of ( is as follows:
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. "
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 *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]
I proof this claims:
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.
In the definition of the macro character:
http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
"[...] 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. [...]"
The above paragraph proofs claim 1.
[ *proof 1* : the #\) reader macro *must* be called. ]
"[...] Upon encountering a macro character, the Lisp reader calls its
reader macro function [...]"
The Lisp reader is implemented by the function read:
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.)
Thus the function read encounters the macro character and calls its
reader macro function.
As the #|)-reader macro function must be called (proof 1),
And read is the function which calls its reader macro function,
And read is the function which encounters #\) as a macro char
Read must be used to read #\).
[ *proof 2* : read *is* the function that *must* be used for reading in
the #\) ]
----------------------------------------------------
[ *claim 3* : the #\) reader macro *must* be used to signal its
occurrence to the #\( reader-macro]
I continue this tomorrow.
This is a very draft, unreviewed. But should be valid. I post it so you
can see what happens until now.
Time to sleep.
-
100% pure Juice, Green Apple-Quince, with green tea.
Try it.
On Sat, Sep 07, 2002 at 04:32:16AM +0300, ilias wrote:
> 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.
>
> In the definition of the macro character:
>
> http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
>
> "[...] 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. [...]"
>
http://www.lispworks.com/reference/HyperSpec/Body/02_d.htm
`` If the reader encounters a macro character, then its associated
reader macro function is invoked and may produce an object to be
returned. This function may read the characters following the macro
character in the stream in any syntax and return the object represented
by that syntax.''
The key words here are "read the characters". This is enough to justify
use of READ-CHAR (and consequently, no call of the #\) reader macro).
Also note "in any syntax".
But there is yet another flaw in your logic. A contradiction can be
found in the paragraph you quoted if you arrive at the conclusion that
you did. ``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).'' If
implementations were required to call READ (and not READ-CHAR) then how
could they handle comments? In a comment, no reader-macro functions
should be called, even if a #\) is encountered. READ-CHAR (or some
non-dispatching read function) must be used. The text in a comment may
follow "any syntax".
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> On Sat, Sep 07, 2002 at 04:32:16AM +0300, ilias wrote:
>
>>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.
>>
>>In the definition of the macro character:
>>
>>http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
>>
>>"[...] 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. [...]"
>>
> http://www.lispworks.com/reference/HyperSpec/Body/02_d.htm
>
> `` If the reader encounters a macro character, then its associated
> reader macro function is invoked and may produce an object to be
> returned. This function may read the characters following the macro
> character in the stream in any syntax and return the object represented
> by that syntax.''
>
> The key words here are "read the characters".
> This is enough to justify use of READ-CHAR (and consequently, no call of the #\) reader macro).
> Also note "in any syntax".
This describes reader-macros in general.
There are different reader-macros that do different tasks.
> But there is yet another flaw in your logic. A contradiction can be
> found in the paragraph you quoted if you arrive at the conclusion that
> you did.
>``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).''
> If
> implementations were required to call READ (and not READ-CHAR) then how
> could they handle comments? In a comment, no reader-macro functions
> should be called, even if a #\) is encountered. READ-CHAR (or some
> non-dispatching read function) must be used. The text in a comment may
> follow "any syntax".
http://www.lispworks.com/reference/HyperSpec/Body/02_dd.htm
" A semicolon introduces characters that are to be ignored, such as
comments. The semicolon and all characters up to and including the next
newline or end of file are ignored. "
As the characters has to be ignored calling READ is *not* allowed.
There is no contradiction.
On Sat, Sep 07, 2002 at 03:19:09PM +0300, ilias wrote:
> Matthew Danish wrote:
> > On Sat, Sep 07, 2002 at 04:32:16AM +0300, ilias wrote:
> >
> >>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.
> >>
> >>In the definition of the macro character:
> >>
> >>http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
> >>
> >>"[...] 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. [...]"
> >>
>
> > http://www.lispworks.com/reference/HyperSpec/Body/02_d.htm
> >
> > `` If the reader encounters a macro character, then its associated
> > reader macro function is invoked and may produce an object to be
> > returned. This function may read the characters following the macro
> > character in the stream in any syntax and return the object represented
> > by that syntax.''
> >
>
> > The key words here are "read the characters".
> > This is enough to justify use of READ-CHAR (and consequently, no call of the #\) reader macro).
> > Also note "in any syntax".
>
> This describes reader-macros in general.
> There are different reader-macros that do different tasks.
Right, but they are allowed to parse ANY syntax they wish. This
includes the standard macro characters. The left-parenthesis has a
definition given in the spec, so then this argument narrows down to the
behavior described by that definition and the general behavior of macro
characters.
The quote I used above states "IF the reader encounters a macro
character, THEN its associated reader macro function is invoked..."
The second half of the quote justifies the use of functions other than
READ to parse the arbitrary syntax following the macro character.
The function that should be used for #\( is described in Chapter 2.4.1
``read is called recursively to read successive objects until a right
parenthesis is found in the input stream.''
What this sentence says is that READ must be used to read successive
objects but it does not state that READ must be used to read the #\).
How the #\) is found in the input stream is left to the implementation.
Therefore it is perfectly valid behavior to use READ-CHAR/UNREAD-CHAR
to look for the #\).
>
> > But there is yet another flaw in your logic. A contradiction can be
> > found in the paragraph you quoted if you arrive at the conclusion that
> > you did.
>
> >``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).''
>
> > If
> > implementations were required to call READ (and not READ-CHAR) then how
> > could they handle comments? In a comment, no reader-macro functions
> > should be called, even if a #\) is encountered. READ-CHAR (or some
> > non-dispatching read function) must be used. The text in a comment may
> > follow "any syntax".
>
> http://www.lispworks.com/reference/HyperSpec/Body/02_dd.htm
> " A semicolon introduces characters that are to be ignored, such as
> comments. The semicolon and all characters up to and including the next
> newline or end of file are ignored. "
>
> As the characters has to be ignored calling READ is *not* allowed.
>
> There is no contradiction.
That IS precisely the contradiction.
Your claim is that "the #\) reader-macro must be called" and is based on
the assumption that READ will be always used to read by macro
character functions. But that would make it impossible for the #\;
reader-macro function to be implemented.
Here is yet another weakness in your argument:
Your first claim is that "the #\) reader-macro must be called" and is
justified by a paragraph which states
``Upon encountering a macro character, the Lisp reader calls its
reader macro function...''
Let us rephrase this into a more straightforward logical proposition:
Proposition A: "the Lisp reader encounters a macro character"
Proposition B: "the Lisp reader calls the reader macro function for that
character"
The sentence in the specification states that
IF A THEN B (also written A -> B).
But you claim that "the #\) reader-macro function must be called"
(You also base this claim on the fact that #\) is a macro character,
which no one is disputing).
As you can see, the sentence you quoted does not prove your claim.
If we further analyze the sentence with first-order logic:
Predicate A(x): "the Lisp reader encounters a macro character, x"
Predicate B(x): "the macro function for the character, x, is called"
Predicate C(x): "x is a macro character"
Then the sentence in the specification states that
For all x, IF C(x) THEN (IF A(x) THEN B(x))
(also written as Ax.(C(x) -> (A(x) -> B(x))))
In your claim you assert that "the #\) reader-macro function must be
called". In order to prove this claim, you must arrive at B(#\)).
In this case x is #\). C(#\)) is satisfied, so we are left with
(A(#\)) -> B(#\))). You can only arrive at B(#\)) by proving A(#\)).
Namely, you must prove that it is indeed the Lisp reader which
encounters the macro character #\) before your claim is proven.
So the first claim is still not proven.
Your second claim is that "READ is the function which must be used to
read the #\)".
Given that the Lisp reader and the function READ are one and the same,
this claim, if proven, would prove A(#\)) and thus would prove claim 1.
ilias wrote:
> "[...] Upon encountering a macro character, the Lisp reader calls its
> reader macro function [...]"
> The Lisp reader is implemented by the function read:
> 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.)
> Thus the function read encounters the macro character and calls its
> reader macro function.
> As the #|)-reader macro function must be called (proof 1),
> And read is the function which calls its reader macro function,
> And read is the function which encounters #\) as a macro char
> Read must be used to read #\).
> [ *proof 2* : read *is* the function that *must* be used for reading in
> the #\) ]
This is a circular argument (since we now know that proof 1 depends on
proof 2): ``As the #\)-reader macro function must be called (proof 1)''
Thus claim 2 is also not proven.
Also, assuming claim 2 and proving claim 1 from it does not work
because you are still left with that dangling assumption, namely that
``READ is the function that *must* be used for reading in the #\)''.
So somehow you must come up with a proof that it is necessary for #\) to
be read in by the Lisp reader AND ONLY the Lisp reader. But we already
know from the standard that other functions than the Lisp reader MAY be
used (``any syntax'', ``read the characters'', my discussion about
chapter 2.4.1 above, comments, etc...). Thus not every #\) that is
encountered may have its reader-macro function called.
Overview:
ilias claim 1: B(#\))
ilias claim 2: A(#\))
The standard states: Ax.(C(x) -> (A(x) -> B(x)))
Substituting #\) for x results in: C(#\)) -> (A(#\) -> B(#\))
The standard also states that C(#\)) is true.
Therefore the standard states that: A(#\)) -> B(#\))
This statement does not support either of ilias's claims.
IF claim 2 is true THEN claim 1 is true. But the proof for claim 2
which ilias presents is dependent on the proof for claim 1. Thus, a
circularity.
--
; 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."
On Sat, Sep 07, 2002 at 11:11:21PM +0300, ilias wrote:
> Matthew Danish wrote:
> > On Sat, Sep 07, 2002 at 03:19:09PM +0300, ilias wrote:
>
> sorry.
>
> complexity.
>
> please reduce.
>
If you can't handle the heat, stop playing with fire. Your argument,
when reduced to unambiguous notation, demonstrates many easy and obvious
flaws. It is only when you phrase them in ambiguous (and poorly
structured) English that they seem to be valid. Many metaphysicists
were also caught in this trap, so don't feel alone.
Complexity cannot always be avoided, so you should be able to handle it.
Dealing with complexity is normal for a computer scientist. It is
intricacy that should be avoided, not complexity. Avoiding complexity
leads to oversimplified systems. (As it is, my counter-proof avoided
much complexity because I knew there was no way you would understand it
with your background. As a result it is oversimplified. I acknowledge
this, but I also find that it expresses the basic idea well enough.)
Java is a good example of a system that attempts to avoid complexity
but suffers a loss of expressiveness as a result. INTERCAL is a good
example of a system that is more intricate than it need be (for the
purpose of writing programs anyway. It is more than adequate for the
purpose of driving people insane).
It is obvious that you haven't had a good background in logic, from the
mistakes in your arguments. I highly recommend that you put your
interest in Lisp on hold for now and learn the basics of modern (past
150 years) logic. For both your sake and ours.
Read about the propositional calculus, predicate, and first-order
logic. Understand the implications of the simple rules you start out
with. Understand the importance of seeking clear, unambiguous
explanations, and how notation can assist you. Understand the
reasoning set forth by people whose training and skills far exceed
yours.
Read books by and about Gottlob Frege, Bertrand Russell, Kurt Godel, and
others. There are numerous texts on logic, and the history of logic.
Your local library should have copies of many.
Then some background on further work done in more specific areas would
greatly assist you in becoming familiar with the context of modern
thought in those areas.
People will take you a lot more seriously if you are capable of
analyzing your own arguments critically. We dislike having to point out
every simple little thing to you. You, as the questioner, should be
doing some work too! Not to mention, people will not be able to
understand your arguments if you cannot phrase them in a grammatically
correct manner. It can be excused if English is not your native
language, but you must make some effort to learn it. You are not
writing poetry here; you should be dealing with logical statements.
Ambiguity is not to be desired.
Apologies for the meta-argument, but it is clear that you need some
guidance.
Return when you are more mature, and it will be a pleasure to debate
with you.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> On Sat, Sep 07, 2002 at 11:11:21PM +0300, ilias wrote:
>
>>Matthew Danish wrote:
>>
>>>On Sat, Sep 07, 2002 at 03:19:09PM +0300, ilias wrote:
>>
>>sorry.
>>
>>complexity.
>>
>>please reduce.
>>
>
>
> If you can't handle the heat, stop playing with fire. Your argument,
> when reduced to unambiguous notation, demonstrates many easy and obvious
> flaws. It is only when you phrase them in ambiguous (and poorly
> structured) English that they seem to be valid. Many metaphysicists
> were also caught in this trap, so don't feel alone.
>
> Complexity cannot always be avoided, so you should be able to handle it.
> Dealing with complexity is normal for a computer scientist. It is
> intricacy that should be avoided, not complexity. Avoiding complexity
> leads to oversimplified systems. (As it is, my counter-proof avoided
> much complexity because I knew there was no way you would understand it
> with your background. As a result it is oversimplified. I acknowledge
> this, but I also find that it expresses the basic idea well enough.)
>
> Java is a good example of a system that attempts to avoid complexity
> but suffers a loss of expressiveness as a result. INTERCAL is a good
> example of a system that is more intricate than it need be (for the
> purpose of writing programs anyway. It is more than adequate for the
> purpose of driving people insane).
>
> It is obvious that you haven't had a good background in logic, from the
> mistakes in your arguments. I highly recommend that you put your
> interest in Lisp on hold for now and learn the basics of modern (past
> 150 years) logic. For both your sake and ours.
>
> Read about the propositional calculus, predicate, and first-order
> logic. Understand the implications of the simple rules you start out
> with. Understand the importance of seeking clear, unambiguous
> explanations, and how notation can assist you. Understand the
> reasoning set forth by people whose training and skills far exceed
> yours.
>
> Read books by and about Gottlob Frege, Bertrand Russell, Kurt Godel, and
> others. There are numerous texts on logic, and the history of logic.
> Your local library should have copies of many.
>
> Then some background on further work done in more specific areas would
> greatly assist you in becoming familiar with the context of modern
> thought in those areas.
>
> People will take you a lot more seriously if you are capable of
> analyzing your own arguments critically. We dislike having to point out
> every simple little thing to you. You, as the questioner, should be
> doing some work too! Not to mention, people will not be able to
> understand your arguments if you cannot phrase them in a grammatically
> correct manner. It can be excused if English is not your native
> language, but you must make some effort to learn it. You are not
> writing poetry here; you should be dealing with logical statements.
> Ambiguity is not to be desired.
>
> Apologies for the meta-argument, but it is clear that you need some
> guidance.
>
> Return when you are more mature, and it will be a pleasure to debate
> with you.
>
I'm very sorry that my words forced you to write all this.
Yes, i'm undereducated.
But i'll learn.
When i am ready.
And this is not yet.
ilias wrote:
[...]
> I'm very sorry that my words forced you to write all this.
>
> Yes, i'm undereducated.
>
> But i'll learn.
>
> When i am ready.
>
> And this is not yet.
ilias,
I am convinced by now that you have very deep psychological problems.
Your stereotypical reactions to people who try to seriously discuss with
you clearly show this. Your off-topic comments about your obviously
problematic relationships with women and other off-topic ramblings, also
in other newsgroups, support my guess. You obviously suffer from, at
least, some kind of neurosis or perhaps even from some kind of trauma.
It is not very likely that your psychological problems will be solved in
any newsgroup because people are usually not trained enough to handle
these issues. I am convinced that you are in need of professional
psychological help by some form of psychotherapy. I don't know where you
live, but if you happen to live in Germany it is very easy to get a
psychotherapy because costs are covered by the public health system. If
you live somewhere else you should still consider asking a doctor about
psychotherapy or similar kinds of treatments. I don't know about cost
coverage in other countries, including Greece.
This is my final statement about this whole issue. I am not interested
in hearing any comments from you about this message, and I will ignore
any posts from you, about any topic, in the near future.
All the best,
Pascal
Pascal Costanza <········@web.de> writes:
> It is not very likely that your psychological problems will be
> solved in any newsgroup because people are usually not trained
> enough to handle these issues.
speak for yourself! we (gonzo) doctors of journalism know how
to handle all issues! nothing a bountiful cocktail of assorted
stimulants taken in a mad dash across the nevada desert in a land
shark can't solve! when the going gets weird...
thi
Pascal Costanza wrote:
> ilias wrote:
> [...]
>
>> I'm very sorry that my words forced you to write all this.
>>
>> Yes, i'm undereducated.
>>
>> But i'll learn.
>>
>> When i am ready.
>>
>> And this is not yet.
>
>
> ilias,
>
> I am convinced by now that you have very deep psychological problems.
> Your stereotypical reactions to people who try to seriously discuss with
> you clearly show this. Your off-topic comments about your obviously
> problematic relationships with women and other off-topic ramblings, also
> in other newsgroups, support my guess. You obviously suffer from, at
> least, some kind of neurosis or perhaps even from some kind of trauma.
>
> It is not very likely that your psychological problems will be solved in
> any newsgroup because people are usually not trained enough to handle
> these issues. I am convinced that you are in need of professional
> psychological help by some form of psychotherapy. I don't know where you
> live, but if you happen to live in Germany it is very easy to get a
> psychotherapy because costs are covered by the public health system. If
> you live somewhere else you should still consider asking a doctor about
> psychotherapy or similar kinds of treatments. I don't know about cost
> coverage in other countries, including Greece.
>
> This is my final statement about this whole issue. I am not interested
> in hearing any comments from you about this message, and I will ignore
> any posts from you, about any topic, in the near future.
>
> All the best,
> Pascal
I'm happy to not met you in 15th century.
Fire is beaty. But not with me in.
Many pain in my life.
That's why i'm strong.
Your words show weakness.
Take care what you write.
The planet is watching.
Your neighbour may too.
ilias wrote:
> http://www.lispworks.com/reference/HyperSpec/Body/02_dd.htm
> " A semicolon introduces characters that are to be ignored, such as
> comments. The semicolon and all characters up to and including the next
> newline or end of file are ignored. "
>
> As the characters has to be ignored calling READ is *not* allowed.
>
> There is no contradiction.
clarification: of course it is allowed to read the chars with e.g.
read-char.
It is not allowed to use READ, as READ would call their
reader-macro-functions.
now:
i loose a little my motivation. This is due to the anoyance of a
moskito, which has [? making hole with a needle] me three or four times
in my feet. I cannot locate it. It flys to low.
I think it is the revenge for the UFO i've killed with my espandrillo
yesterday (see subject "LISP - GarbageCollector [off topic]" ).
So it is somehow ok.
Btu if i find it, i'll kill it.
Defense. The natural flow of things.
I think you have noticed, that i've interupted my C++ Project.
I continue now with proof 3.
> Ilias claims :
>
> [ *claim 1* : the #\) reader macro *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]
>
>
> I proof this claims:
>
>
> 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.
>
> In the definition of the macro character:
>
> http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
>
> "[...] 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. [...]"
>
> The above paragraph proofs claim 1.
>
> [ *proof 1* : the #\) reader macro *must* be called. ]
To prevent the argument, that at the end of a list "(+ a b)", the call
is not neccessary:
http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm
"[...] ) terminating macro char [...] "
=> ) is defined as "terminating macro char"
http://www.lispworks.com/reference/HyperSpec/Body/02_add.htm
end of 4th paragraph:
"[...] A terminating macro character terminates any token, and its
associated reader macro function is called no matter where the character
appears. [...]"
=> The #\)-reader-macro-function is called no matter where the #\)
character appears.
i've simplyfied the proofs 1 & 2 again.
now it must be very clear:
[...]
(set-syntax-from-char #\] #\) ) ; => T
(set-syntax-from-char #\[ #\( ) ; => T
[+ 3 2] ;nc => 5
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]
I proof this claims:
*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. ]
claim 3 still unproofed.
subconscious is fast.
and proofs for me.
passing to conscious.
needs time to do.
must read the specs.
with foreground open.
but so many facts.
and so little time.