LISP - [SPECS ERR] - Backquote - please confirm.
ilias
I announce a fault that i've found in the specifications.
At least i think so.
Please validate this, so more users can benefit from this information.
Is there any place where clarifications / corrections of the
specifications were collected?
--------------------------------------------------------------------
The standard-document states:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]"
=> "the *innermost* backquoted form *should be* expanded first"
=> " if several commas occur in a row, the *leftmost* comma belongs to
the *innermost* backquote"
This definition is false.
------------------------------------------------------------------------
Macro for test / demonstration purposes
(defmacro abbrev (short long) ; [1]
`(defmacro ,short (&rest args)
`(,',long ,@args))) ;
------------------------------------------------------------------------
Applying the standard definition manually to the abbrev-macro:
(abbrev df defun)
[innermost first, left commas first]
`(defmacro ,short (&rest args)
(,long ,@args )))
^ .........this evaluates correctly (,',long => ,long
^... here we would get an error, as 'args' is not available.
--------------------------------------------------------------------
Verifying with evaluations:
(macroexpand-1 '(abbrev df defun))
LispWorks:
=> (DEFMACRO DF (&REST ARGS) (SYSTEM::BQ-LIST* (QUOTE DEFUN) ARGS))
manual 'translation':
(DEFMACRO DF (&REST ARGS) `(,'DEFUN ,@ARGS))
Allegro:
=> (DEFMACRO DF (&REST ARGS) (EXCL::BQ-CONS 'DEFUN ARGS))
manual 'translation':
(DEFMACRO DF (&REST ARGS) `(,'DEFUN ,@ARGS))
We see in the processing of both implementations:
- The *outermost* backquoted form is processed first.
- The *innermost* backquoted form is processed partially by the
outermost backquote to evaluate the ,',long to ,'DEFUN.
This confirms: The definition of backquote is false.
--------------------------------------------------------------------
The author meant probably this:
If the backquote syntax is nested, the innermost backquoted form should
be *served*[not expanded] first [with a comma]. This means that if
several commas occur in a row, the leftmost one belongs to the innermost
backquote [and so on].
[naturally, as given by reading in the stream, the outermost backquote
is expanded first.]
(setq d 1 c 'd b 'c a 'b )
`(,a `(,b ,,c)) ; => (b `(c ,d))
|_|__||
|_|________|
the only , prior to a will be processed from the outermost `
the only , prior to b will be processed from the innermost `
the left , prior to c will be processed from the innermost `
the right , prior to c will be processed from the outermost `
--------------------------------------------------------------------
[1]
http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
Page 213
Carlos Ungil
explained it in terms of apples.
> (defmacro abbrev (short long) ; [1]
> `(defmacro ,short (&rest args)
> `(,',long ,@args))) ;
If you expand the inner backquote as explained in the specification you get
(defmacro abbrev (short long)
`(defmacro ,short (&rest args)
(append ;; `(
(list ',long) ;; ,',long
args ;; ,@args
'nil))) ;; ) end of backquote
And expanding the outer backquote (done in two steps):
(defmacro abbrev (short long)
(append ;; `(
(list `defmacro) ;; defmacro
(list short) ;; ,short
(list (append (list short) (list long) nil)) ;; (short long)
(append (list 'append) ;; (append
(list `(list (quote ,long))) ;; (list ',long)
(list 'args) ;; args
(list 'nil) ;; 'nil
'nil) ;; )
'nil)) ;; ) end of backquote
(defmacro abbrev (short long)
(append ;; `(
(list 'defmacro) ;; defmacro
(list short) ;; ,short
(list (append (list short) (list long) nil)) ;; (short long)
(append (list 'append) ;; (append
(list (append (list 'list)
(list (append (list 'quote) (list long) 'nil))
'nil)) ;; (list ',long)
(list 'args) ;; args
'nil ;; 'nil
'nil) ;; )
'nil)) ;; ) end of backquote
It might be wrong, but it seems to work :-)
Even if any detail in my expansion is wrong, I cannot see why do you say
that the definition you quoted is false. In fact I cannot understand what
does "false" mean in this context.
Marco Antoniotti
"Carlos Ungil" <Carlos...@cern.ch> writes:
"false" seems to mean: it works in ways that I do not expect and that
do not correspond to my expectations. (Meaning in Ilias' world).
Now, we are just at the reader and the backquote. Sooner or later
Ilias will get to pathnames. :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Carlos Ungil
(&rest args) was missing in the second expansion, I had expanded (shrot
long) instead
And a (list ...) was lost before an (append ..)
Now it works. Really.
(defmacro abbrev (short long)
(append ;; `(
(list 'defmacro) ;; defmacro
(list short) ;; ,short
(list (append (list '&rest) (list 'args) 'nil)) ;; (&rest args)
(list (append (list 'append) ;; (append
(list (append (list 'list)
(list (append (list 'quote) (list long) 'nil))
'nil)) ;; (list ',long)
(list 'args) ;; args
'nil ;; 'nil
'nil)) ;; )
'nil))
(macroexpand-1 '(abbrev plus +))
;; -> (DEFMACRO PLUS (&REST ARGS) (APPEND (LIST (QUOTE +)) ARGS))
(abbrev plus +)
;; -> PLUS
(plus 1 2)
;; -> 3
Duane Rettig
> comp.lang.lisp
>
> I announce a fault that i've found in the specifications.
>
> At least i think so.
You should stop trying so hard to find fault with the spec, and
start learning how to interpret it. I had no problem interpreting
what you wanted with the code you showed, and it worked fine for me
in Allegro CL:
CL-USER(1): (defmacro abbrev (short long) ; [1]
`(defmacro ,short (&rest args)
`(,',long ,@args)))
ABBREV
CL-USER(2): (abbrev hello goodbye)
HELLO
CL-USER(3): (pprint (macroexpand '(hello 10 20 30)))
(GOODBYE 10 20 30)
CL-USER(4):
There was no error, as you had indicated there was. Perhaps you
called your own macro incorrectly?
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
ilias
> ilias <at_...@pontos.net> writes:
>
>
>>comp.lang.lisp
>>
>>I announce a fault that i've found in the specifications.
>>
>>At least i think so.
>
>
> You should stop trying so hard to find fault with the spec, and
i don't try.
its an automated process.
> start learning how to interpret it.
interpret.
> I had no problem interpreting
> what you wanted with the code you showed, and it worked fine for me
> in Allegro CL:
It worked fine in Allegro/LispWorks to me, too.
>
> CL-USER(1): (defmacro abbrev (short long) ; [1]
> `(defmacro ,short (&rest args)
> `(,',long ,@args)))
> ABBREV
> CL-USER(2): (abbrev hello goodbye)
> HELLO
> CL-USER(3): (pprint (macroexpand '(hello 10 20 30)))
>
> (GOODBYE 10 20 30)
> CL-USER(4):
>
> There was no error, as you had indicated there was. Perhaps you
> called your own macro incorrectly?
No.
I've to clarify the text, that the specs is wrong and not the
implementations.
Espen Vestre
> > You should stop trying so hard to find fault with the spec, and
>
> i don't try.
>
> its an automated process.
It's really a robot :-)!
--
(espen)
Kenny Tilton
ilias wrote:
> Duane Rettig wrote:
>
>> ilias <at_...@pontos.net> writes:
>>
>>
>>> comp.lang.lisp
>>>
>>> I announce a fault that i've found in the specifications.
>>>
>>> At least i think so.
>>
>>
>>
>> You should stop trying so hard to find fault with the spec, and
>
>
> i don't try.
>
> its an automated process.
bzzzt! sarte: you are not free to be not free.
kt
ilias
please validate.
--------------------------------------------------------------------
clarification: the implementation i've tested (LispWorks / Allegro) work
, 'as expected', *not* conforming to the (faulty) specification.
--------------------------------------------------------------------
NESTED BACKQUOTE
--------------------------------------------------------------------
The standard-document states:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]"
=> "the *innermost* backquoted form *should be* expanded first"
This definition is wrong.
------------------------------------------------------------------------
Testing with implementations:
Allegro:
(setq d 1 c 'd b 'c a 'b )
`(,a `(,b ,,c)) ; => (B (EXCL::BQ-LIST B D))
;;; which is same as: (B `(,B ,D))
LispWorks:
`(,a `(,b ,,c)) ; => (B (SYSTEM::BQ-LIST B D))
;;; which is same as: (B `(,B ,D))
We see in the processing of both implementations:
- The *outermost* backquoted form is expanded first (in contradiction to
the specification)
- The *innermost* backquoted form is processed *partially* by the
outermost backquote to evaluate the ,,c => ,D.
This confirms: The definition of backquote is false.
------------------------------------------------------------------------
one could say now:
The specification is correct. The implementors are wrong.
--------------------------------------------------------------------
The 'natural' flow of things will help out.
Naturally (as given by reading in the stream) the outermost backquote is
expanded first.
The Lisp-Reader cannot preview more than *one* char. Thus it is
impossible to detect the existence of the innermost quote to avoid
evaluation of the outermost backquote.
--------------------------------------------------------------------
(setq d 1 c 'd b 'c a 'b )
`(,a `(,b ,,c)) ; => (b `(c ,d))
|_|__||
|_|________|
the only , prior to a will be processed from the outermost `
the only , prior to b will be processed from the innermost `
the left , prior to c will be processed from the innermost `
the right , prior to c will be processed from the outermost `
--------------------------------------------------------------------
The author meant probably this:
If the backquote syntax is nested, the innermost backquoted form should
be *served*[not expanded] first [with a comma]. This means that if
several commas occur in a row, the leftmost one belongs to the innermost
backquote [and so on].
--------------------------------------------------------------------
ilias
...
> Even if any detail in my expansion is wrong, I cannot see why do you say
> that the definition you quoted is false. In fact I cannot understand what
> does "false" mean in this context.
i've simplified & rewritten some parts. see #V0.2
false: not true, wrong.
ilias
> There was a couple of errors.
>
> (&rest args) was missing in the second expansion, I had expanded (shrot
sorry.
i've corrected the document.
the error in the specs is about backquote.
to simplify the case, i've decoulpled the explanations from macros.
see text #V0.2
Espen Vestre
> I've to clarify the text, that the specs is wrong and not the
> implementations.
The spec is not 'wrong', but the part you're nagging about is not very
clear or strictly defined (in particular 'backquoted expression' is
vague, in this case the intended meaning is something like
"comma-preceded subexpression of a backquote-expression"), so you may
say that the spec is somewhat _incomplete_ when it comes to nested
backquotes.
In fact the backquote algorithm is not a as complete and formal as one
maybe may have wished, since it lacks the nested case. To make it more
complete and formal, just add the concept of _nesting_level_, where
backquote increases the nesting level and comma decreases it, and
where the comma-expansion only applies if the nesting level is zero
(or one, depending you what you start with :-)).
(nested backquotes has been elaborated to quite a detail by Steele in
CLtL-II (from which the quoted sentence was taken), so although they
have always been considered relatively hard to understand, the
vagueness of the spec has _never_ been a problem for the CLtL
community until the day when a probably great talent for nitty-gritty
bookkeeping lost his way into the freewheeling world of Common Lisp)
--
(espen)
Carlos Ungil
(http://ki.cs.tu-berlin.de/clisp/cltl/clm/node367.html) and it has been
really illuminating.
The key point is:
"In general, Common Lisp guarantees the result of an expression with
backquotes nested to depth k only after k successive evaluations have been
performed; the results after fewer than k evaluations are
implementation-dependent."
"Espen Vestre" <espen@*do-not-spam-me*.vestre.net> wrote in message
news:kwfzw4j...@merced.netfonds.no...
ilias
> ilias <at_...@pontos.net> writes:
>
>>I've to clarify the text, that the specs is wrong and not the
>>implementations.
>
> The spec is not 'wrong', but the part you're nagging about is not very
> clear or strictly defined (in particular 'backquoted expression' is
> vague, in this case the intended meaning is something like
> "comma-preceded subexpression of a backquote-expression"), so you may
> say that the spec is somewhat _incomplete_ when it comes to nested
> backquotes.
the specs is *wrong*.
it states : the *innermost*.
correct is: the *outermost*.
> In fact the backquote algorithm is not a as complete and formal as one
> maybe may have wished, since it lacks the nested case. To make it more
> complete and formal, just add the concept of _nesting_level_, where
> backquote increases the nesting level and comma decreases it, and
> where the comma-expansion only applies if the nesting level is zero
> (or one, depending you what you start with :-)).
I'm a LISP novice.
How could i do that?
> (nested backquotes has been elaborated to quite a detail by Steele in
> CLtL-II (from which the quoted sentence was taken), so although they
thus Steele is wrong in this passage.
> have always been considered relatively hard to understand, the
yes, hard to understand.
due to confusing documentation.
this is a difference.
> vagueness of the spec has _never_ been a problem for the CLtL
you sayed: "have always bee considered relatively hard to understand"
this is a problem.
> community until the day when a probably great talent for nitty-gritty
> bookkeeping lost his way into the freewheeling world of Common Lisp)
The Spirit of Lisp.
Freedom.
But not of this kind.
ilias
> I had been reading at lunchtime the apendix on backquotes in CLtL-II
> (http://ki.cs.tu-berlin.de/clisp/cltl/clm/node367.html) and it has been
> really illuminating.
>
> The key point is:
> "In general, Common Lisp guarantees the result of an expression with
> backquotes nested to depth k only after k successive evaluations have been
> performed; the results after fewer than k evaluations are
> implementation-dependent."
Sounds like this matter:
Allegro:
(setq d 1 c 'd b 'c a 'b )
`(,a `(,b ,,c)) ; => (B (EXCL::BQ-LIST B D))
;;; which is same as: (B `(,B ,D))
LispWorks:
`(,a `(,b ,,c)) ; => (B (SYSTEM::BQ-LIST B D))
;;; which is same as: (B `(,B ,D))
after 1 of 2 evaluations, the results are not equal optically (although
they are logically)
Allegro: (B (EXCL::BQ-LIST B D ))
LispWorks: (B (SYSTEM::BQ-LIST B D ))
the next evaluation ( 2nd of 2, k=2) must have an equal result.
notice that CLTL2 is *not* the ANSI Standard. Its simply a book.
Espen Vestre
> the specs is *wrong*.
>
> it states : the *innermost*.
> correct is: the *outermost*.
No, rewriting with *outermost* doesn't help at all. *innermost* is
correct for the intented meaning, it is "backquoted expression"
which is the vague part here.
> I'm a LISP novice.
You play the expert, so stop whining.
> yes, hard to understand.
>
> due to confusing documentation.
Not at all, it takes some time to understand because it is _complex_
and requires _experience_.
I guess Taekwondo students aren't expected to break bricks with their
bare hands during their first lessons. Likewise, Lisp students are
better off not trying to use nested backquotes. But if they insist,
they should read all the stuff on backquote in Steele instead of
picking on a somewhat _incomplete_ and vague (not incorrect!) part of
the standard.
--
(espen)
Carlos Ungil
> the specs is *wrong*.
>
> it states : the *innermost*.
> correct is: the *outermost*.
The specification says:
An implementation is free to interpret a backquoted form F1 as any form F2
that, when evaluated, will produce a result that is the same under equal as
the result implied by the above definition, provided that the side-effect
behavior of the substitute form F2 is also consistent with the description
given above. The constructed copy of the template might or might not share
list structure with the template itself.
And although it is not specified (but it doesn't mean that the above is
*wrong*) the "when evaluated" before means "when completely evaluated,
several evaluations might take place when dealing with nested backquotes."
You have yet to explain how is the result from the recipe in the
specification different from the one yielded by LispWorks or Alegro.
ilias
> ilias <at_...@pontos.net> writes:
>
>>the specs is *wrong*.
>>
>>it states : the *innermost*.
>>correct is: the *outermost*.
>
> No, rewriting with *outermost* doesn't help at all. *innermost* is
> correct for the intented meaning, it is "backquoted expression"
> which is the vague part here.
innermost/outermost.
this was the essence.
you interprete all the specs.
why not my words?
>
>>I'm a LISP novice.
>
> You play the expert, so stop whining.
not whining.
not expert.
your interpretation.
wrong.
>>yes, hard to understand.
>>
>>due to confusing documentation.
>
> Not at all, it takes some time to understand because it is _complex_
> and requires _experience_.
backquote is a *very* simple construct.
only confusing documentation.
> I guess Taekwondo students aren't expected to break bricks with their
> bare hands during their first lessons. Likewise, Lisp students are
analogy.
faulty.
no further comment.
> better off not trying to use nested backquotes. But if they insist,
> they should read all the stuff on backquote in Steele instead of
of course.
to get fully confused.
> picking on a somewhat _incomplete_ and vague (not incorrect!) part of
> the standard.
incomplete standard?
nice.
the standard if wrong (passage about nested backquote).
so easy.
ilias
there is no need to extend this with other parts of the specs, which
leads to an complexity which cannot be discussed anymore.
to avoid further confusion (not only for me, but for the readers, too):
please go to the posting V0.2
i've take a passage out of the specs, which refers directly to nested
backquote. and i've made a simple demonstration, of why the passage is
wrong.
Espen Vestre
> innermost/outermost.
>
> this was the essence.
One last try:
If you replace innermost with outermost, the sentence you pick on gets
completely bogus. The point really was to communicate that backquotes
and commas match like parantheses. So 'backquoted expression' is the
source of confusion, *not* 'innermost'.
> > better off not trying to use nested backquotes. But if they insist,
> > they should read all the stuff on backquote in Steele instead of
>
> of course.
>
> to get fully confused.
Did you or did you not read all the stuff on backquote in CLtL II?
(btw. I don't know if your name really is Ilias, but imho your writing
style is an insult to Homer)
--
(espen)
ilias
> ilias <at_...@pontos.net> writes:
>
>
>>innermost/outermost.
>>
>>this was the essence.
>
> One last try:
> If you replace innermost with outermost, the sentence you pick on gets
> completely bogus. The point really was to communicate that backquotes
> and commas match like parantheses. So 'backquoted expression' is the
> source of confusion, *not* 'innermost'.
innermost/outermost.
this was the essence.
you find my concrete analysis in #V0.2.
there i explain, and make the same thing what you try to make here:
finding out, what the author want's to express.
it does not change:
the specification is wrong.
>
>>>better off not trying to use nested backquotes. But if they insist,
>>>they should read all the stuff on backquote in Steele instead of
>>
>>of course.
>>
>>to get fully confused.
>
> Did you or did you not read all the stuff on backquote in CLtL II?
I read a little in the specs (online version @lispworks.com).
CLTL II is only a book - irrelevant.
i take a look here:
http://ki.cs.tu-berlin.de/clisp/cltl/clm/node367.html
to complicated.
that's not teaching.
that's confusing.
> (btw. I don't know if your name really is Ilias, but imho your writing
> style is an insult to Homer)
My name is ilias.
Who's Homer?
Espen Vestre
> it does not change:
>
> the specification is wrong.
If you read the specification that way, the sentence you pick on is
neither wrong nor right, because none of the concepts have been
defined formally enough, e.g. the interpretation of "innermost
backquoted form" is open.
> CLTL II is only a book - irrelevant.
Sigh.
> My name is ilias.
>
> Who's Homer?
*ROTFL*!
Homer Simpson of course ;-)!
(are you serious? I don't know what it's called in greek, but at least
in german the Iliad (does that ring a bell?) is spelled Ilias)
--
(espen)
ilias
> ilias <at_...@pontos.net> writes:
>
>>it does not change:
>>
>>the specification is wrong.
>
> If you read the specification that way, the sentence you pick on is
> neither wrong nor right, because none of the concepts have been
> defined formally enough, e.g. the interpretation of "innermost
> backquoted form" is open.
this is 'overbookkeeping'.
>>CLTL II is only a book - irrelevant.
>
> Sigh.
>
>>My name is ilias.
>>
>>Who's Homer?
>
> *ROTFL*!
> Homer Simpson of course ;-)!
>
> (are you serious? I don't know what it's called in greek, but at least
> in german the Iliad (does that ring a bell?) is spelled Ilias)
i'm just interconnecting...
'Homer' with 'Sage der Ilias'
but i don't know both.
a masterpiece, right?
i'll keep this things for the 'evening of live'.
then i've maybe reached the ripeness, to assimilate masterpieces.
Carlos Ungil
> > specification different from the one yielded by LispWorks or Alegro.
>
> there is no need to extend this with other parts of the specs, which
> leads to an complexity which cannot be discussed anymore.
implementation might interpret a backquoted form
as something else if it is equivalent
specification says that
implementations do
everything fine
> i've take a passage out of the specs, which refers directly to nested
> backquote. and i've made a simple demonstration, of why the passage is
> wrong.
you didn't
about LispWorks or Allegro
nothing says the specification
ilias
>>>You have yet to explain how is the result from the recipe in the
>>>specification different from the one yielded by LispWorks or Alegro.
>>
>>there is no need to extend this with other parts of the specs, which
>>leads to an complexity which cannot be discussed anymore.
>
> implementation might interpret a backquoted form
> as something else if it is equivalent
they might.
you can see it on the different outpout of LispWorks/Allegro.
The evaluation-order / expansion order is the point.
> specification says that
>
> implementations do
>
> everything fine
>
>>i've take a passage out of the specs, which refers directly to nested
>>backquote. and i've made a simple demonstration, of why the passage is
>>wrong.
>
> you didn't
i did.
> about LispWorks or Allegro
> nothing says the specification
i refere the lispwors/allegro as a comparision:
the line:
the specs definition.
lispworks/allegro processing.
specs is wrong.
may lispworks/allegro is wrong?
'natural' view of things.
conclusion: specs is wrong.
I stop this game here.
Please be so kindly to answer direclyt to the document, without placing
new documents whilst ignoring the argumentation lines i place.
this makes simply no sense.
Carlos Ungil
I do as well
Espen Vestre
> In fact the backquote algorithm is not a as complete and formal as one
> maybe may have wished, since it lacks the nested case.
Bzzt. I'm a fool. Since ilias put it out of context, I didn't see that
the sentence on nested expressions should be read as _part_ of the
algorithm - as the inductive step. Carlos got it right, the spec is
just fine.
--
(espen)
ilias
there is a sentence.
and this sentence is wrong.
should.
algorithm.
inductive step.
do you believe all this?
-
i had to go.
have fun.
Espen Vestre
> there is a sentence.
>
> and this sentence is wrong.
>
> should.
>
> algorithm.
>
> inductive step.
>
> do you believe all this?
Impressing - your poetic qualities are improving!
--
(espen)
Software Scavenger
> My name is ilias.
>
> Who's Homer?
Ilias or Iliad is the name of the story of the Trojan war. Homer was
the poet who told the story. And also the sequel, which was named the
Odyssey. Have you heard of Achilles, Odyseus, or the Trojan horse?
Some fraction of modern computer science is based on the Trojan horse.
And journeys like the Odyssey cause large software projects to get so
far behind schedule that people forget what they're for. Is Ilias the
name you were born with or is it just an alias?
ilias
> ilias <at_...@pontos.net> wrote in message news:<amfc4l$9tj$1...@usenet.otenet.gr>...
>
>>My name is ilias.
>>
>>Who's Homer?
>
> Ilias or Iliad is the name of the story of the Trojan war. Homer was
> the poet who told the story. And also the sequel, which was named the
> Odyssey. Have you heard of Achilles, Odyseus, or the Trojan horse?
yes. in very early school years. but mostly forgotten.
Achilles heel bone.
Odyseus (many adventures)
Trojan horse (present, filled with warriors)
> Some fraction of modern computer science is based on the Trojan horse.
> And journeys like the Odyssey cause large software projects to get so
> far behind schedule that people forget what they're for. Is Ilias the
> name you were born with or is it just an alias?
It is my real name.
From my Grandfather.
ilias
Kaz Kylhelku
cf333042.02091...@posting.google.com
> ilias <at_...@pontos.net> wrote in message > i try to analyze. this should be the source of confusion:
>
>>
>> http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
>> [...] If the backquote syntax is nested, the innermost backquoted form
>> should be expanded first. This means that if several commas occur in a
>> row, the leftmost one belongs to the innermost backquote.[...]
>>
>> after sleep will be much clearer!!!
>
>
> I suspect that this text is defective. The expansion of a backquote
> expression only takes place when that backquote is evaluated. The only
> way inner backquotes are evaluated at all is if evaluation is forced
> with commas. Otherwise they are simply incorporated into the resulting
> form.
>
> Example:
>
> `(a `(b `(c `(d ,,,,(+ 2 2)))))
>
> ==> (A `(B `(C `(D ,,,4))))
>
> As you can see, the outer backquote disappears, leaving us with the
> list (A ...). The inner backquote expressions are untouched, except
> that the four commas in the row trigger evaluation and substitution of
> (+ 2 2). If there were fewer then four commas, the evaluation would
> not take place. In any case, it is the rightmost comma that
> disappears, as if ,(+ 2 2) was replaced by 4.
ilias
At least i think so.
I've published this in comp.lang.lisp, and asked for validation.
The bug is very simple.
But i got no responses that leads to a confirmation.
I had this again. When i was claiming that:
----------------------------------------------------------------
() can be changed to [] with 2 lines of ANSI Common Lisp Code
An ANSI Conforming Common Lisp implementation *must* execute:
(set-syntax-from-char #\] #\) ) ; => T
(set-syntax-from-char #\[ #\( ) ; => T
[+ 3 2] ; => 5
http://groups.google.com/groups?selm=alot2c$pkv$1...@usenet.otenet.gr
(LispWorks *does*, Franz Allegro *does not*, Corman Lisp *does not*,
other versions: don't know, i got no feedback !
----------------------------------------------------------------
But this case is much simpler.
Interested in "The 'Savages' of C.L.L." ?
Interested in LISP?
Interested in Software Engeneering?
Here's a showcase.
The Medium 'Public Newsgroups'.
Used for quick 'Language Evolution'.
==============================================================
--------------------------------------------------------------------
NESTED BACKQUOTE
--------------------------------------------------------------------
The [online-version of the] standard-document states:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]"
=> "the *innermost* backquoted form *should be* expanded first"
This definition is wrong.
------------------------------------------------------------------------
Testing with implementations:
Allegro:
(setq d 1 c 'd b 'c a 'b )
`(,a `(,b ,,c)) ; => (B (EXCL::BQ-LIST B D))
;;; which is same as: (B `(,B ,D))
LispWorks:
`(,a `(,b ,,c)) ; => (B (SYSTEM::BQ-LIST B D))
;;; which is same as: (B `(,B ,D))
We see in the processing of both implementations:
- The *outermost* backquoted form is expanded first
=> direct contradiction to the specification
- The *innermost* backquoted form is processed *partially* by the
outermost backquote to evaluate the ,,c => ,D.
This confirms: The definition of nested backquote is wrong.
------------------------------------------------------------------------
one could say now:
The specification is correct. The implementors are wrong.
--------------------------------------------------------------------
The 'natural' flow of things will help out.
Naturally (as given by reading in the stream) the outermost backquote is
expanded first.
The Lisp-Reader cannot preview more than *one* char. Thus it is
impossible to detect the existence of the innermost quote to avoid
evaluation of the outermost backquote.
--------------------------------------------------------------------
(setq d 1 c 'd b 'c a 'b )
`(,a `(,b ,,c)) ; => (b `(c ,d))
|_|__||
|_|________|
the only , prior to a will be processed from the outermost `
the only , prior to b will be processed from the innermost `
the left , prior to c will be processed from the innermost `
the right , prior to c will be processed from the outermost `
--------------------------------------------------------------------
The author meant probably this:
If the backquote syntax is nested, the innermost backquoted form should
be *served*[not expanded] first [with a comma]. This means that if
several commas occur in a row, the leftmost one belongs to the innermost
backquote [and so on].
in any case:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first.[...]"
is wrong.
--------------------------------------------------------------------
'Looking around'
i follow an suggested link in the specs:
http://www.lispworks.com/reference/HyperSpec/Body/02_dfa.htm
"[...] Implementors who have no particular reason to make one choice or
another might wish to refer to IEEE Standard for the Scheme Programming
Language,[...]"
http://www.cs.indiana.edu/scheme-repository/doc.standards.html
nothing found there,
but i reached finally this point:
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html#%_sec_4.2.6
"[...]
Quasiquote forms may be nested. Substitutions are made only for unquoted
components appearing at the same nesting level as the outermost
backquote. The nesting level increases by one inside each successive
quasiquotation, and decreases by one inside each unquotation.
`(a `(b ,(+ 1 2) ,(foo ,(+ 1 3) d) e) f)
===> (a `(b ,(+ 1 2) ,(foo 4 d) e) f)
(let ((name1 'x)
(name2 'y))
`(a `(b ,,name1 ,',name2 d) e))
===> (a `(b ,x ,'y d) e)
[...]
"
Which confirms what already is obvious:
The ANSI Common Lisp specification about nested Backquote is wrong.
My main interest now is:
I've lost *many* time due to this wrong specification, which ruins my
understanding process for days.
I've invested *many* time to find out whats happened and to write
everything down, so other newcomers to lisp (i'm a lisp-novice) don't
run into the same problem.
Now look at the behaviour of comp.lang.lisp.
And explain me please:
- Is this a common behaviour of Lisp people?
- Or is this only the behaviour of the few people online in cll?
- are other languages-lovers like this people? i mean, declaring the
specs as a religion which has no errors? Believe - don't doubt.
Are this people not able to say:
- Yes, it's maybe an bug.
- Yes, it's an bug.
- Ok, we've a bug in the specs, so what?
- Ok, we've a bug in the specs, lets look what to do.
Simply to raise the image and the quality of comp.lang.lisp. And of
Common Lisp.
I've a strange feeling, that the nature of Common Lisp is like the
nature oth the people in c.l.l.
Talking, talking, talking.
And silence, when it is time to talk.
-
I'm a lisp-novice.
Be happy.
Espen Vestre
> We see in the processing of both implementations:
>
> - The *outermost* backquoted form is expanded first
> => direct contradiction to the specification
Wrong. The outermost is _evaluated_ first. BOTH are expanded at
read time (i.e. before you get the first result).
I think I now understand why you're confused: Both ACL and LW use
internal functions BQ-LIST (they also use things like BQ-LIST* and
BQ-APPEND) as the *expansion* of the backquote. They're perfectly
allowed to use whatever they like, the spec only states what the
result must be when the backquote form is _evaluated_.
Why do they use special functions instead of list, list* and append?
I think you get the best answer to that if you call PPRINT on a
BQ-LIST-form in LispWorks: LW will prettyprint it with backquote.
--
(espen)
ilias
> ilias <at_...@pontos.net> writes:
>
>>We see in the processing of both implementations:
>>
>>- The *outermost* backquoted form is expanded first
>>=> direct contradiction to the specification
>
> Wrong. The outermost is _evaluated_ first. BOTH are expanded at
> read time (i.e. before you get the first result).
the innermost form *cannot* be expandend/evaluated first.
=> see text #V0.3 (reader cannot preview more than one char).
the innermost *is not* expanded/evaluated first.
=> see code examples from LispWorks / Allegro.
"
Allegro:
(setq d 1 c 'd b 'c a 'b )
`(,a `(,b ,,c)) ; => (B (EXCL::BQ-LIST B D))
;;; which is same as: (B `(,B ,D))
LispWorks:
`(,a `(,b ,,c)) ; => (B (SYSTEM::BQ-LIST B D))
;;; which is same as: (B `(,B ,D))
"
only the outermost backquote is processed for each call.
this is true for Allegro / Lispworks.
this is true for the scheme standard:
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html#%_sec_4.2.6
"[...]
Quasiquote forms may be nested. Substitutions are made only for unquoted
components appearing at the same nesting level as the outermost
backquote. The nesting level increases by one inside each successive
quasiquotation, and decreases by one inside each unquotation.
`(a `(b ,(+ 1 2) ,(foo ,(+ 1 3) d) e) f)
===> (a `(b ,(+ 1 2) ,(foo 4 d) e) f)
(let ((name1 'x)
(name2 'y))
`(a `(b ,,name1 ,',name2 d) e))
===> (a `(b ,x ,'y d) e)
[...]
"
the following matter is clear:
> I think I now understand why you're confused: Both ACL and LW use
i'm not confused anymore.
> internal functions BQ-LIST (they also use things like BQ-LIST* and
> BQ-APPEND) as the *expansion* of the backquote. They're perfectly
> allowed to use whatever they like, the spec only states what the
> result must be when the backquote form is _evaluated_.
ok.
> Why do they use special functions instead of list, list* and append?
> I think you get the best answer to that if you call PPRINT on a
> BQ-LIST-form in LispWorks: LW will prettyprint it with backquote.
ok.
both points are clear.
One reason (maybe the only) for the use of the BQ-LIST etc. functions is
to be able to pretty-print the code.
Fred Gilham
> the innermost form *cannot* be expandend/evaluated first.
>
>
> (setq d 1 c 'd b 'c a 'b )
> `(,a `(,b ,,c))
ilias, you're wrong. Here's why.
Assume you expand the inner backquoted form first.
What would you get if you expanded `(,b ,,c)?
You would get (list b ,c) of course.
"What?" you exclaim, with a puzzled look on your face. "Why didn't c
get substituted for the b?"
Because no evaluation took place. Just EXPANSION. In fact, if you
tried to evaluate it, you'd get an error, because of the extra comma.
But that's OK, since we're not done expanding.
Continuing, we substitute the expanded inner form for the original
inner form and get the following:
`(,a (list b ,c))
When we EXPAND this, we get (list a (list 'list 'b c))
Why? Because everything that doesn't have a comma in the backquoted
form gets a quote in the expanded form...
...which, of course, EVALUATES to (b (list b d)).
--
Fred Gilham gil...@csl.sri.com
It's not when people notice you're there that they pay attention; it's
when they notice you're *still* there. --- Paul Graham
Vassil Nikolov
> Espen Vestre wrote:
> > ilias <at_...@pontos.net> writes:
> >
> >>We see in the processing of both implementations:
> >>
> >>- The *outermost* backquoted form is expanded first
> >>=> direct contradiction to the specification
> >
> > Wrong. The outermost is _evaluated_ first. BOTH are expanded at
> > read time (i.e. before you get the first result).
>
> the innermost form *cannot* be expandend/evaluated first.
>
> => see text #V0.3 (reader cannot preview more than one char).
>
> the innermost *is not* expanded/evaluated first.
Expansion and evaluation are different things, but there
is an analogy between them.
In (+ 1 (* 2 3)), the innermost expression, (* 2 3), is
evaluated first, even though the evaluation of the whole
expression begins with processing the outermost expression.
In an analogous way, the innermost backquoted expression is
expanded first, even though as the reader is consuming the
whole expression, it starts processing it with the outermost
expression.
> => see code examples from LispWorks / Allegro.
>
> "
> Allegro:
> (setq d 1 c 'd b 'c a 'b )
> `(,a `(,b ,,c)) ; => (B (EXCL::BQ-LIST B D))
> ;;; which is same as: (B `(,B ,D))
>
> LispWorks:
>
> `(,a `(,b ,,c)) ; => (B (SYSTEM::BQ-LIST B D))
> ;;; which is same as: (B `(,B ,D))
> "
It would be more instructive to examine what the reader returns
upon reading the backquoted expression.
Hint: (read-from-string "`(,a `(,b ,,c))").
---Vassil.
ilias
>>the innermost form *cannot* be expandend/evaluated first.
>>
>> ....
>>
>>(setq d 1 c 'd b 'c a 'b )
>>`(,a `(,b ,,c))
>
> ilias, you're wrong. Here's why.
> Assume you expand the inner backquoted form first.
ok assuming.
> What would you get if you expanded `(,b ,,c)?
>
> You would get (list b ,c) of course.
remark: this expresssion does not *expand* in reality
> "What?" you exclaim, with a puzzled look on your face. "Why didn't c
> get substituted for the b?"
hypothetical construct. no reason to look puzzled.
> Because no evaluation took place. Just EXPANSION. In fact, if you
> tried to evaluate it, you'd get an error, because of the extra comma.
> But that's OK, since we're not done expanding.
notice: prior to evaluation comes expansion.
notice: you get already an error at expansion-time.
notice: the term 'expansion' is not defined in the specs.
> Continuing, we substitute the expanded inner form for the original
> inner form and get the following:
>
> `(,a (list b ,c))
>
> When we EXPAND this, we get (list a (list 'list 'b c))
>
> Why? Because everything that doesn't have a comma in the backquoted
> form gets a quote in the expanded form...
>
> ....which, of course, EVALUATES to (b (list b d)).
This is an hypothetical expansion/evaluation, which *cannot* happen in
practice.
thus, you confirm me:
i've written:
the innermost form *cannot* be expandend/evaluated first.
=> see text #V0.3 (reader cannot preview more than one char).
as the character-stream is read in, the character-stream gets converted
(expanded) by the lisp-reader into objects.
in Allegro:
`(,a `(,b ,,c))
`( -> (EXCL::BQ-LIST ; outermost is expanded first
,a -> A
`( = (EXCL::BQ_LIST ; innermost is expanded second
,b -> A ;
ilias
> ilias <at_...@pontos.net> wrote in message news:<ami8lk$hs9$1...@usenet.otenet.gr>...
>>Espen Vestre wrote:
>>>ilias <at_...@pontos.net> writes:
>>>>We see in the processing of both implementations:
>>>>
>>>>- The *outermost* backquoted form is expanded first
>>>>=> direct contradiction to the specification
>>>
>>>Wrong. The outermost is _evaluated_ first. BOTH are expanded at
>>>read time (i.e. before you get the first result).
>>the innermost form *cannot* be expandend/evaluated first.
>>
>>=> see text #V0.3 (reader cannot preview more than one char).
>>
>>the innermost *is not* expanded/evaluated first.
>
> Expansion and evaluation are different things, but there
> is an analogy between them.
notice: the term 'expansion' is not defined in the specs.
> In (+ 1 (* 2 3)), the innermost expression, (* 2 3), is
> evaluated first, even though the evaluation of the whole
> expression begins with processing the outermost expression.
begins with *the evaluation* of the outermost expression
+ => (evaluates to) function-call +
1 => (evaluates to) 1
(setq a 4 b 9)
(+ a (* 2 3) b)
(+ ; +=> function-call +
4 ; a=>4 outermost is evaluated partially first
(* 2 3) ; (*2 3)=> 6 innermost is evaluated fully
9) ; b=>9
(+ 4 6 9) ; => 10 result of addition, final evaluation
> In an analogous way, the innermost backquoted expression is
> expanded first, even though as the reader is consuming the
> whole expression, it starts processing it with the outermost
> expression.
>
>>=> see code examples from LispWorks / Allegro.
>>
>>"
>>Allegro:
>>(setq d 1 c 'd b 'c a 'b )
>>`(,a `(,b ,,c)) ; => (B (EXCL::BQ-LIST B D))
>> ;;; which is same as: (B `(,B ,D))
>>
>>LispWorks:
>>
>>`(,a `(,b ,,c)) ; => (B (SYSTEM::BQ-LIST B D))
>> ;;; which is same as: (B `(,B ,D))
>>"
>
> It would be more instructive to examine what the reader returns
> upon reading the backquoted expression.
>
> Hint: (read-from-string "`(,a `(,b ,,c))").
read-from-string returns the full expanded expression.
not the result is what matters.
but the *processing-sequence* to gain that result.
The specs say:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]"
=> "the *innermost* backquoted form *should be* expanded first"
i've said:
the innermost form *cannot* be expandend/evaluated first.
=> see text #V0.3 (reader cannot preview more than one char).
the innermost *is not* expanded/evaluated first.
=> see code examples from LispWorks / Allegro.
as the character-stream is read in, the character-stream gets converted
(expanded) by the lisp-reader into objects.
in Allegro:
`(,a `(,b ,,c))
`( -> (EXCL::BQ-LIST ; *outermost* is expanded first
,a -> A
`( = (EXCL::BQ_LIST ; *innermost* is expanded second
,b -> A ;
as a conclusion, the specification is wrong:
Fred Gilham
> notice: prior to evaluation comes expansion.
> notice: you get already an error at expansion-time.
> notice: the term 'expansion' is not defined in the specs.
ilias, this seems to me to be deliberate obtuseness.
I've showed how you can interpret the spec so as to produce the
results the implementations give. That's really all there is to it.
--
Fred Gilham gil...@csl.sri.com The TMI accident was unique: it was the
only multi-billion dollar accident in history in which nobody was
harmed. -Howard C. Hayden, Professor Emeritus, U of Conn.
ilias
>>notice: prior to evaluation comes expansion.
>>notice: you get already an error at expansion-time.
>>notice: the term 'expansion' is not defined in the specs.
>
> ilias, this seems to me to be deliberate obtuseness.
this 3 times 'notice'is for information purposes only.
> I've showed how you can interpret the spec so as to produce the
> results the implementations give. That's really all there is to it.
you showcase was hypothetical.
i've answered you in detail, why this is wrong.
ilias
The [online-version of the] standard-document states:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]"
=> "the *innermost* backquoted form *should be* expanded first"
This definition of nested backquote syntax is wrong.
------------------------------------------------------------------------
notes to the term 'expansion'
The term 'expansion' is not directly defined in the Glossary of the
specs. It refers to converting the printed representation of an
expression to an expression which can be directly evaluated.
e.g.: 'A expands to (QUOTE A) which evaluates to A
The section about macroexpand refers often to the term expansion:
http://www.lispworks.com/reference/HyperSpec/Body/f_mexp_.htm#macroexpand-1
------------------------------------------------------------------------
Naturally, as given by reading in the character-stream which contains
the expression, the outermost backquote is expanded first.
note:
the expansion syntax is implementation dependent. "SYSTEM::BQ-LIST" is
the function which is used by XANALYS LispWorks.
=> means "evaluates to" (as usual)
%> means "expands to"
(setq a 1 b 2)
`(,a) expands to (SYSTEM::BQ-LIST A) evaluates to 1
`(,a `(,,c))
expands to
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST) C))
the expansion occours whilst reading the expression out of the stream.
(SYSTEM::BQ-LIST
(SYSTEM::BQ-LIST A
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST)
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST) C)
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST) C))
of course, the outermost backquote is expanded first.
during the expansion of the outermost backquote, the innermost backquote
is expanded.
------------------------------------------------------------------------
evaluation sequence
notice: this is to analyze the second sentence of the nested-backquote
specification
(setq d 1 c 'd b 'c a 'b )
`(,a `(,b ,,c)) ; => (b `(c ,d))
|_|__||
|_|________|
the only , prior to a will be processed from the outermost `
the only , prior to b will be processed from the innermost `
the left , prior to c will be processed from the innermost `
the right , prior to c will be processed from the outermost `
--------------------------------------------------------------------
The author meant probably this:
If the backquote syntax is nested, the innermost backquoted form should
be *served*[not expanded] first [with a comma]. This means that if
several commas occur in a row, the leftmost one belongs to the innermost
backquote [and so on].
in any case:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first.[...]"
is wrong.
--------------------------------------------------------------------
Fred Gilham
> http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
> "[...] If the backquote syntax is nested, the innermost backquoted form
> should be expanded first. This means that if several commas occur in a
> row, the leftmost one belongs to the innermost backquote.[...]"
>
> => "the *innermost* backquoted form *should be* expanded first"
>
> This definition of nested backquote syntax is wrong.
And yet I will continue to happily follow section 2.4.6 of the spec as
it is written, and I will go along blissfully expecting
implementations to work the way they do, and I will actually write
programs (instead of engaging in certain other activities of dubious
value, like a certain person who shall remain unnamed), and I'll read
CLTL-2 and run Steele's backquote implementation to see what happens,
and my programs will work, and I won't get flamed by most of the
population of cll and ignored by the rest, and I'll enjoy
understanding things as much as, if not more than, just expressing my
opinion, and, who knows, some day I might actually get good at this
stuff.
--
Fred Gilham gilham @ csl . sri . com
King Christ, this world is all aleak, / And life preservers there are none,
And waves that only He may walk / Who dared to call Himself a man.
-- e. e. cummings, from Jehovah Buried, Satan Dead
ilias
>>http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
>>"[...] If the backquote syntax is nested, the innermost backquoted form
>>should be expanded first. This means that if several commas occur in a
>>row, the leftmost one belongs to the innermost backquote.[...]"
>>
>>=> "the *innermost* backquoted form *should be* expanded first"
>>
>>This definition of nested backquote syntax is wrong.
>
> And yet I will continue to happily follow section 2.4.6 of the spec as
> it is written, and I will go along blissfully expecting
> implementations to work the way they do, and I will actually write
> programs (instead of engaging in certain other activities of dubious
> value, like a certain person who shall remain unnamed), and I'll read
> CLTL-2 and run Steele's backquote implementation to see what happens,
> and my programs will work, and I won't get flamed by most of the
> population of cll and ignored by the rest, and I'll enjoy
> understanding things as much as, if not more than, just expressing my
> opinion, and, who knows, some day I might actually get good at this
> stuff.
nice written.
do i extract that you agree?
Is the backquote-syntax-definition wrong?
Fred Gilham
ilias writes:
> Is the backquote-syntax-definition wrong?
At this point I'm no longer even sure what planet I'm on.
--
Fred Gilham gil...@csl.sri.com
....We doctors know
a hopeless case if --- listen: there's a hell
of a good universe next door; let's go
-e e cummings
Software Scavenger
> Is the backquote-syntax-definition wrong?
If it's hard to understand, does that make it wrong? Try using it for
a while, until you have more experience with it. Then it might become
much easier to understand, and what seemed wrong might seem from a new
perspective to be a simple misunderstanding. And after you finally
understand it, maybe you can give the CL community some suggestions of
how to make it clearer.
Espen Vestre
> If it's hard to understand, does that make it wrong? Try using it for
> a while, until you have more experience with it.
Since ilias is unwilling to learn even the most elementary math, he
will probably never understand the definition he's barking at, so
please, all of you: Unless you have a funny remark you'd like to
share, please don't comment his postings anymore.
(And I apologise that I was fooled into trying to explain anything to
him myself. Sorry for wasting your bandwidth.)
--
(espen)
ilias
xexe!
most of the CL community has not understood nested backquote.
otherwise they would be clear documentation.
otherwise they could show me my fault.
but the cannot.
simply as the fault is in the specs.
the savages will continue to waste their time whilst protecting the
CL-'bible'.
what about you?
will you continue to push out your emty didactically words?
or will you show my my error.
document #V0.4 is very simple.
ilias
could you please be so kindly to post the e-mail you've sent me here in
this group?
thank you.
ilias
you replied 'no'.
it seems, that you've not the courage to speak in the public.
maybe you are afraid, that you'll be finally the 'fool'.
i've no problem to be a fool.
i'm human. not god.
and i'm a lisp-novice.
like the most, if not all people here in c.l.l.
please re-post your message in public, if you have a minimum of respect
for your own person.
Ingvar Mattsson
One of the more amusing errors I've seen was the co-joining of ,'.
Since (as far as I know) ` , and ' are implemented as reader macros
(and the , reader macro would rpesumably have to do a PEEK-CHAR to see
if the next character is @ and if so gobble that up) returning full
forms the ,' sequence would result in (COMMA (QUOTE ...
//Ingvar
--
My posts are fair game for anybody who wants to distribute the countless
pearls of wisdom sprinkled in them, as long as I'm attributed.
-- Martin Wisse, in a.f.p
ilias
the essence
----------------------------------------------------------------
You make yourself a fool.
The sentence you've picked is:
*part of the inductive definition of backquote expansion*
You forced another meaning in it, by reading it isolated from the rest
of the definition.
You're mixing backquote expansion with evaluation.
The specs does *not* say that expansion should be done from inside to
out (since sentence must be read in part of the defined algorhythm ).
The spec does *not* require implementations to implement backquote with
that algorithm.
The spec *does* not put restrictions on backquote expansion order.
Only on the result of EVALUATING backquote forms.
The proof only proovs not understanding of backquote.
----------------------------------------------------------------
Espen Vestre
posts it against your will, but he posts a *mistreated* version of
it!
Since he might have done this only to provoke me to post the whole
mail, I'll only give you the last sentence (The anti-iliasing of the
rest of the mail is left as an exercise for the reader):
Ilias version:
> The proof only proovs not understanding of backquote.
Original:
2) Your "proof" only proves that you haven't understood backquote
properly.
--
(espen)
Joe Marshall
> and i'm a lisp-novice.
>
> like the most, if not all people here in c.l.l.
Many of the regular posters in comp.lang.lisp have had years of
experience with the language.
ilias
this does not exclude, that they are lisp novices.
sometimes doing complicated things let you forget the fundamentals.
The Spirit of Lisp.
ilias
> This man is really unbelievable - you send him mail and he not only
> posts it against your will, but he posts a *mistreated* version of
> it!
i've not posted your email.
sorry for the mistake.
> Since he might have done this only to provoke me to post the whole
paranoia.
> mail, I'll only give you the last sentence (The anti-iliasing of the
> rest of the mail is left as an exercise for the reader):
i've read this sentence again somewhere.
"is left as an exercise for the reader"
i think 'steele'.
in a topic about backquote.
>
> Ilias version:
>
>>The proof only proovs not understanding of backquote.
>
> Original:
>
> 2) Your "proof" only proves that you haven't understood backquote
> properly.
>
thanks.
ilias
> i got via e-mail(i post this out of my memory, sorry):
>
> the essence
i try now to answer to this.
which is very difficult.
cause it's not as a direct reply to my V0.4 document.
this is a common style in cll and general in usenet.
they cannot attack a document?
they write a seperate one.
ungentle people.
anyway.
> ----------------------------------------------------------------
> You make yourself a fool.
fool.
>
> The sentence you've picked is:
> *part of the inductive definition of backquote expansion*
this sounds really complicated and knowledgeable.
>
> You forced another meaning in it, by reading it isolated from the rest
> of the definition.
extract essences.
then interconnect.
To interconnect the essence of some sentences, you have to extract the
essences of this sentences and this extraction of the essences of the
sentences must be independent of essences of other sentences cause
otherwise the essential essence of the essences which is normally based
on the interconnections of the essences of sentences is maybe not the
essential essence of the essences of the sentences.
i need 5 minutes for this.
looks good.
i like it.
>
> You're mixing backquote expansion with evaluation.
not *i* do that.
the *specs* do that.
i've seperated them in V0.4
>
> The specs does *not* say that expansion should be done from inside to
> out (since sentence must be read in part of the defined algorhythm ).
"If the backquote syntax is nested, the innermost backquoted form
should be expanded first."
show me the *precise* interconnection of this sentence to another
sentence, which alters the meaning of this sentencs.
are you people sick?
>
> The spec does *not* require implementations to implement backquote with
> that algorithm.
algorithm?
show me the algorithm!
>
> The spec *does* not put restrictions on backquote expansion order.
"If the backquote syntax is nested, the innermost backquoted form
should be expanded first."
should be. -> restriction
expanded. -> expansion
first. -> order
>
> Only on the result of EVALUATING backquote forms.
not only.
>
> The proof only proovs not understanding of backquote.
sorry. my memory lacks.
i got the original in another posting:
> Original:
>
> 2) Your "proof" only proves that you haven't understood backquote
> properly.
not understood.
who?
me?
the designers?
the documentors?
the standartizers?
> ----------------------------------------------------------------
>
ozan s yigit
> sometimes doing complicated things let you forget the fundamentals.
strangely enough, /not/ with lisp.
> The Spirit of Lisp.
requires more than a microscopic reading of the spec and related banter.
get a life. stop watching so much trek. write some programs.
oz
--
there is a fault in reality. do not adjust your minds. -- salman rushdie
ilias
> ilias <at_...@pontos.net> writes:
>
>>sometimes doing complicated things let you forget the fundamentals.
>
> strangely enough, /not/ with lisp.
>
>>The Spirit of Lisp.
>
> requires more than a microscopic reading of the spec and related banter.
the specs have *nothing* to do with it.
> get a life. stop watching so much trek. write some programs.
>
> oz
yes master.
William Tanksley Google
> the innermost form *cannot* be expandend/evaluated first.
> => see text #V0.3 (reader cannot preview more than one char).
I'm sorry (terribly sorry) to interrupt here, especially to ask such a
simple question, but are you familiar with parsing theory?
The reason I ask is that if you're not, it's very easy to
misunderstand the statement "the lisp reader cannot preview more than
one character." Character and token preview is a specific parsing
technology used to parse some grammars; according to this statement,
Common Lisp doesn't use more than one token of preview.
This does not imply that Lisp's reader can't parse an expression
before dealing with macros and such; it simply means that the parsing
doesn't need to 'cheat' by looking ahead.
On the contrary, as you've proven, Lisp must parse to find balanced
parentheses; only when it has a complete set can it determine what the
innermost level is.
Parsing isn't a simple subject, unfortunately, and I'm not the best of
teachers. If you'd like to know more, I'd be glad to hunt down a nice
tutorial or explanation, at a level you choose. Let me know if that'd
help.
As a closing note: it's not clear to me that you're wrong on the main
subject. It is, however, very clear that you don't understand the
complete issue (something which you admit repeatedly). It would be
prudent for you to gain a more complete understanding in this case
before continuing a debate. I suspect that an introduction to parsing
will be sufficient.
-Billy
P.S. I don't know whether Lisp actually uses a single character of
preview. I can't find anything about it in the hyperspec; I speculate
that it doesn't use ANY preview at all. Why do you claim that it uses
any (i.e. where's your source in the hyperspec)?
ilias
> ilias <at_...@pontos.net> wrote:
>
>>the innermost form *cannot* be expandend/evaluated first.
>>=> see text #V0.3 (reader cannot preview more than one char).
>
>
> I'm sorry (terribly sorry) to interrupt here, especially to ask such a
you don't have to be sorry.
you're welcome.
> simple question, but are you familiar with parsing theory?
no i'm not.
lisp-reader is ther firt construct of this kind which i assimilate.
i'll completely comment your post later, as i must leave from the screen
due to migraine headache.
how can somthing so beatyfull like light hurt?
> P.S. I don't know whether Lisp actually uses a single character of
> preview. I can't find anything about it in the hyperspec; I speculate
> that it doesn't use ANY preview at all. Why do you claim that it uses
> any (i.e. where's your source in the hyperspec)?
unread char:
http://www.lispworks.com/reference/HyperSpec/Body/f_unrd_c.htm#unread-char
"[...]
Notes:
unread-char is intended to be an efficient mechanism for allowing the
Lisp reader and other parsers to perform one-character lookahead in
input-stream.
[...]"
the reader-algorithm (implemented by the function read):
http://www.lispworks.com/reference/HyperSpec/Body/02_b.htm
Joe Marshall
> P.S. I don't know whether Lisp actually uses a single character of
> preview. I can't find anything about it in the hyperspec; I speculate
> that it doesn't use ANY preview at all. Why do you claim that it uses
> any (i.e. where's your source in the hyperspec)?
Section 2.2 Reader Algorithm describes the algorithm as using a single
character lookahead (step 8, clause 5). Intuitively, you have to look
ahead a single character to determine if you have reached the end of a
token.
ilias
> wtan...@bigfoot.com (William Tanksley Google) writes:
>
>>P.S. I don't know whether Lisp actually uses a single character of
>>preview. I can't find anything about it in the hyperspec; I speculate
>>that it doesn't use ANY preview at all. Why do you claim that it uses
>>any (i.e. where's your source in the hyperspec)?
>
> Section 2.2 Reader Algorithm describes the algorithm as using a single
> character lookahead (step 8, clause 5).
bravo.
> Intuitively, you have to look
> ahead a single character to determine if you have reached the end of a
> token.
bravo.
-
i think the reader could be redisigned to work without preview.
i don't like preview.
as i don't like headache.
must stop now.
Brian Palmer
>
> it seems, that you've not the courage to speak in the public.
>
> maybe you are afraid, that you'll be finally the 'fool'.
>
> i've no problem to be a fool.
>
> i'm human. not god.
>
> and i'm a lisp-novice.
Many a troll hath usenet seen,
none so fine as he hath been.
Feed him once, he's back for more,
calls himself a true Lisp whore.
Say "you fool", he says "I am!",
send him mail, he doth post spam.
Tell me, aged one of old:
Why oh why do they feed trolls?
Aleksandr Skobelev
> Many a troll hath usenet seen,
> none so fine as he hath been.
> Feed him once, he's back for more,
> calls himself a true Lisp whore.
> Say "you fool", he says "I am!",
> send him mail, he doth post spam.
>
> Tell me, aged one of old:
> Why oh why do they feed trolls?
Rudyard Kipling? :)
ilias
> Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:
>
>
>>cubic...@mailandnews.com (Software Scavenger) writes:
>>
>>
>>>If it's hard to understand, does that make it wrong? Try using it for
>>>a while, until you have more experience with it.
>>
>>Since ilias is unwilling to learn even the most elementary math, he
>>will probably never understand the definition he's barking at, so
>>please, all of you: Unless you have a funny remark you'd like to
>>share, please don't comment his postings anymore.
>>
>>(And I apologise that I was fooled into trying to explain anything to
>> him myself. Sorry for wasting your bandwidth.)
>
>
> One of the more amusing errors I've seen was the co-joining of ,'.
> Since (as far as I know) ` , and ' are implemented as reader macros
> (and the , reader macro would rpesumably have to do a PEEK-CHAR to see
> if the next character is @ and if so gobble that up) returning full
> forms the ,' sequence would result in (COMMA (QUOTE ...
>
> //Ingvar
where have you seen this error?
ilias
> ilias <at_...@pontos.net> wrote:
>
>>the innermost form *cannot* be expandend/evaluated first.
>>=> see text #V0.3 (reader cannot preview more than one char).
>
> I'm sorry (terribly sorry) to interrupt here, especially to ask such a
> simple question, but are you familiar with parsing theory?
>
> The reason I ask is that if you're not, it's very easy to
> misunderstand the statement "the lisp reader cannot preview more than
> one character."
the statement is true.
> Character and token preview is a specific parsing
> technology used to parse some grammars; according to this statement,
> Common Lisp doesn't use more than one token of preview.
intuition:
- i think it doesn't do.
- simplyfied reader due to simplyfied notation (prefix)
> This does not imply that Lisp's reader can't parse an expression
> before dealing with macros and such; it simply means that the parsing
> doesn't need to 'cheat' by looking ahead.
?
i think you knowledge confuses you.
but i'm not sure.
i'm only sure, that i don't have to have this knowledge to understand.
>
> On the contrary, as you've proven, Lisp must parse to find balanced
> parentheses; only when it has a complete set can it determine what the
> innermost level is.
complete-set. don't know it.
the lispreader cannot *pre*-view.
but he can *past*-view, due to internal flags and variables (intuitive
guess of how its implemented).
>
> Parsing isn't a simple subject, unfortunately, and I'm not the best of
> teachers. If you'd like to know more, I'd be glad to hunt down a nice
> tutorial or explanation, at a level you choose. Let me know if that'd
> help.
if you have an online one with simple terminology, than i'm happy to
read it (at the moment i need it).
i think that the information is not needed to assimilate the lispreader.
the lisp-reader is 'peanuts'.
only difficult documented.
> As a closing note: it's not clear to me that you're wrong on the main
> subject. It is, however, very clear that you don't understand the
> complete issue (something which you admit repeatedly). It would be
The Process of Missunderstanding
has often the effect of better understanding.
many people can understand better, based on my transparent
missunderstandings.
- novices don't fall in the same traps.
- experts see where they confuse novices.
lisp is very easy.
the documentation makes it difficult.
> prudent for you to gain a more complete understanding in this case
> before continuing a debate.
in general, i don't debate.
i ask for information.
somehow.
the savages debate.
> I suspect that an introduction to parsing
> will be sufficient.
the introcution to parsing will be simply confusing.
the lisp-reader is a simple parser.
-
The Spirit of Lisp.
to detect it, i must remain with less knowledge.
William Tanksley Google
> William Tanksley Google wrote:
> > ilias <at_...@pontos.net> wrote:
> >>the innermost form *cannot* be expandend/evaluated first.
> >>=> see text #V0.3 (reader cannot preview more than one char).
> > The reason I ask is that if you're not, it's very easy to
> > misunderstand the statement "the lisp reader cannot preview more than
> > one character."
> the statement is true.
Definitely. But your understanding of the statement is NOT true.
> > Character and token preview is a specific parsing
> > technology used to parse some grammars; according to this statement,
> > Common Lisp doesn't use more than one token of preview.
> intuition:
> - i think it doesn't do.
Do what?
> - simplyfied reader due to simplyfied notation (prefix)
Prefix is still a parsed notation -- if you want an unparsed notation,
you have to switch to a completely different type of language. Lisp is
like almost all the other languages in this respect, that it uses a
parser to convert a text string into a syntax tree.
> > This does not imply that Lisp's reader can't parse an expression
> > before dealing with macros and such; it simply means that the parsing
> > doesn't need to 'cheat' by looking ahead.
> ?
> i think you knowledge confuses you.
Obviously, only one of us is confused.
> but i'm not sure.
> i'm only sure, that i don't have to have this knowledge to understand.
Let me point you to a tutorial so you can have a chance to understand.
> > On the contrary, as you've proven, Lisp must parse to find balanced
> > parentheses; only when it has a complete set can it determine what the
> > innermost level is.
> complete-set. don't know it.
A complete set of parentheses.
> the lispreader cannot *pre*-view.
> but he can *past*-view, due to internal flags and variables (intuitive
> guess of how its implemented).
Wrong guess, correct conclusion. The reader is recursive on lists;
thus, whenever a list is completed (that's what the ")" character
does), the read function which parsed the source code for the list
returns the data structure representing the list. To whom does it
return the data structure? Well, to the read which called it.
> > Parsing isn't a simple subject, unfortunately, and I'm not the best of
> > teachers. If you'd like to know more, I'd be glad to hunt down a nice
> > tutorial or explanation, at a level you choose. Let me know if that'd
> > help.
> if you have an online one with simple terminology, than i'm happy to
> read it (at the moment i need it).
Actually, I'm starting to be convinced that the best (simplest)
alternative would be a little exploration on your part. The problem is
that Lisp parsing is very simple, thanks to its elegant syntax; the
tutorials I could find all assume a much more horrible syntax.
The most immediately appropriate document is:
http://www.cs.utsa.edu/research/AI/cltl/clm/node188.html#SECTION002611000000000000000
Note the paragraph:
"The macro-character function may of course read characters from the
input stream; if it does, it will see those characters following the
macro character. The function may even invoke the reader recursively.
This is how the macro character ( constructs a list: by invoking the
reader recursively to read the elements of the list."
The important thing to see here is recursion. Specifically, every time
read hits a "(", it calls itself for every element in the parentheses,
and forms a list out of the results.
> i think that the information is not needed to assimilate the lispreader.
> the lisp-reader is 'peanuts'.
Yes, it is needed.
> only difficult documented.
If you're expecting a novice-level presentation of the Lisp reader,
the hyperspec is the wrong place to look. It's excellent documentation
for its purpose; but it's not an introduction, and you need one.
> > As a closing note: it's not clear to me that you're wrong on the main
> > subject. It is, however, very clear that you don't understand the
> > complete issue (something which you admit repeatedly). It would be
> The Process of Missunderstanding
> has often the effect of better understanding.
No, misunderstanding is just misunderstanding. The process of
correction of the misunderstanding has the effect of better
understanding. So correct your misunderstanding.
> - novices don't fall in the same traps.
> - experts see where they confuse novices.
> lisp is very easy.
Hmm.
> the documentation makes it difficult.
No, it doesn't. You just need documentation more suited to your level.
I'm not sure what would be most appropriate for you; but "Structure
and Interpretation of Computer Programs," which I believe is available
online, definitely has the answers and presents them accessibly.
>> prudent for you to gain a more complete understanding in this case
>> before continuing a debate.
> in general, i don't debate.
Nonsense! You're stating your position and demanding a rebuttal;
that's a debate.
> the savages debate.
Nonsense. Savages don't debate; they merely attack.
> > I suspect that an introduction to parsing
> > will be sufficient.
> the introcution to parsing will be simply confusing.
Perhaps. But it will leave you less confused, since it will allow you
to understand something which now leaves you hopelessly confused.
> the lisp-reader is a simple parser.
Yes. But it's a parser still.
> The Spirit of Lisp.
> to detect it, i must remain with less knowledge.
I can't contradict that. It's possibly true, although I don't see how
it could be.
However, it's clear that if you wish to remain with less knowledge,
you must stop seeking for knowledge on the technical point of parsing.
You must be content with your confusion.
Stop, then, seeking after the details of the hyperspec; if it doesn't
make sense to you, assume that your lack of knowledge is at fault and
continue on (since otherwise, you might be presented with knowledge
which would obscure the Spirit of Lisp for you). Gather the Spirit of
Lisp, and tell us about it once you have it.
-Billy
ilias
> ilias <at_...@pontos.net> wrote:
you wrote:
>>I'm sorry (terribly sorry) to interrupt here, especially to ask such a
>>simple question, but are you familiar with parsing theory?
i answered you:
>you don't have to be sorry.
>you're welcome.
now, after overflowing your last reply (picking samples) i've the
feeling that your gentleness was not honest.
i'm not sure.
but i'll not read this response fully.
at least not now.
-
style violation.
rejected.
ilias
[SPECS ERR] - Backquote #V0.5 - ilias - 2002-09-25
----------------------------------------------------------------
=> means "evaluates to" (as usual)
=>| means "expands to" [please let me know, if this notation is
reserved somehow]
------------------------------------------------------------------------
The [online-version of the] standard-document states:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]"
=> "If the backquote syntax is nested, the *innermost* backquoted form
*should be* *expanded* first"
This definition of nested backquote syntax is wrong.
------------------------------------------------------------------------
notes to the term 'expansion'
The term 'expansion' is not directly defined in the Glossary of the
specs. It refers to converting the printed representation of an
expression to an expression which can be directly evaluated.
e.g.: 'A =>| (QUOTE A) => A
thus: to evaluate an expression, it must be expanded first (if it needs
expansion), which is normally not 'visible':
'A => A
The section about macroexpand refers often to the term expansion:
http://www.lispworks.com/reference/HyperSpec/Body/f_mexp_.htm#macroexpand-1
------------------------------------------------------------------------
notice:
The specification referes at some places to evaluation and at some
places to expansion:
evaluation:
"[...]
`(x ,x ,@x foo ,(cadr x) bar ,(cdr x) baz ,@(cdr x))
=> (x (a b c) a b c foo b bar (b c) baz b c)
[...]"
expansion:
"[...]
`((,a b) ,c ,@d)
will be interpreted as if it were
(append (list (append (list a) (list 'b) 'nil)) (list c) d 'nil)
[...]"
------------------------------------------------------------------------
Prior to evaluation comes expansion. The doubted sentence of the specs
referes to *expansion*.
Naturally, as given by reading in the character-stream which represents
the expression, the outermost backquote is *expanded* first.
note:
the resulting expansion is implementation dependent. "SYSTEM::BQ-LIST"
is the function which is used by XANALYS LispWorks.
(setq a 1 b 2)
`(,a) =>| (SYSTEM::BQ-LIST A) => 1
`(,a `(,,b))
=>|
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST) B))
the expansion occours whilst reading the expression out of the stream.
(SYSTEM::BQ-LIST
(SYSTEM::BQ-LIST A
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST)
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST) B)
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST) B))
of course, the outermost backquote is expanded first.
during the expansion of the outermost backquote, the innermost backquote
is expanded.
------------------------------------------------------------------------
The doubted sentence refers to *expansion*. A hypothetically view on
evaluation:
even the evaluation has the same order:
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST) B))
=> (1 (SYSTEM::BQ-LIST 2))
again, the outermost form is evaluated first.
during the evaluation of the outermost form, the 2nd-innermost form is
evaluated and during this the innermost.
------------------------------------------------------------------------
evaluation sequence
notice: this is to analyze the second sentence of the nested-backquote
specification
(setq d 1 c 'd b 'c a 'b )
`(,a `(,b ,,c)) ; => (b `(c ,d))
|_|__||
|_|________|
the only , prior to a will be processed from the outermost `
the only , prior to b will be processed from the innermost `
the left , prior to c will be processed from the innermost `
the right , prior to c will be processed from the outermost `
--------------------------------------------------------------------
The author meant probably this:
If the backquote syntax is nested, the innermost backquoted form should
be *served*[not expanded] first [with a comma]. This means that if
several commas occur in a row, the leftmost one belongs to the innermost
backquote [and so on].
--------------------------------------------------------------------
in any case:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first.[...]"
is wrong.
--------------------------------------------------------------------
ilias
> ilias <at_...@pontos.net> wrote:
>
>>William Tanksley Google wrote:
>> > ilias <at_...@pontos.net> wrote:
>
>
>> >>the innermost form *cannot* be expandend/evaluated first.
>> >>=> see text #V0.3 (reader cannot preview more than one char).
>
>
>> > The reason I ask is that if you're not, it's very easy to
>> > misunderstand the statement "the lisp reader cannot preview more than
>> > one character."
>
>
>>the statement is true.
>
>
> Definitely. But your understanding of the statement is NOT true.
i've made the statement.
i've understood the statement.
you comment about my understanding is hypothetical.
>> > Character and token preview is a specific parsing
>> > technology used to parse some grammars; according to this statement,
>> > Common Lisp doesn't use more than one token of preview.
>
>>intuition:
>>- i think it doesn't do.
>
> Do what?
preview more than one token.
it previews only one char.
however, intuition.
and irrelevant at this time
>>- simplyfied reader due to simplyfied notation (prefix)
>
> Prefix is still a parsed notation -- if you want an unparsed notation,
> you have to switch to a completely different type of language. Lisp is
> like almost all the other languages in this respect, that it uses a
> parser to convert a text string into a syntax tree.
i'm assimilating lisp.
>> > This does not imply that Lisp's reader can't parse an expression
>> > before dealing with macros and such; it simply means that the parsing
>> > doesn't need to 'cheat' by looking ahead.
>
>>?
>>i think you knowledge confuses you.
>
> Obviously, only one of us is confused.
ok
>
>>but i'm not sure.
>>i'm only sure, that i don't have to have this knowledge to understand.
>
> Let me point you to a tutorial so you can have a chance to understand.
i said: i'm only *sure*, that i don't have to have this knowledge to
undertand.
accept it.
>> > On the contrary, as you've proven, Lisp must parse to find balanced
>> > parentheses; only when it has a complete set can it determine what the
>> > innermost level is.
>
>>complete-set. don't know it.
>
> A complete set of parentheses.
ok
>>the lispreader cannot *pre*-view.
>>but he can *past*-view, due to internal flags and variables (intuitive
>>guess of how its implemented).
>
> Wrong guess, correct conclusion. The reader is recursive on lists;
> thus, whenever a list is completed (that's what the ")" character
> does), the read function which parsed the source code for the list
> returns the data structure representing the list. To whom does it
> return the data structure? Well, to the read which called it.
my statement was wrong:
the lispreader cannot *pre*-view *more than one char*.
this is true.
>> > Parsing isn't a simple subject, unfortunately, and I'm not the best of
>> > teachers. If you'd like to know more, I'd be glad to hunt down a nice
>> > tutorial or explanation, at a level you choose. Let me know if that'd
>> > help.
>>if you have an online one with simple terminology, than i'm happy to
>>read it (at the moment i need it).
>
> Actually, I'm starting to be convinced that the best (simplest)
> alternative would be a little exploration on your part. The problem is
> that Lisp parsing is very simple, thanks to its elegant syntax; the
> tutorials I could find all assume a much more horrible syntax.
i understand your thought.
>
> The most immediately appropriate document is:
>
> http://www.cs.utsa.edu/research/AI/cltl/clm/node188.html#SECTION002611000000000000000
you give me a pointer to CLTL2 ?
CLTL2 is irrelevant.
and its the source of the wrong sentence in the specs.
thus i've made this topic.
>
> Note the paragraph:
>
> "The macro-character function may of course read characters from the
> input stream; if it does, it will see those characters following the
> macro character. The function may even invoke the reader recursively.
> This is how the macro character ( constructs a list: by invoking the
> reader recursively to read the elements of the list."
>
> The important thing to see here is recursion. Specifically, every time
> read hits a "(", it calls itself for every element in the parentheses,
> and forms a list out of the results.
btw: read the paragraph carefully.
there is a small bug, too.
OK, maybe only a 'bug'.
>>i think that the information is not needed to assimilate the lispreader.
>>the lisp-reader is 'peanuts'.
>
> Yes, it is needed.
ok
>>only difficult documented.
>
> If you're expecting a novice-level presentation of the Lisp reader,
> the hyperspec is the wrong place to look. It's excellent documentation
> for its purpose; but it's not an introduction, and you need one.
Not excellent.
Its missleading.
And its underspecified.
Maybe excellent.
Excellent politics.
>> > As a closing note: it's not clear to me that you're wrong on the main
>> > subject. It is, however, very clear that you don't understand the
>> > complete issue (something which you admit repeatedly). It would be
>
>>The Process of Missunderstanding
>>has often the effect of better understanding.
>
> No, misunderstanding is just misunderstanding. The process of
> correction of the misunderstanding has the effect of better
> understanding. So correct your misunderstanding.
Process.
>>- novices don't fall in the same traps.
>>- experts see where they confuse novices.
>>lisp is very easy.
>
> Hmm.
>
>>the documentation makes it difficult.
>
> No, it doesn't. You just need documentation more suited to your level.
> I'm not sure what would be most appropriate for you; but "Structure
> and Interpretation of Computer Programs," which I believe is available
> online, definitely has the answers and presents them accessibly.
sounds good.
but for this here i don't need it.
>>>prudent for you to gain a more complete understanding in this case
>>>before continuing a debate.
>>
>>in general, i don't debate.
>
> Nonsense! You're stating your position and demanding a rebuttal;
> that's a debate.
ah! debate = friendly talking.
ok.
>
>>the savages debate.
>
> Nonsense. Savages don't debate; they merely attack.
you are right.
ok.
>> > I suspect that an introduction to parsing
>> > will be sufficient.
>
>>the introcution to parsing will be simply confusing.
>
> Perhaps. But it will leave you less confused, since it will allow you
> to understand something which now leaves you hopelessly confused.
i'm not hopelessly confused anymore.
>>the lisp-reader is a simple parser.
>
> Yes. But it's a parser still.
ok
>>The Spirit of Lisp.
>>to detect it, i must remain with less knowledge.
>
> I can't contradict that. It's possibly true, although I don't see how
> it could be.
ok
> However, it's clear that if you wish to remain with less knowledge,
> you must stop seeking for knowledge on the technical point of parsing.
> You must be content with your confusion.
i must become part of the falling rain.
> Stop, then, seeking after the details of the hyperspec; if it doesn't
> make sense to you, assume that your lack of knowledge is at fault and
> continue on (since otherwise, you might be presented with knowledge
> which would obscure the Spirit of Lisp for you). Gather the Spirit of
> Lisp, and tell us about it once you have it.
>
> -Billy
irrelevant.
my process is clear.
-
finally you post was friendly.
but you try to much to make hypothetical suggestions.
-
i've read very much about the reader.
to write this:
http://groups.google.com/groups?selm=amsq4a$cra$1...@usenet.otenet.gr
Brian Palmer
>
> I announce a fault that i've found in the specifications.
You say you announce a fault that you've found in the specifications?
> At least i think so.
Can you elaborate on that?
> Please validate this, so more users can benefit from this information.
I'm not sure I understand you fully.
> Is there any place where clarifications / corrections of the
> specifications were collected?
Please go on.
> --------------------------------------------------------------------
>
> The standard-document states:
>
> http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
> "[...] If the backquote syntax is nested, the innermost backquoted form
> should be expanded first. This means that if several commas occur in a
> row, the leftmost one belongs to the innermost backquote.[...]"
>
> => "the *innermost* backquoted form *should be* expanded first"
>
> => " if several commas occur in a row, the *leftmost* comma belongs to
> the *innermost* backquote"
>
> This definition is false.
What does that suggest to you?
Brian Palmer
>
> sorry.
Please don't apologize.
> i've corrected the document.
Do you feel strongly about discussing such things?
> the error in the specs is about backquote.
I'm not sure I understand you fully.
> to simplify the case, i've decoulpled the explanations from macros.
Please go on.
Brian Palmer
>
> you don't have to be sorry.
We were discussing you -- not me.
> you're welcome.
What makes you think I am welcome?
> no i'm not.
Are you saying that just to be negative?
> lisp-reader is ther firt construct of this kind which i assimilate.
Do you say lisp reader is ther first construct of this kind which you
assimilate for some special reason?
> i'll completely comment your post later, as i must leave from the screen
> due to migraine headache.
Why are you concerned over my post later?
> how can somthing so beatyfull like light hurt?
Why do you ask?
Brian Palmer
>
> the statement is true.
What does that suggest to you?
> intuition:
>
> - i think it doesn't do.
That's quite interesting.
> - simplyfied reader due to simplyfied notation (prefix)
Do you feel strongly about discussing such things?
> i think you knowledge confuses you.
Oh, I?
> but i'm not sure.
Is it because you are not sure that you came to me?
> i'm only sure, that i don't have to have this knowledge to understand.
How long have you been only sure?
> complete-set. don't know it.
I'm not sure I understand you fully.
> the lispreader cannot *pre*-view.
Please go on.
> but he can *past*-view, due to internal flags and variables (intuitive
> guess of how its implemented).
Does that question interest you?
Brian Palmer
>
> now, after overflowing your last reply (picking samples) i've the
> feeling that your gentleness was not honest.
What about your own last reply picking samples i've the feeling that my
gentleness was not honest?
> i'm not sure.
Do you believe it is normal not to be sure?
> but i'll not read this response fully.
What does that suggest to you?
> at least not now.
Do you feel strongly about discussing such things?
> style violation.
I'm not sure I understand you fully.
> rejected.
Please go on.
Brian Palmer
>
> you replied 'no'.
You're not really talking about me -- are you?
> it seems, that you've not the courage to speak in the public.
What does that suggest to you?
> maybe you are afraid, that you'll be finally the 'fool'.
You don't seem quite certain.
> i've no problem to be a fool.
You are being a bit negative.
> i'm human. not god.
Do you enjoy being human?
> and i'm a lisp-novice.
Is it because you're a lisp-novice that you came to me?
> like the most, if not all people here in c.l.l.
Do you think it's likely that not all people here in c.l.l.?
> please re-post your message in public, if you have a minimum of respect
> for your own person.
Are you worried about someone else's message in public?
Brian Palmer
>
> i've made the statement.
Please go on.
> i've understood the statement.
Can you elaborate on that?
> you comment about my understanding is hypothetical.
Why do you say that your understanding is hypothetical?
> i'm assimilating lisp.
How long have you been assuming lisp?
> i said: i'm only *sure*, that i don't have to have this knowledge to
> undertand.
Do you believe it is normal to be only sure?
> my statement was wrong:
Does that suggest anything else which belongs to you?
> i understand your thought.
Do you say you understand my thought for some special reason?
> thus i've made this topic.
Does that have anything to do with the fact that your understanding is
hypothetical?
> there is a small bug, too.
But your statement was wrong.
> but for this here i don't need it.
Don't you really need it?
> you are right.
Does it please you to believe I am right?
> i'm not hopelessly confused anymore.
Do you enjoy being not hopelessly confused anymore?
> i must become part of the falling rain.
That's quite interesting.
> my process is clear.
Is it important that your process is clear?
> i've read very much about the reader.
But your process is clear.
Christopher Browne
No, Eliza, please don't...
(Unless you can get Mr Ractor involved for a threesome...)
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://cbbrowne.com/info/lsf.html
"I'm sorry, Mr. Kipling, but you just don't know how to use the
English Language." -- Editor of the San Francisco Examiner, informing
Rudyard Kipling, who had one article published in the newspaper, that
he needn't bother submitting a second, 1889
Brian Palmer
William Tanksley Google
> you give me a pointer to CLTL2 ?
> CLTL2 is irrelevant.
> and its the source of the wrong sentence in the specs.
> thus i've made this topic.
Why isn't the original source relevant? If, as you are claiming, the
spec contains an sentence inherited from CLTL2, then it's possible
that the sentence was given context in CLTL2 which makes it correct in
CLTL2. It's possible that the error in the specs (if there were one)
is simply the omission of some critical context which was given in
CLTL2.
Identifying the source of that error would help your cause immensely.
In any case, I quoted CLTL2 because it explains the process of reading
tersely and elegantly. You need that explanation.
> > Note the paragraph:
> > "The macro-character function may of course read characters from the
> > input stream; if it does, it will see those characters following the
> > macro character. The function may even invoke the reader recursively.
> > This is how the macro character ( constructs a list: by invoking the
> > reader recursively to read the elements of the list."
> > The important thing to see here is recursion. Specifically, every time
> > read hits a "(", it calls itself for every element in the parentheses,
> > and forms a list out of the results.
> btw: read the paragraph carefully.
> there is a small bug, too.
> OK, maybe only a 'bug'.
Specify the bug -- I don't see any.
One possible macro-character function for '(' is given in the
hyperspec; it's 'read-delimited-list'. See
http://www-2.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/fun_read-delimited-list.html
for details. The spec doesn't require or state that this function may
be used, but its requirements for list processing clearly permit one
like it, and in fact the spec does say that this function is intended
for use in reader macros.
This is important: notice that this function doesn't ever let its
caller see the close-parenthesis. This means that if a function like
this is used as a reader macro, the read function will never see the
final delimiter!
Follow that through to its logical conclusion: If the read function
never sees the delimiter, it doesn't matter whether that delimiter has
a macro function. Such a macro function wouldn't get executed!
Furthermore, because this function is explicitly intended to be used
in implementing reader macros, and because it explicitly uses a
textual character (such as close-parenthesis), the direct intent of
the standard is that macro functions which parse a list must parse for
a character, NOT a function. This means that most macro functions
which use ")" as a delimiter will continue to do so even if you alter
*readtable*.
Truly, my logic is dizzying. But I'm only getting warmed up.
A Lisp implementation may (the standard doesn't forbid it) allow you
to write what you did, swapping [] for (). But one which does so will
cause other people's macros to look odd, because they're written with
read-delimited-list and thus will always use the same old character as
their closing character.
So a conforming Lisp which doesn't want to look odd will *not* allow
the behavior you're requiring, even though the standard allows it.
Read the above discussion carefully. Try to find a flaw, and if you do
report it to me. Be specific. Note the two conclusions: first, that
it's permissible to NOT call the macro function associated with an
end-of-list delimiter; and second, that it's advisable to not search
for end-of-list tokens according to readtable's bindings.
> >>only difficult documented.
> > If you're expecting a novice-level presentation of the Lisp reader,
> > the hyperspec is the wrong place to look. It's excellent documentation
> > for its purpose; but it's not an introduction, and you need one.
> Not excellent.
> Its missleading.
Wrong.
> And its underspecified.
Correct. That's the right thing to do in many cases. This is one of
those cases where underspecification produces NO harm to the language:
why, after all, would you ever want to globally replace () with []?
> Maybe excellent.
> Excellent politics.
Politics isn't a bad word.
> > No, it doesn't. You just need documentation more suited to your level.
> > I'm not sure what would be most appropriate for you; but "Structure
> > and Interpretation of Computer Programs," which I believe is available
> > online, definitely has the answers and presents them accessibly.
> sounds good.
> but for this here i don't need it.
You wouldn't need it if you would learn by our teaching. Will you? If
you won't, and if you won't stop trying to gain knowledge, then you
must seek the knowledge elsewhere. SICP is a magnificent place to
start.
> > Stop, then, seeking after the details of the hyperspec; if it doesn't
> > make sense to you, assume that your lack of knowledge is at fault and
> > continue on (since otherwise, you might be presented with knowledge
> > which would obscure the Spirit of Lisp for you). Gather the Spirit of
> > Lisp, and tell us about it once you have it.
> irrelevant.
How could it be? You declared that knowledge is anathema to gathering
the Spirit of Lisp; so grasping after petty details of knowledge must
therefore logically be anathema.
> my process is clear.
No, it's not. It makes no sense at all.
> finally you post was friendly.
Finally? You mean as opposed to your original post, in which you
claimed my post was unfriendly and rejected it?
> but you try to much to make hypothetical suggestions.
I made practical, concrete suggestions.
-Billy
ilias
> ilias <at_...@pontos.net> wrote:
>
>>you give me a pointer to CLTL2 ?
>>CLTL2 is irrelevant.
>>and its the source of the wrong sentence in the specs.
>>thus i've made this topic.
>
> Why isn't the original source relevant? If, as you are claiming, the
> spec contains an sentence inherited from CLTL2, then it's possible
> that the sentence was given context in CLTL2 which makes it correct in
> CLTL2. It's possible that the error in the specs (if there were one)
> is simply the omission of some critical context which was given in
> CLTL2.
possible.
evaluating Common Lisp Specs.
CLTL2 is irrelevant.
rejected.
> Identifying the source of that error would help your cause immensely.
>
> In any case, I quoted CLTL2 because it explains the process of reading
> tersely and elegantly. You need that explanation.
i understand your thought.
your thought.
rejected.
>
>
>>>Note the paragraph:
>>
>
>>>"The macro-character function may of course read characters from the
>>>input stream; if it does, it will see those characters following the
>>>macro character. The function may even invoke the reader recursively.
>>>This is how the macro character ( constructs a list: by invoking the
>>>reader recursively to read the elements of the list."
>>
>
>>>The important thing to see here is recursion. Specifically, every time
>>>read hits a "(", it calls itself for every element in the parentheses,
>>>and forms a list out of the results.
>>
>
>>btw: read the paragraph carefully.
>>there is a small bug, too.
>>OK, maybe only a 'bug'.
>
>
> Specify the bug -- I don't see any.
i'm tired.
i'll not open a new topic.
not now.
or never again.
sorry.
> One possible macro-character function for '(' is given in the
> hyperspec; it's 'read-delimited-list'. See
>
> http://www-2.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/fun_read-delimited-list.html
>
> for details. The spec doesn't require or state that this function may
> be used, but its requirements for list processing clearly permit one
> like it, and in fact the spec does say that this function is intended
> for use in reader macros.
>
> This is important: notice that this function doesn't ever let its
> caller see the close-parenthesis. This means that if a function like
> this is used as a reader macro, the read function will never see the
> final delimiter!
>
> Follow that through to its logical conclusion: If the read function
> never sees the delimiter, it doesn't matter whether that delimiter has
> a macro function. Such a macro function wouldn't get executed!
you are wrong.
and i'll not teach you, whilst you try to teach me.
aborted...
>
> Furthermore, because this function is explicitly intended to be used
> in implementing reader macros, and because it explicitly uses a
> textual character (such as close-parenthesis), the direct intent of
> the standard is that macro functions which parse a list must parse for
> a character, NOT a function. This means that most macro functions
> which use ")" as a delimiter will continue to do so even if you alter
> *readtable*.
>
> Truly, my logic is dizzying. But I'm only getting warmed up.
>
> A Lisp implementation may (the standard doesn't forbid it) allow you
> to write what you did, swapping [] for (). But one which does so will
> cause other people's macros to look odd, because they're written with
> read-delimited-list and thus will always use the same old character as
> their closing character.
>
> So a conforming Lisp which doesn't want to look odd will *not* allow
> the behavior you're requiring, even though the standard allows it.
>
> Read the above discussion carefully. Try to find a flaw, and if you do
> report it to me. Be specific. Note the two conclusions: first, that
> it's permissible to NOT call the macro function associated with an
> end-of-list delimiter; and second, that it's advisable to not search
> for end-of-list tokens according to readtable's bindings.
...end of aborted.
>
>
>>>>only difficult documented.
>>>
>>>If you're expecting a novice-level presentation of the Lisp reader,
>>>the hyperspec is the wrong place to look. It's excellent documentation
>>>for its purpose; but it's not an introduction, and you need one.
>>
>
>>Not excellent.
>>Its missleading.
>
> Wrong.
yes, missleading and partially wrong.
no problem.
the authors are humans - not gods.
>
>
>>And its underspecified.
>
>
> Correct. That's the right thing to do in many cases. This is one of
> those cases where underspecification produces NO harm to the language:
> why, after all, would you ever want to globally replace () with []?
for fun.
>
>
>>Maybe excellent.
>>Excellent politics.
>
>
> Politics isn't a bad word.
ok
>
>
>>>No, it doesn't. You just need documentation more suited to your level.
>>>I'm not sure what would be most appropriate for you; but "Structure
>>>and Interpretation of Computer Programs," which I believe is available
>>>online, definitely has the answers and presents them accessibly.
>>
>
>>sounds good.
>>but for this here i don't need it.
>
>
> You wouldn't need it if you would learn by our teaching. Will you? If
> you won't, and if you won't stop trying to gain knowledge, then you
> must seek the knowledge elsewhere. SICP is a magnificent place to
> start.
so read it.
carefully.
may you then understand the design of the lisp reader.
cause you havn't.
>
>
>>>Stop, then, seeking after the details of the hyperspec; if it doesn't
>>>make sense to you, assume that your lack of knowledge is at fault and
>>>continue on (since otherwise, you might be presented with knowledge
>>>which would obscure the Spirit of Lisp for you). Gather the Spirit of
>>>Lisp, and tell us about it once you have it.
>>
>
>>irrelevant.
>
>
> How could it be? You declared that knowledge is anathema to gathering
> the Spirit of Lisp; so grasping after petty details of knowledge must
> therefore logically be anathema.
you suggest me a processing model.
irrelevant.
>
>
>>my process is clear.
>
>
> No, it's not. It makes no sense at all.
for you.
thats irrelevant.
>
>
>>finally you post was friendly.
>
>
> Finally? You mean as opposed to your original post, in which you
> claimed my post was unfriendly and rejected it?
i wrote:
------------------------------
> now, after overflowing your last reply (picking samples) i've the feeling that your gentleness was not honest.
>
> i'm not sure.
>
> but i'll not read this response fully.
>
> at least not now.
>
> -
>
> style violation.
>
> rejected.
------------------------------
i'm human. not god.
i make errors.
correct words:
assumed style violation.
provisionally rejected.
>
>
>>but you try to much to make hypothetical suggestions.
>
>
> I made practical, concrete suggestions.
you cannot make 'practical, concrete suggestion'.
you don't have the knowledge.
about the most important factor:
the target of your practical, concrete suggestions.
me.
you don't know me.
accept your limits.
ilias
----------------------------------------------------------------
[SPECS ERR] - Backquote #V0.6 - ilias - 2002-09-28
----------------------------------------------------------------
=> means "evaluates to" (as usual)
=>| means "expands to" [please let me know, if this notation is
reserved somehow]
------------------------------------------------------------------------
The [online-version of the] standard-document states:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]"
=> "If the backquote syntax is nested, the *innermost* backquoted form
*should be* *expanded* first"
This definition of nested backquote syntax is wrong.
------------------------------------------------------------------------
The term 'expansion'
The term 'expansion' is not directly defined in the Glossary of the
specs. It refers to converting the printed representation of an
expression to an expression which can be directly evaluated.
e.g.: 'A =>| (QUOTE A) => A
thus: to evaluate an expression, it must be expanded first (if it needs
expansion), which is normally not 'visible':
'A => A
The section about macroexpand refers often to the term expansion:
http://www.lispworks.com/reference/HyperSpec/Body/f_mexp_.htm#macroexpand-1
------------------------------------------------------------------------
notice:
The specification of backquote referes at some places to evaluation and
expansion:
`(,a `(,,b))
=>|
------------------------------------------------------------------------
An hypothetically view on evaluation:
The doubted sentence refers to *expansion*. But even the evaluation has
the same order:
(SYSTEM::BQ-LIST A (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST) B))
=> (1 (SYSTEM::BQ-LIST 2))
again, the outermost form is evaluated first.
During the evaluation of the outermost form, the 2nd-innermost form is
evaluated and during this the innermost.
------------------------------------------------------------------------
evaluation sequence
notice: this is to analyze the second sentence of the nested-backquote
specification
(setq d 1 c 'd b 'c a 'b )
`(,a `(,b ,,c)) ; => (b `(c ,d))
|_|__||
|_|________|
the only , prior to a will be processed from the outermost `
the only , prior to b will be processed from the innermost `
the left , prior to c will be processed from the innermost `
the right , prior to c will be processed from the outermost `
the leftmost comma before c remains *unprocessed* after the evaluation!
--------------------------------------------------------------------
The author meant probably this:
If the backquote syntax is nested, the innermost backquoted form should
be *served*[not expanded] first [with a comma]. This means that if
several commas occur in a row, the leftmost one belongs to the innermost
backquote [and so on].
--------------------------------------------------------------------
in any case:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first.[...]"
is wrong.
--------------------------------------------------------------------
TRACE
--------------------------------------------------------------------
Using this code, you can trace the expansion of the backquote.
The code is for XANALYS LispWorks.
;;; tracing expansion of backquote
(trace SYSTEM::READ-BACKQUOTE) ; Xanalys LispWorks specific
;;; tracing expansion of !
(defun expansion-tracer (stream char)
(format T "~% The Expansion of The !:
~% The Spirit of Lisp - you can't beat it~% " ))
;;; attach reader-macro-function to !
(set-macro-character #\! #'expansion-tracer)
;;; some vars
(setq a 1 b 2)
;;; this line expands during read:
`(,a ! `(,,b))
----------------------------------------------------------------------
0 SYSTEM::READ-BACKQUOTE > (#<E::R-S #<E:BUFFER CAPI i-pane2>> #\`)
>> STREAM : #<E::R-S #<E:BUFFER CAPI i-pane2>>
>> CHAR : #\`
The Expansion of The !:
The Spirit of Lisp - you can't beat it
1 SYSTEM::READ-BACKQUOTE > (#<E::R-S #<E:BUFFER CAPI i-pane2>> #\`)
>> STREAM : #<E::R-S #<E:BUFFER CAPI i-pane2>>
>> CHAR : #\`
1 SYSTEM::READ-BACKQUOTE < ((SYSTEM::BQ-LIST #))
0 SYSTEM::READ-BACKQUOTE < ((SYSTEM::BQ-LIST A NIL #))
|||
||+----+
|+---+ |
| | |
`(,a ! `(,,b))
(1 NIL (SYSTEM::BQ-LIST 2))
As you see, the outermost backquote is expanded first.
----------------------------------------------------------------------
a further discussion of trace in context of this topic here:
http://groups.google.com/groups?selm=kwsmzxw...@merced.netfonds.no
----------------------------------------------------------------------
ilias
initial
http://groups.google.com/groups?selm=amc48r$hc0$1...@usenet.otenet.gr
V0.2
http://groups.google.com/groups?selm=amep5j$ji6$1...@usenet.otenet.gr
V0.3
http://groups.google.com/groups?selm=amhlmk$456$1...@usenet.otenet.gr
V0.4
http://groups.google.com/groups?selm=amnmpf$89d$1...@usenet.otenet.gr
V0.5
http://groups.google.com/groups?selm=amt301$spr$1...@usenet.otenet.gr
V0.6
http://groups.google.com/groups?selm=an4ic3$om9$1...@usenet.otenet.gr