I've spent the last couple weeks trying to what should have been a simple task, and I feel the need to publicly whine and complain about how hard it has turned out to be.
All I want is to fully expand a mzscheme module definition and then do some syntactic rewriting on it. I expected to be able to write something like this:
(define optimize (λ (code) (rewrite (expand code)))
Oh, how naive I was...
I have learned about the difference between expand, expand-syntax, and local-expand. I have learned that local-expand requires its caller to specify whether it's in an expression context, module context, toplevel context, or some weird list context whose purpose I have yet to understand.
I have learned about the all-important datum->syntax-object function, which is the only way to make mzscheme realize that when a function appears in function-call position, it is meant to be called.
I have learned that telling local-expand that it's in a module context does not mean that you can expand code that actually came from a module context, because the "module" macro has special handling for define-values.
I have learned about the difference between module-identifier=?, bound-identifier=?, and free-identifier=?.
I have learned that a define-for-syntax binding cannot be exported from a module. You must either suck callers into the same module, or find some way to rewrite it as a regular define.
I have read about require-for-template half a dozen times, and I still don't understand its purpose. I have learned about namespaces, but I haven't yet seen the need to use them.
I have learned that macros can be expanded on demand, by using syntax-local-value to retrieve their syntax transformer. I currently count this discovery as a minor victory. I have learned that for some reason this does not insert #%app, #%top, or #%datum wrappers. I do not know where these wrappers usually come from.
I have learned that if you attempt to rewrite an expanded expression, then you will be sent to certificate hell. I am currently reading about certificates. In order to understand them I must learn about "marks" and "inspectors". I must decipher obscure writings, such as:
To check access to an unexported identifier, the compiler or macro expander checks each of the identifier's marks and module bindings; if, for some mark, the identifier's enclosing expressions include a certificate with the mark, the identifier's binding module, and with an inspector that controls the module's invocation (as opposed to the module's declaration; see again section 9.4), then the access is allowed.
And it is about at this point that I realize how far I have come, and I begin to question why the journey was required in the first place.
Never let it be said that the mzscheme macro & module system is simple.
Posted on July 22, 2006 03:14 PM
More languages articles
Thanks for a beautiful site! I have added you in elected!
Necessarily I shall advise your site to the friends!
http://shsrth.hostxd.com
http://fgfhat.byteact.com
http://fgfhat.byteact.com
http://xgfnxg.4qh.info
http://vbxhg.fastsit.com
http://xfghgf.fasthoster.info
http://fgfhat.byteact.com
http://sexy.freeinternethosting.info