[cl-typesetting-devel] CLISP support

[Marc Battyani]

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

> On Sun, Apr 25, 2004 at 04:01:55PM +0200, Marc Battyani wrote:

> The accumulation section for maximize specifically says "If the maximize
> or minimize clause is never executed, the accumulated value is
> unspecified". And that's what is happening here.

OK I missed this one and it's the good point. So CLISP is OK here.

> Other compilers apparently use more complex type inference to figure out
> that it's a number (I can't see how they are supposed to deduce that it's
> a float given the available information), but that's beyond what the
> standard requires.

LW returns 0 not 0.0. It's better IMO as number variables are to be
initialized with 0 (or 0.0 for a float) though we should not rely on it
based on the standard. Anyway nil is also an arbitrary value so (or
max-height 0) is not compliant either.

> > 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.
>
> That may be an alternative, I have not looked at "iterate" yet. One
> reason I dislike LOOP is that it doesn't play well with my editor's s-exp
> manipulation commands.
>
> But another disadvantage is that it apparently encourages long complex
> functions with unobvious semantics which are painful to debug, which I'm
> not sure that iterate would be better with.

The major advantage of iterate is that it is AFAIK there is only one version
and the source is public :)

> > > (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)
>
> I don't agree - the standard specifies sequential *binding* as in DO vs.
> DO*, but it does not mention anywhere that this has anything to do with
> the semantics of the end tests.

In 6.1.2.1 Iteration Control:
"When iteration control clauses are used in a loop, the corresponding
termination tests in the loop body are evaluated before any other loop body
code is executed."
For me "any other" applies to other clauses as well. The reference to do and
do* is unfortunate because they have only one termination form.

> My understanding of loop (such as it is) would say that the FOR and AND
> variants would be equivalent to DO*/DO loops like this:
>
> (do ((i 0 (incf i))
>      (j 0 (incf j)))
>     ((or (>= i 2) (>= j 2)) (list i j)))
>
> (do* ((i 0 (incf i))
>       (j 0 (incf j)))
>      ((or (>= i 2) (>= j 2)) (list i j)))
>
> which of course behave identically, since the i and j binding/stepping
> clauses are independent.
>
> > 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 ? ;-)
>
> I'll do that at least to clarify what's going on. But except for the "on
> list" example I'm not sure if the standard offers much support.

Unfortunally the standard is ambiguous on several points. Some time ago
there was a problem with CMUCL and parse-integer. Again the standard could
be interpreted in 2 ways. Finally they decided to go back to the
interpretation of all the other implementations. Maybe the CLISP developpers
will agree to do the same. (ie interpret the standard like all the other
implementations)

> Is "iterate" specified less ambiguously? That alone would be a reason to
> choose it.

see above.

Marc