[racket-dev] Preserving source location in macro-generating macros, in collects

From: Neil Toronto (neil.toronto at gmail.com)
Date: Fri Oct 7 13:43:51 EDT 2011

On 10/07/2011 10:24 AM, Robby Findler wrote:
> On Fri, Oct 7, 2011 at 11:15 AM, Neil Toronto<neil.toronto at gmail.com>  wrote:
>> Here's the thing. When I first looked into it, I wasn't making a collection;
>> 'plot' was just a directory on my hard drive. I tried using
>> 'scribble/srcloc', and it kept not finding modules. So what I think is true
>> about it are often assumptions and inferences.
>> For example, I think that it wouldn't give me the freedom to present the API
>> in the order/grouping I want it in, for the cases where the best
>> order/grouping in the docs is different from the best order/grouping in the
>> code.
> I think there are hooks in there to make this pretty flexible. The
> framework docs use them to slice up things and move things around. You
> might take a look at how it is set up and see if something like that
> would work.

I'll take a look. Thanks!

>>> When a syntax object is compiled and written to a .zo file, all that
>>> information is stripped. You have to write use another function at
>>> compile time that walks over the syntax objects and records the source
>>> locations and then saves them in some way that is not a syntax object
>>> literal. Then restore them.
>> I was afraid of that. Probably not too hard, but not a cakewalk, either.
> There may be some library that I don't know about that helps with this.
> Robby

I looked around and didn't find anything immediately useful either, so I 
wrote a 'serialize-syntax' and 'unserialize-syntax'. Serializing doesn't 
store lexical context, so unserializing takes a context argument - it 
basically does a 'replace-context'. But I was already doing that anyway. 
It also serializes syntax properties that have symbol keys.

It works. My docs look nice again.

Neil T

Posted on the dev mailing list.