Thanks, Ryan, that info is helpful, although it's missing most of the
reasons I've had to partition one library into several modules (macro
transformers).
As people have mentioned before, there seems to be a theoretical brick
wall preventing these tools from seeing references that likely will be
used in the results of macro transformations. I don't understand that
in all cases. For one example, the transformers often have templates
that should know many of the symbols and exactly where they're coming
from. (Is this information from templates lost too soon? Is the
information from templates not as precise as I assumed?) For another
example (or possibly the same thing), these tools seem to be missing
references in the code of "syntax-parse" productions that is outside
templates and that I'd think is unambiguous.
BTW, a student who is bored over the summer could do worse than to
enhance the Module Browser in some other ways. First low-hanging fruit
step might be to put the information from "check-requires" into tooltips
on the arrows. Then there's a lot one could do with graph drawing.
And, as a small graphics tweak, you can make it skip redundant repaints
queued up when dragging. (Summer is good for this. More than a little
sun exposure will just age your skin prematurely and give you melanoma,
anyway.)
Neil V.
Ryan Culpepper wrote at 05/23/2012 02:28 PM:
On 05/23/2012 11:13 AM, Neil Van Dyke wrote:
In the Module Browser, has anyone tried annotating the graph edges with
imported symbols that are actually referenced by the importing module?
Maybe further annotate those symbols with phases?
You can get this information (in text form) from the check-requires
utility. You may find the code in
macro-debugger/analysis/check-requires (and its dependencies) useful
if you want to add this information to the module browser. Getting the
set of references is actually somewhat tricky, and I think my code
does as good a job as possible.
Ryan
____________________
Racket Users list:
http://lists.racket-lang.org/users
