bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>>> Separate data structures for locations might be an option worth exploring,
>>> keeping the actual s-expressions unadorned. Consider a reader mode that also
>>> produces a table mapping cons cells read to their locations, for example.
>> When Alan looked at it, the cost seemed prohibitive.
> I'm not aware of the details but think that it may be worth revisiting.

Feel free :-)

> The only serious difficulty a priori appears to be keeping locations in
> transformed code, but most of our diagnostics are issued on code before Lisp
> optimisations so this should mostly matter to macro-expansion.

We shouldn't emit errors/warnings from byte-opt, indeed, so that part
doesn't need to preserve the info, but we still need to preserve it
at least through macro-expansion and cconv.

> Yes, Scheme doesn't have much problems with user code manipulating Lisp as data.
> But what do actual Lisp compilers do? Do they perform a slow re-read when
> until they get to the location they want, when they need to issue
> a diagnostic? (Relint does something similar, in fact.)

Scheme's macro system has a notion of "syntactic object" (i.e. an sexp
combined with metainfo), and the macros make it clear when you're
looking inside a syntactic object or when you're building a new
syntactic object.

Don't know what Common Lisp systems do with `defmacro`, sorry.
I know Gambit Scheme has "defmacro" (under the name `define-macro`) but
it treats it as "second class citizen" in the sense that when using
a macro defined with `define-macro`, the metainfo is just lost.


        Stefan