[cl-typesetting-devel] CLISP support

[Marc Battyani]

"Klaus Weidner" <kw at w-m-p.com> wrote:

> I got the table handling working on CLISP. This was *not* fun to track
> down, it turned out to be due to semantic differences in the way the
> different Lisps implement the LOOP macro. This has cost me a couple of
> hours which I'd rather have spent on something more productive :-(

Sure and it's contagious as I took some time to look at it too. :(
But at least for the maximize into, the culprit is clearly CLISP. ;-)

>From 6.1.3 Value Accumulation Clauses:
"The var argument is bound as if by the construct with.
[...]
The default type is implementation-dependent; but it must be a supertype of
type real."

>From 6.1.2.2 Local Variable Initializations:
The with construct initializes variables that are local to a loop.
[...]
For example, for the types t, number, and float, the default values are nil,
0, and 0.0 respectively."

So max-height should be 0.0

> See below for results of my experiments. If someone can point me to the
> place in the standard that proves that one of these behaviors is not
> compliant, I'll gladly file a bug report for the affected implementation.
>
> Section 6.1.2.1 says that variables are stepped "at" each iteration (when
> exactly?), and that the difference between parallel AND and sequential
> FOR binding is analogous to the difference between DO and DO* (which
> behave identically as far as loop termination is concerned). I personally
> find the CLISP behavior more logical...

You have to look at the standard for each loop construct to be sure.
For instance "6.1.2.1.2 The for-as-in-list subclause" says:
"The variable var is bound to the successive elements of the list in form1
before each iteration."
So (loop for r in '(42) finally (return r)) => 42 is ok.

In "6.1.2.1.3 The for-as-on-list subclause" you have
The variable var is bound to the successive tails of the list in form1.
There is no "before" here so nil is the tail but it's not a list (atom nil)
=> t so the clause terminates.
(loop for r on '(42) finally (return r)) should return nil.
Don't forget that nil is an atom (atom nil) => t
(loop for r on '(42 . 43) do finally (return r)) should return 43

So here also clisp is wrong.

> The appended patch has workarounds, but IMHO the code should really be
> rewritten to be less loopy. Apparently having more than a single exit
> clause in a loop is asking for trouble, and the implementations can't
> even agree on the simple case of what an "for X on LIST" should return.

I was also prejudicied against loop earlier, but I took the time to learn it
and now I rather like it. It fits well in the Common Lisp way of doing it
(create a domain specfic language) the only bad thing is the syntax which is
not lispy. (PG does not like loop but he likes scheme more than CL.) May be
we should switch to iterate which is a more lispy loop? I have an iterate
version and IIRC Andreas Fuchs has revived and packaged it also.

> ;; LOOP test results. CMUCL and SBCL have identical behavior, which
> ;; apparently also matches that of LispWorks.
>
> (loop for r in '(42) finally (return r))
>
>    all   => 42
>
> (loop for r on '(42) finally (return r))
>
>    sbcl  => nil
>    clisp => (42)

all is correct see above.

> (loop for i from 0 below 2
>       for j from 0 below 1
>       finally (return (list i j)))
>
>    all   => (1 1)
>
> (loop for i from 0 below 2
>       for j from 0 below 2
>       finally (return (list i j)))
>
>    sbcl  => (2 1)
>    clisp => (2 2)

all is correct: the clauses are executed sequentially. (6.1.2.1 Iteration
Control)

> (loop for i from 0 below 2
>       and j from 0 below 2
>       finally (return (list i j)))
>
>    all   => (2 2)
>
> (loop for i from 0 below 2
>       for j from 0 below 3
>       finally (return (list i j)))
>
>    sbcl  => (2 1)
>    clisp => (2 2)

idem.

So for the patches, it's not a problem of semantic differences but a problem
of non conformance of clisp.
I will put your paches but with #+/-clisp conditionnals.
Do you send an email to the clisp mailing list (clisp-devel)  or do I do it
? ;-)

Marc