Opened 4 years ago

Last modified 15 months ago

#1061 new enhancement

syntax-rules should be able to automatically determine implicit exports

Reported by: syn Owned by:
Priority: not urgent at all Milestone: someday
Component: expander Version: 4.8.x
Keywords: Cc: ecloud
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 4 years ago by ckeen

also affects Version 4.8.3 (rev ba01911)

comment:2 Changed 4 years ago by ecloud

  • Cc ecloud added

comment:3 follow-up: Changed 4 years ago by 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 of some-syntax to make this work.

comment:4 in reply to: ↑ 3 Changed 4 years ago by syn

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 of some-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 4 years ago by syn

  • Milestone changed from 4.9.0 to 4.10.0
  • Priority changed from major to minor
  • Type changed from defect to 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 2 years ago by sjamaan

  • Milestone changed from 4.10.0 to 4.11.0

comment:7 Changed 2 years ago by sjamaan

  • Milestone changed from 4.11.0 to someday
  • Priority changed from minor to not urgent at all
  • Summary changed from Implicit export of identifiers only works for syntax to 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 15 months ago by sjamaan

  • Estimated difficulty set to hard

Fixing it in the general case would be insane, but we might be able to improve a few edge cases.

Note: See TracTickets for help on using tickets.