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

Previous Next

Full log

Message #92 received at 65017 <at> debbugs.gnu.org (full text, mbox):

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

>> I'd even like it to try and replace uses of `eq/eql` with `equal` in
>> those cases where we want to overlook differences in symbol-positions, so
>> that we can eventually get rid of `symbols-with-pos-enabled` which
>> I consider as a wart.
> I agree it would be wonderful if we could restore `eq` to its former
> simplicity and speed but is that easily achievable at this point?

I didn't say it would be easy.  But I think it's feasible (tho it will
take many years).

> For example, what about macros that compare arguments with `eq`?

Yes, these are the cases where we need to "replace uses of `eq/eql` with `equal`".

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

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.


        Stefan

Previous Next

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