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

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Alan Mackenzie <acm <at> muc.de>, 65017 <at> debbugs.gnu.org, Eric Marsden <eric.marsden <at> risk-engineering.org>
Subject: bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function
Date: Sun, 6 Aug 2023 12:47:15 +0200

6 aug. 2023 kl. 00.40 skrev Stefan Monnier <monnier <at> 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.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.