GNU bug report logs -
#65017
29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function
Previous Next
Full log
Message #113 received at 65017 <at> debbugs.gnu.org (full text, mbox):
>>> 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
This bug report was last modified 1 year and 337 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.