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

[Mattias Engdegård]

6 aug. 2023 kl. 00.40 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

>> 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.

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.

> BTW, a related option would be to develop a new kind of macro-definition
> along the lines of what's used in Scheme, where the macro author doesn't
> need to worry about such issues because the macro knows which parts of
> the data it manipulates are chunks of code (potentially adorned with
> metainfo) and can take care of extracting the underlying unadorned code.

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.)