Re: [Sbcl-devel] SBCL 1.2.2 breaks social contract that backquote conceptually might as well be a macro

[Pascal J. B. <pj...@in...>]

Jean-Philippe Paradis <hex...@gm...> writes:

> Hello, I subscribed to this mailing list just to post this message,
> as it's important enough to discuss on sbcl-devel, I'm told.
>
> I'm a perfectionist so I'll try to cut this short before I'm tempted
> to write a novel. I have my hands quite full at the moment and I know
> I could argue this thing much more eloquently, but really I think the
> point I'm about to make is pretty obvious.
>
> So, SBCL 1.2.2 has recently been released, and it broke backquote,
> and I'm not happy about that.
>
> How did it break backquote? By hiding user-supplied code inside
> implementation-defined objects. Now there's this whole discussion of
> how it breaks so-called "naîve cons-walking", which has worked very
> well for decades, thank you very much, and on the other side, "oh, so
> you thought you could just walk the conses to get at your
> user-supplied code, too bad for you, haha". But here's the CENTRAL
> POINT to this matter:
>
> ---------------------
>
Backquote IS specified as a reader-macro, and it
could read as any form.

I don't have the latest sbcl version, but I infer from what you're
writing that now #\` reads as a form containing a literal object such as
a structure or worse, of some implementation specific type, that
contains sub-expressions from your backquoted source.

This is explicitely allowed by the standard.  If you code expected
anything from the form read by #\`, then it wouldn't be conforming.

I'd only notice that using a literal implementation specific object or
structure in the result of backquote seems to me to be an implementation
complication (since it will require at the very least, a make-load-form
method), but I've not read the April discussion mentionned by
Christophe.



If you want to process the form read by #\` conformingly, you should
provide you own reader macro for #\`.  There are various implementations
floating arround along with various readers.  As long as the
implementation you use to read backquote forms is conforming, it should
make no difference, and if you use your own reader macro, you can
process its output as you wish while with conforming code.




> We couldn't possibly be having this discussion if backquote was a
> macro, which conceptually, it might as well be.
>
> If backquote was a macro instead of a reader-macro, there's no way
> SBCL could hide user-supplied code inside implementation-dependent
> objects BEFORE macroexpansion.

Of course there would be!

    (defmacro ` (&rest forms)
      `(system:expand-backquote ',(make-internal-backquote-object forms)))




-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk