[Openmcl-devel] Re: persistence of xref info in fasl files.
entrox at entrox.org
Sun Jan 4 11:57:23 UTC 2004
On 03.01.2004, at 23:53, Gary Byers wrote:
> On Sat, 3 Jan 2004, Alan Ruttenberg wrote:
>> Here's an implementation. Gary, I don't really know which what the
>> place to put the hooks, so I've used advise where it seemed
>> appropriate. Please feel free to fix or tell me how to.
>> I came across one issue when doing this. If you have (defun foo ()
>> (flet ((bar ())) *baz*))
>> then you get a recorded xref from bar to *baz*. I think this should be
>> foo to *baz* since bar isn't global. If you disagree with that policy
>> the code needs to be reworked a bit.
> I can't remember whether I sent mail about this before the holidays,
> or who I would have sent it to if I did.
I think we talked about it on IRC before the holidays.
> <lots of interesting information snipped>
Is this written down somewhere? I remember something about an old
MCL internals document, but it seems to have been lost in the disk
> (It might take a while to come up with a reasonable policy here:
> is DOTIMES interesting ? It might have macroexpanded into "calls"
> to 1+, or =. Are those interesting ? Etc.) Once we've decided what's
> interesting, it's not too hard to ensure that everything that was
> interesting to the frontend shows up in the backend.
That's an interesting question. Right now, both cases can happen
on whether you're dealing with a compiler macro or an ordinary macro.
quite sub-optimal IMHO. Perhaps we can do something along the lines of
macroexpand and macroexpand-1, because I can see people being interested
in both answers.
> There are some possible advantages to using a separate data structure
> as Alan's code does as well. I'm not 100% convinced that the idea I'm
> proposing is entirely better, but I think that it's worth thinking
> further. It has always sort of struck me that (incomplete and
> XREF info's already there and there's a lot of it, and it seems more
> attractive to make it more complete and precise than to duplicate it.)
I agree with you in that it looks cleaner. The reason why I chose a
data structure was that I'm not familiar enough with compiler internals
actually do something like you proposed. You can easily confuse the
scheme by doing something like you did in your example. Getting oddballs
like these right would be really great, since all other XREFs I've
and Allegro) trip on them as well.
From what I gather, this would only store direct references (e.g. who
by or who is bound by). How would you get the inverse case? Right now
the information is stored in separate tables. Would this also get
where or would one need to walk all functions like ccl::callers does?
as this doesn't take very long and is probably only used interactively,
>> BTW, what does "indirect calls" mean?
> Maybe that bit 3 is set in the corresponding
> xref-constant-information-map ?
Exactly. I just copied the Allegro interface which distinguishes
and indirect calls e.g. (foo 1 2) is a direct, (mapcar #'foo '(1 2)) an
to FOO. At least that's what's written in the documentation, but after
trying it out,
it seems as if it doesn't detect these correctly 100% of times (not
given example in the doc...)
Speaking of documentation, I'd like to write a page or two about the
since I don't think it should change that much (apart from the
The HTML pages seem to be generated from Docbook sources, which I can't
find anywhere. Are they downloadable somewhere?
More information about the Openmcl-devel