[Openmcl-devel] Re: persistence of xref info in fasl files.

[Oliver Markovic]

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


> (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 
depending
on whether you're dealing with a compiler macro or an ordinary macro. 
That's
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 
> about
> further.  It has always sort of struck me that (incomplete and 
> imprecise)
> 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 
separate
data structure was that I'm not familiar enough with compiler internals 
to
actually do something like you proposed. You can easily confuse the 
current
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 
tried (LW
and Allegro) trip on them as well.
 From what I gather, this would only store direct references (e.g. who 
is called
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 
stored some-
where or would one need to walk all functions like ccl::callers does? 
Seeing
as this doesn't take very long and is probably only used interactively, 
I guess
that's OK.


>> 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 
between direct
and indirect calls e.g. (foo 1 2) is a direct, (mapcar #'foo '(1 2)) an 
indirect call
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 
even their
given example in the doc...)

Speaking of documentation, I'd like to write a page or two about the 
XREF API,
since I don't think it should change that much (apart from the 
implementation).
The HTML pages seem to be generated from Docbook sources, which I can't
find anywhere. Are they downloadable somewhere?

--
   Oliver Markovic