CLISP developers attitude. Was: [cl-typesetting-devel] CLISP support

[Marc Battyani]

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

> On Mon, Apr 26, 2004 at 05:29:21PM +0200, Marc Battyani wrote:
>
> I've looked at the iterate macro this weekend, and I very much like the
> idea of switching to that - it's conceptually very close to LOOP, but
> more powerful and cleaner. It's X11-style-licensed, so could even be
> included in the source package (contrib/ ?) for people who don't have it.
>
> So any rework should probably be based on that.

So do I wait for your new patches or do I put your last ones.
Just note that your workaround will not work on the next release of CLISP as
they are busy to patch it to be sure that it won't work!! This is truly
amazing! I would have understood if they did nothing, but they are actually
spending time to be sure that it won't work. When I think at the time we
spent on this CLISP issue, I'm rather disgusted. Are you sure you need to
use CLISP ? Otherwise I would put #+clisp (error "You should use another
implementation")

Ok, I'm rather upset but look at this:

"Sam Steingold" <sds at gnu.org>
> > * Bruno Haible <oehab at pyvfc.bet> [2004-04-26 17:28:10 +0200]:
[...]
> > Can we add a warning about it? Let's say, expand
> >
> >     (loop for r in '(42) finally (return r))
> >
> > into something where the loop epilogue looks like this:
> >
> >   system::end-loop
> >   (let ((#:G172 r))
> >     (macrolet ((loop-finish () (system::loop-finish-warn) '(go
system::end-loop))
> >                (#:G173 () (system::loop-finally-abuse-warn 'r) '#:G172))
> >       (symbol-macrolet ((r (#:G173)))
> >         (return r))))
> >
> > The system::loop-finally-abuse-warn function would signal a
> > portability warning at macroexpansion time.
>
> (loop for r in '(42) finally (setq r 123) (return r))
>
> will give 2 unwarranted warnings.
>
> I would prefer that this usage just be banned, via an ANSI action.

And this one is even worse:
"Sam Steingold" <sds at gnu.org>
> The interesting thing is just starting.
> IIUC, Paul's test suite uncovered some bugs in this MIT LOOP (which,
> again IIUC, was something like _a_ reference implementation for the
> standard - not _THE_ reference implementation, of course).
> This means that some people who are using this implementation will be
> fixing it.  Incompatibly.  Introducing different new bugs.  Cool!

He is happy to see that it will be the mess!

[All this is public it's on the clisp-devel mailing list]

:(

Marc