Re: more bugs in openmcl

Dear Gary and bug-openmcl'ers,

> In Common Lisp, the variable which holds the pathname of the file being
> compiled is named *COMPILE-FILE-PATHNAME*
Yes, there was a typo in my email. I used the real thing in my
software, that works on other implementations (SBCL, CLisp). I think
CL-PDF also relies on this, but I haven't tried CL-PDF with OpenMCL,
yet.

> I'd ordinarily assume that there's just a typo in your example and
> that you intended to reference *COMPILE-FILE-PATHNAME*, but I'm not
> aware of any case where *COMPILE-FILE-PATHNAME* would be set to or
> bound to NIL by the implementation during file compilation.

Note: my attempts where with the old 0.14p1 from Debian; since the
former debian maintainer has moved away and no one has taken over, 1.0
still isn't packaged. I've downloaded the tarball for 1.0 but got
short on time. Obviously, my not possessing a PPC machine and my only
having access to an antique Powerbook 3400c under Linux means I this
is all low priority to me: only a way to make a test once in a while,
in the hope of uncovering a bug in my code, of assessing the semantics
of something fishy, of making some performance comparison between
implementations.

My documents are compiled fastest with Exscribe on CLisp, then with
Scribe on JVM, then with Exscribe on OpenMCL, then on Exscribe on
SBCL. Unintuitive since I would have expected an opposite performance
order, as was the case on some CPU-intensive problem solvers I wrote
previously. I suppose Exscribe being quick and dirty does lots of
cons'ing and CLisp is more efficient about that (and/or keeping things
within cache), but I'd have to do a deeper performance analysis to
understand what's happening.

> > * Your implementation of backquotes doesn't work correctly in presence
> > of unquote-splicing. I won't cast any stone, since I realized the same
> > failure in my own implementation of quasiquote: it's easy enough to
> > have a stupid implementation that does lots of append's, but it's less
> > easy to do simplifications that do not break in presence of
> > unquote-splicing.
> >
> > Example, simplified from a very useful macro I use in exscribe:
> >
> > (defparameter *c '((list :x x) (list :y y)))
> >
> > ``(f ,@,@*c)
> >
> > I suppose you should steal the implementation from clisp or from
> > cmucl... they both work correctly.
>
> There's also Steele's 1985 reference implementation, which is about
> as old as OpenMCL's.  Steele's implementation yields the behavior
> that you expect; I'm not yet sure whether fixing this case is best
> done by using that code or ... simply fixing this case.
>
I'm sure that the double unquote-splicing is correct by the
definition, and SBCL and CLisp get it right. Actually, by
macroexpanding away one level of backquoting from CLisp, I could get
an expression that would work in OpenMCL. Still, I'm convinced that
OpenMCL is dead wrong and needs get fixed. So was fare-quasiquote, I
regret to say. Nested unquote-splicing is incompatible with some
simplifications that work well in absence of it. In practice, most
patterns I used were simple enough that I could match them with such
patterns as (cons (cons :foo x) y) instead of the more condensed
`((:foo ,@x) ,@y)... so I disabled the reliance on a reliable
quasiquote for now. Sigh. I think I'll make the next version of
fare-quasiquote a derivative of SBCL's code.


> You never subscribed to the bug-openmcl mailing list, so this and any
> other messages that you may have sent to that address were tossed out
> with the spam; as I explained earlier, I can't wade through the spam
> looking for on-topic messages from non-subscribers, because there's
> just too much spam and not enough time.
Yes, I understand that. That's the reason why I sent message to you
with bug-openmcl as Cc: -- because I knew that's the only way it would
go through without my subscribing to bug-openmcl. I don't use openmcl
often enough to be concerned with all the bugs that may be found about
it.

> I added you to a mailing list filter that allows you to send messages
> from this address without subscribing, so hopefully neither of us will
> have to waste further time on this.
Thanks! And sorry for the trouble.

Now back to coding. Thanks a lot for your code!

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Complexity is the hallmark of stupidity
        -- Erik Naggum