The
(mapc #'(lambda (char) (set-macro-character char (get-macro-character #\))))
'(#\] #\}))
is common enough.
Does the READ-RIGHT-PAREN do something ? Are the settings above needed ?
If so, what are the benefits ? What else should be done after READ-DELIMITED-LIST ?
--
Vladimir Zolotykh
* Vladimir Zolotykh <······@eurocom.od.ua>
| The
: [faulty code]
| is common enough.
Some bugs are common. Why do you think this one in particular is not a bug?
See `set-syntax-from-char�.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Vladimir Zolotykh wrote:
> The
>
> (mapc #'(lambda (char) (set-macro-character char (get-macro-character #\))))
> '(#\] #\}))
novice simplification:
(set-macro-character #\] (get-macro-character #\) )
(set-macro-character #\} (get-macro-character #\) )
> is common enough.
>
> Does the READ-RIGHT-PAREN do something ?
READ-RIGHT-PAREN: the reader-macro-function of #\)
i *must*:
·················································@usenet.otenet.gr
> Are the settings above needed ?
no
> If so, what are the benefits ?
http://www.lispworks.com/reference/HyperSpec/Body/f_rd_del.htm#read-delimited-list
" read-delimited-list is intended for use in implementing reader macros.
Usually it is desirable for char to be a terminating macro character so
that it can be used to delimit tokens; however, read-delimited-list
makes no attempt to alter the syntax specified for char by the current
readtable. The caller must make any necessary changes to the readtable
syntax explicitly."
>What else should be done after READ-DELIMITED-LIST ?
rewrite it.
"Vladimir Zolotykh" <······@eurocom.od.ua> ha scritto nel messaggio ······················@eurocom.od.ua...
> The
>
> (mapc #'(lambda (char) (set-macro-character char (get-macro-character #\))))
> '(#\] #\}))
>
> is common enough.
>
> Does the READ-RIGHT-PAREN do something ? Are the settings above needed ?
Usually, #\) has a reader macro associated to it that just signals
an error with a message of "close paren found at top level".
> If so, what are the benefits ? What else should be done after READ-DELIMITED-LIST ?
Copying this macro to other closing delimiter just copies this
error signalling behaviour to them. This is not guaranted, but
is a reasonable thing to expect from an implementation.
P.
Pierpaolo BERNARDI wrote:
> "Vladimir Zolotykh" <······@eurocom.od.ua> ha scritto nel messaggio ······················@eurocom.od.ua...
>
>>The
>>
>>(mapc #'(lambda (char) (set-macro-character char (get-macro-character #\))))
>> '(#\] #\}))
>>
>>is common enough.
>>
>>Does the READ-RIGHT-PAREN do something ? Are the settings above needed ?
>
>
> Usually, #\) has a reader macro associated to it that just signals
> an error with a message of "close paren found at top level".
this is not true for an ANSI Conforming Common Lisp immplementation:
>>If so, what are the benefits ? What else should be done after READ-DELIMITED-LIST ?
>
> Copying this macro to other closing delimiter just copies this
> error signalling behaviour to them. This is not guaranted, but
> is a reasonable thing to expect from an implementation.
not guaranted, not usable.
however:
ANSI Conforming Common Lisp immplementation:
--------------------------------------------------------------------
*Rationale c)* - see section [derivation c]
" A *right-parenthesis* has an associated function called a reader macro
function that implements its specialized parsing behavior. [...] "
--------------------------------------------------------------------
·················································@usenet.otenet.gr
"ilias" <·······@pontos.net> ha scritto nel messaggio ·················@usenet.otenet.gr...
> Pierpaolo BERNARDI wrote:
> > "Vladimir Zolotykh" <······@eurocom.od.ua> ha scritto nel messaggio ······················@eurocom.od.ua...
> >
> >>The
> >>
> >>(mapc #'(lambda (char) (set-macro-character char (get-macro-character #\))))
> >> '(#\] #\}))
> >>
> >>is common enough.
> >>
> >>Does the READ-RIGHT-PAREN do something ? Are the settings above needed ?
> >
> >
> > Usually, #\) has a reader macro associated to it that just signals
> > an error with a message of "close paren found at top level".
>
> this is not true for an ANSI Conforming Common Lisp immplementation:
Uh? The CL spec says #\) is invalid, so a conforming implementation
can do whatever it likes.
> >>If so, what are the benefits ? What else should be done after READ-DELIMITED-LIST ?
> >
> > Copying this macro to other closing delimiter just copies this
> > error signalling behaviour to them. This is not guaranted, but
> > is a reasonable thing to expect from an implementation.
>
> not guaranted, not usable.
It is not guaranted that (CONS 'A 'B) will not signal an error,
so CONS is not usable.
> however:
>
> ANSI Conforming Common Lisp immplementation:
>
> --------------------------------------------------------------------
>
> *Rationale c)* - see section [derivation c]
> " A *right-parenthesis* has an associated function called a reader macro
> function that implements its specialized parsing behavior. [...] "
Where this crap comes from?
P.
Pierpaolo BERNARDI wrote:
> "ilias" <·······@pontos.net> ha scritto nel messaggio ·················@usenet.otenet.gr...
>>Pierpaolo BERNARDI wrote:
>>>"Vladimir Zolotykh" <······@eurocom.od.ua> ha scritto nel messaggio ······················@eurocom.od.ua...
...
>>>>Does the READ-RIGHT-PAREN do something ? Are the settings above needed ?
>>>
>>>Usually, #\) has a reader macro associated to it that just signals
>>>an error with a message of "close paren found at top level".
>>this is not true for an ANSI Conforming Common Lisp immplementation:
> Uh? The CL spec says #\) is invalid, so a conforming implementation
> can do whatever it likes.
see below.
>>>>If so, what are the benefits ? What else should be done after READ-DELIMITED-LIST ?
>>>Copying this macro to other closing delimiter just copies this
>>>error signalling behaviour to them. This is not guaranted, but
>>>is a reasonable thing to expect from an implementation.
>>not guaranted, not usable.
> It is not guaranted that (CONS 'A 'B) will not signal an error,
> so CONS is not usable.
faulty generalisation.
>>however:
>>
>>ANSI Conforming Common Lisp immplementation:
>>--------------------------------------------------------------------
>>*Rationale c)* - see section [derivation c]
>>" A *right-parenthesis* has an associated function called a reader macro
>>function that implements its specialized parsing behavior. [...] "
>
> Where this crap comes from?
form the link you've omitted whilst quoting the above text:
--------------------------------------------------------------------
·················································@usenet.otenet.gr
"ilias" <·······@pontos.net> ha scritto nel messaggio ·················@usenet.otenet.gr...
> Pierpaolo BERNARDI wrote:
> > "ilias" <·······@pontos.net> ha scritto nel messaggio ·················@usenet.otenet.gr...
> >>Pierpaolo BERNARDI wrote:
> >>>"Vladimir Zolotykh" <······@eurocom.od.ua> ha scritto nel messaggio ······················@eurocom.od.ua...
> ...
> >>>>Does the READ-RIGHT-PAREN do something ? Are the settings above needed ?
> >>>
> >>>Usually, #\) has a reader macro associated to it that just signals
> >>>an error with a message of "close paren found at top level".
> >>this is not true for an ANSI Conforming Common Lisp immplementation:
> > Uh? The CL spec says #\) is invalid, so a conforming implementation
> > can do whatever it likes.
>
> see below.
What?
> >>however:
> >>
> >>ANSI Conforming Common Lisp immplementation:
> >>--------------------------------------------------------------------
> >>*Rationale c)* - see section [derivation c]
> >>" A *right-parenthesis* has an associated function called a reader macro
> >>function that implements its specialized parsing behavior. [...] "
> >
> > Where this crap comes from?
>
> form the link you've omitted whilst quoting the above text:
>
> --------------------------------------------------------------------
> ·················································@usenet.otenet.gr
Which is a link to something you wrote.
Where *that* crap comes from?
P.
Pierpaolo BERNARDI wrote:
> "ilias" <·······@pontos.net> ha scritto nel messaggio ·················@usenet.otenet.gr...
>>Pierpaolo BERNARDI wrote:
>>>"ilias" <·······@pontos.net> ha scritto nel messaggio ·················@usenet.otenet.gr...
>>>>Pierpaolo BERNARDI wrote:
>>>>>"Vladimir Zolotykh" <······@eurocom.od.ua> ha scritto nel messaggio ······················@eurocom.od.ua...
>>>>
>>...
>>>>>>Does the READ-RIGHT-PAREN do something ? Are the settings above needed ?
>>>>>Usually, #\) has a reader macro associated to it that just signals
>>>>>an error with a message of "close paren found at top level".
>>>>this is not true for an ANSI Conforming Common Lisp immplementation:
>>>Uh? The CL spec says #\) is invalid, so a conforming implementation
>>>can do whatever it likes.
>>see below.
> What?
link
>>>>however:
>>>>ANSI Conforming Common Lisp immplementation:
>>>>--------------------------------------------------------------------
>>>>*Rationale c)* - see section [derivation c]
>>>>" A *right-parenthesis* has an associated function called a reader macro
>>>>function that implements its specialized parsing behavior. [...] "
>>>Where this crap comes from?
>>form the link you've omitted whilst quoting the above text:
>>--------------------------------------------------------------------
>>·················································@usenet.otenet.gr
>
> Which is a link to something you wrote.
> Where *that* crap comes from?
the crap comes from the online version of the ANSI Common Lisp specs.
replace simply *right-parenthesis* with *macro-character*, then you have
original text.
"ilias" <·······@pontos.net> ha scritto nel messaggio ·················@usenet.otenet.gr...
> >>>>>Usually, #\) has a reader macro associated to it that just signals
> >>>>>an error with a message of "close paren found at top level".
> >>>>this is not true for an ANSI Conforming Common Lisp immplementation:
> >>>Uh? The CL spec says #\) is invalid, so a conforming implementation
> >>>can do whatever it likes.
I was wrong on this. The spec mandates that an error must be signaled.
> >>see below.
> > What?
> link
> the crap comes from the online version of the ANSI Common Lisp specs.
> replace simply *right-parenthesis* with *macro-character*, then you have
> original text.
If you change pieces at random, then it is not the standard.
You say:
>>>>" A *right-parenthesis* has an associated function called a reader macro
>>>>function that implements its specialized parsing behavior. [...] "
The "specialized parsing behavior" of ) is mandated by the
standard to be the signaling of an error of type READER-ERROR.
See 2.4.2 and 2.1.4.3
P.
Pierpaolo BERNARDI wrote:
> "ilias" <·······@pontos.net> ha scritto nel messaggio ·················@usenet.otenet.gr...
>
>
>>>>>>>Usually, #\) has a reader macro associated to it that just signals
>>>>>>>an error with a message of "close paren found at top level".
>>>>>>
>>>>>>this is not true for an ANSI Conforming Common Lisp immplementation:
>>>>>
>>>>>Uh? The CL spec says #\) is invalid, so a conforming implementation
>>>>>can do whatever it likes.
>>>>
>
> I was wrong on this. The spec mandates that an error must be signaled.
>
>
>>>>see below.
>>>
>>>What?
>>
>>link
>
>
>>the crap comes from the online version of the ANSI Common Lisp specs.
>>replace simply *right-parenthesis* with *macro-character*, then you have
>> original text.
>
> If you change pieces at random, then it is not the standard.
this is not a piece-change by random.
right-parenthesis is an macro-character.
you can read all this in the link i've placed.
> You say:
>
>>>>>" A *right-parenthesis* has an associated function called a reader macro
>>>>>function that implements its specialized parsing behavior. [...] "
>>>>
>
> The "specialized parsing behavior" of ) is mandated by the
> standard to be the signaling of an error of type READER-ERROR.
> See 2.4.2 and 2.1.4.3
theres nothing.
2.4.2 says nothing:
http://www.lispworks.com/reference/HyperSpec/Body/02_db.htm
2.1.4.3 sasy nothing:
http://www.lispworks.com/reference/HyperSpec/Body/02_adc.htm
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> The
>
> (mapc #'(lambda (char) (set-macro-character char (get-macro-character #\))))
> '(#\] #\}))
>
> is common enough.
>
> Does the READ-RIGHT-PAREN do something?
It does *something*, but there is no particular defined behavior.
Many Common Lisp implementations have #\) signal an error. At least
one Common Lisp implementation relies on catching a signal from #\) in
order to detect the end of a list.
> Are the settings above needed? If so, what are the benefits?
It depends on what you are doing. If you want #\] and #\} to behave
like #\) (when encountered alone), then you need to do this.
Joe Marshall wrote:
> Vladimir Zolotykh <······@eurocom.od.ua> writes:
>
>>The
>>
>>(mapc #'(lambda (char) (set-macro-character char (get-macro-character #\))))
>> '(#\] #\}))
>>
>>is common enough.
>>
>>Does the READ-RIGHT-PAREN do something?
notes to readers: here in cll and generally in Common Lisp, you've to
learn to interpret.
what?
everything.
e.g. the following statement:
>
> It does *something*, but there is no particular defined behavior.
> Many Common Lisp implementations have #\) signal an error.
this is the general behaviour of Common Lisp implementations.
[which is faulty, but the author does not *know* that or does not
*state* that. maybe politics].
> At least
> one Common Lisp implementation relies on catching a signal from #\) in
> order to detect the end of a list.
this is the correct behaviour of *one* implementation. Xanalys
LispWorks, which implements the #\) exactly as specified in the ANSI
document[1]. [The author does not state, how essential this different
behaviour is. It affects core functionality of the implemetations.]
This is a good example of passing missinformation to newcomers, which
have not the thorough understanding to evaluate the information given.
They are happy if they can fight through this confusing terminology,
which in fact is nothing special.
>
>>Are the settings above needed? If so, what are the benefits?
>
> It depends on what you are doing. If you want #\] and #\} to behave
> like #\) (when encountered alone), then you need to do this.
[1]
ANSI Conforming Common Lisp immplementation:
--------------------------------------------------------------------
*Rationale c)* - see section [derivation c]
" A *right-parenthesis* has an associated function called a reader macro
function that implements its specialized parsing behavior. [...] "
--------------------------------------------------------------------
·················································@usenet.otenet.gr
ilias <·······@pontos.net> writes:
> Joe Marshall wrote:
>
> > Many Common Lisp implementations have #\) signal an error.
>
> this is the general behaviour of Common Lisp implementations.
> [which is faulty, but the author does not *know* that or does not
> *state* that. maybe politics].
The statement that I made is complete, true, and directly relevant to
the original poster's question.
> > At least
> > one Common Lisp implementation relies on catching a signal from #\) in
> > order to detect the end of a list.
This statement is also complete, true, and directly relevant to the
original poster's question.
> This is a good example of passing missinformation to newcomers, which
> have not the thorough understanding to evaluate the information
> given. They are happy if they can fight through this confusing
> terminology, which in fact is nothing special.
I don't think you understand the meaning of the word `misinformation'.
Joe Marshall wrote:
> ilias <·······@pontos.net> writes:
>
>
>>Joe Marshall wrote:
>>
>>
>>>Many Common Lisp implementations have #\) signal an error.
>>
>>this is the general behaviour of Common Lisp implementations.
>>[which is faulty, but the author does not *know* that or does not
>>*state* that. maybe politics].
>
> The statement that I made is complete, true, and directly relevant to
> the original poster's question.
>
>
>>>At least
>>>one Common Lisp implementation relies on catching a signal from #\) in
>>>order to detect the end of a list.
>>
>
> This statement is also complete, true, and directly relevant to the
> original poster's question.
>
>
>>This is a good example of passing missinformation to newcomers, which
>>have not the thorough understanding to evaluate the information
>>given. They are happy if they can fight through this confusing
>>terminology, which in fact is nothing special.
>
>
> I don't think you understand the meaning of the word `misinformation'.
i do.
misinformation.
an example: quoting a message incomplete an comment it thus giving the
reader another context.
i : quoted your message complete and comment it.
you : quoted my message incomplete and comment it.
be happy, human.
"ilias" <·······@pontos.net> wrote in message
·················@usenet.otenet.gr...
> Joe Marshall wrote:
> > It does *something*, but there is no particular defined behavior.
> > Many Common Lisp implementations have #\) signal an error.
> > At least
> > one Common Lisp implementation relies on catching a signal from #\) in
> > order to detect the end of a list.
>
> this is the correct behaviour of *one* implementation. Xanalys
> LispWorks, which implements the #\) exactly as specified in the ANSI
> document[1]. [The author does not state, how essential this different
> behaviour is. It affects core functionality of the implemetations.]
While I personally like this particular behaviour it is not accurate to
claim it is the only correct behaviour. It has been very clearly
established in ilias' "Scary Readtable" threads that this is *not* the only
correct (ie conforming) behaviour.
>
> This is a good example of passing missinformation to newcomers, which
> have not the thorough understanding to evaluate the information given.
ilias is the one who is passing misinformation. Sincere as he may be, he is
still quite wrong.
> ANSI Conforming Common Lisp immplementation:
> --------------------------------------------------------------------
> *Rationale c)* - see section [derivation c]
> " A *right-parenthesis* has an associated function called a reader macro
> function that implements its specialized parsing behavior. [...] "
> --------------------------------------------------------------------
> ·················································@usenet.otenet.gr
A *right-parenthesis* does indeed have an associated reader macro function
that implements its specialized parsing behavior. However, what this
parsing behaviour almost completely unspecified.
http://www.lispworks.com/reference/HyperSpec/Body/02_db.htm
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Coby Beck wrote:
> "ilias" <·······@pontos.net> wrote in message
> ·················@usenet.otenet.gr...
>
>>Joe Marshall wrote:
>>
>>>It does *something*, but there is no particular defined behavior.
>>>Many Common Lisp implementations have #\) signal an error.
>>>At least
>>>one Common Lisp implementation relies on catching a signal from #\) in
>>>order to detect the end of a list.
>>
>>this is the correct behaviour of *one* implementation. Xanalys
>>LispWorks, which implements the #\) exactly as specified in the ANSI
>>document[1]. [The author does not state, how essential this different
>>behaviour is. It affects core functionality of the implemetations.]
>
> While I personally like this particular behaviour it is not accurate to
> claim it is the only correct behaviour. It has been very clearly
> established in ilias' "Scary Readtable" threads that this is *not* the only
> correct (ie conforming) behaviour.
missinformation:
nothing has clearly established.
the rejoinders have stopped, after i placed rejoinders against them.
·················································@usenet.otenet.gr
>>This is a good example of passing missinformation to newcomers, which
>>have not the thorough understanding to evaluate the information given.
>
> ilias is the one who is passing misinformation. Sincere as he may be, he is
> still quite wrong.
of course not.
(set-syntax-from-char #\] #\) ) ; => T
(set-syntax-from-char #\[ #\( ) ; => T
[+ 3 2] ; => *implementation dependent* ???
this is a bad joke. a *very* bad joke.
>>ANSI Conforming Common Lisp immplementation:
>>--------------------------------------------------------------------
>>*Rationale c)* - see section [derivation c]
>>" A *right-parenthesis* has an associated function called a reader macro
>>function that implements its specialized parsing behavior. [...] "
>>--------------------------------------------------------------------
>>·················································@usenet.otenet.gr
hehehe.
now things get funny!!!
a question for the experts.
what is the "parsing specific behaviour of )" ?
try to express it, please.
try to find an expression, so you are 'compatible' with the 'fuzzy standard'
one possible answer:
> A *right-parenthesis* does indeed have an associated reader macro function
> that implements its specialized parsing behavior. However, what this
> parsing behaviour almost completely unspecified.
> http://www.lispworks.com/reference/HyperSpec/Body/02_db.htm
as you sayed, almost completely unspecified.
so?
(paring-specific-behaviour-of #\) ANSI-specs fuzzy)=> do what you want.
*very* funny.
The "parsing specific behaviour of )" is *not* what is missed to be
defined in the above section of the spec.
It is (e.g., free text): to terminate what the "parsing specific
behaviour of (" initiates.
If you *really* need to look for it, you can find it at different places
is the specs, "the parsing specific behaviour of )".
-
i feel agression.
it looks like the specs is intentionally underspecified, to allow
different implementations to 'pass' the 'standard'.
i don't know if this is what the working-group wanted.
If it *is* what they wanted to do, the i say:
NO!
why i say that?
who am i to say that?
what gives me the right to say that?
-
escape.
no chance.
you can't beat.
The Spirit of Lisp.