Module Provides Syntax Properties Missing in Expanded Module

26 views
Skip to first unread message

Leif Andersen

unread,
Feb 4, 2016, 3:25:03 PM2/4/16
to racket-dev, Matthew Flatt
A module's syntax properties when fully expanded do a reasonable job
getting the requires and provides out. However, if I have something
defined (and provided) in a phase other than 0, it seems to be
missing. For example:

#lang racket

(require zordoz)

(define mod
#'(module foo racket/base
(#%plain-module-begin
(#%require (only racket/match match))
(#%provide x)
(#%provide (for-syntax y))
(define x 5)
(define-for-syntax y 6))))

(expand mod)

In the expanded module there is no syntax property for `y`, even
though it's provided for syntax.

Now, I could (and currently do) just recalculate this when I'm
compiling the module, but this seems a little bit silly to redo as the
macro expander seems to already have this information.

Is it possible to have all of a module's provides included when a
syntax object is expanded, and not just it's phase level 0 ones, or am
I missing something?

Thank you.

~Leif Andersen

Matthew Flatt

unread,
Feb 4, 2016, 3:48:21 PM2/4/16
to Leif Andersen, racket-dev
Phase-0 exports are available because those were the only kind of
exports when syntax properties were originally added to a `module`
expansion.

I almost added information for other phases when I recently added the
'module-body-inside-context and 'module-direct-for-meta-requires
properties. In the end, I skipped that addition; unlike the other
information, it seemed relatively easy enough to reconstruct exports
from a module's expansion.

So, I can fill out provided-identifier information if it seems
important, but it's somewhat tedious to add, and I'd prefer to leave it
out.

Leif Andersen

unread,
Feb 4, 2016, 5:29:31 PM2/4/16
to Matthew Flatt, racket-dev
Yeah, it seems easy enough to do it in the compiler by grabbing the
defines internal to the module, and do either for all external modules
that are (#%provide (all-from ...))`:

1. If the module is a module path, calling `module->exports` on it.
2. Or if it's a submod in the current compilation unit, compile it
first and grab it's provides then.

I'm more then happy to do that myself. I just thought it was already
being done in the macro expander.

Thank you.

~Leif Andersen
Reply all
Reply to author
Forward
0 new messages