Opened 11 years ago
Last modified 8 years ago
#1061 new enhancement
syntax-rules should be able to automatically determine implicit exports
Reported by: | Moritz Heidkamp | Owned by: | |
---|---|---|---|
Priority: | not urgent at all | Milestone: | someday |
Component: | expander | Version: | 4.8.x |
Keywords: | Cc: | Shawn Rutledge | |
Estimated difficulty: | hard |
Description
Given a module which exports some syntax which expands to an identifier which isn't explicitly exported and isn't itself a syntax identifier, implciit export of that identifier doesn't work:
;;; foo.scm (module foo (some-syntax) (import scheme) (define (some-implicitly-used-procedure x) (list x)) (define-syntax some-syntax (syntax-rules () ((_ x) (some-implicitly-used-procedure 'x)))) )
To trigger the error:
$ csc -s -J foo.scm $ csi -R foo -p '(some-syntax bar)' Error: unbound variable: some-implicitly-used-procedure
As can be witnessed in #1060, it works fine for implicitly exported syntax.
Change History (8)
comment:1 Changed 11 years ago by
comment:2 Changed 11 years ago by
Cc: | Shawn Rutledge added |
---|
comment:3 follow-up: 4 Changed 11 years ago by
AFAIK this is a known limitation in CHICKEN's module system. You'd have to use the (some-syntax some-implicitly-used-procedure)
syntax in the export list instead of some-syntax
to make this work.
comment:4 Changed 11 years ago by
Replying to sjamaan:
AFAIK this is a known limitation in CHICKEN's module system. You'd have to use the
(some-syntax some-implicitly-used-procedure)
syntax in the export list instead ofsome-syntax
to make this work.
Hm, now that you say it, the manual doesn't claim anything about automatic export of implicitly referenced identifiers. I guess we can just close #1060 and this ticket then?
comment:5 Changed 11 years ago by
Milestone: | 4.9.0 → 4.10.0 |
---|---|
Priority: | major → minor |
Type: | defect → enhancement |
Given that automatic export of implicitly referenced identifiers is an undocumented feature of the module system as of now, this ticket should be considered a feature request instead.
comment:6 Changed 9 years ago by
Milestone: | 4.10.0 → 4.11.0 |
---|
comment:7 Changed 9 years ago by
Milestone: | 4.11.0 → someday |
---|---|
Priority: | minor → not urgent at all |
Summary: | Implicit export of identifiers only works for syntax → syntax-rules should be able to automatically determine implicit exports |
I don't think this can be made to work in the general case. The problem here is that if you construct an identifier name on the fly, it is possible to generate arbitrary procedure/variable names. That means potentially everything in a module should be considered "implicitly exported".
I think it works for syntax because that runs fully interpreted inside the compiler, which means that (currently) nothing is optimized away, so all the definitions are kept around. It's more of a bug really that this works at all (and we may consider making it more strict to reduce confusion).
That is a problem because it means none of the identifiers in a module would be eligible for inlining. Performance would suffer too much.
This is the reason we have the special syntax for marking procedures as belonging to a macro. If you change it to the following, your example works:
;;; foo.scm (module foo ((some-syntax some-implicitly-used-procedure)) (import scheme) (define (some-implicitly-used-procedure x) (list x)) (define-syntax some-syntax (syntax-rules () ((_ x) (some-implicitly-used-procedure 'x)))) )
I believe it may be possible to do this automatically for syntax-rules, but it would require an additional mechanism that one could also use with other macro expansion systems (like the bindings
egg). In the end that would not be very different than doing this manually in the "indirect export" list, but it would be quite a bit of work.
So it's more something for a wish-list rather than something we should fix ASAP.
comment:8 Changed 8 years ago by
Estimated difficulty: | → hard |
---|
Fixing it in the general case would be insane, but we might be able to improve a few edge cases.
also affects Version 4.8.3 (rev ba01911)