Opened 7 weeks ago

Last modified 12 days ago

#1832 new defect

Exported syntaxes are not fully hygienic

Reported by: Dominik Joe Pantůček Owned by:
Priority: major Milestone: someday
Component: compiler Version: 5.3.0
Keywords: syntax hygiene modules Cc:
Estimated difficulty: hard

Description

Modules exporting syntaxes generated by syntaxes are not fully hygienic as the serialization into module-name.import.scm uses strip-syntax on module's sexports.

Minimal (Working) Example

Attached as follows:

mwe-ok.scm - single file where the macros show expected behavior

mwe-ko-common.scm - module with the macro generating macros
mwe-ko-one.scm - first macro generated by the macro from common module
mwe-ko-two.scm - second macro generated by the macro from module "one"
mw-ko-run.scm - should behave like mwe-ok.scm, shows binding collisions

How to run

Reference (working) module:

csi -q -b mwe.ok.scm

Multiple modules with problems:

csc -P -J mwe-ko-common.scm
csc -P -J mwe-ko-one.scm
csc -P -J mwe-ko-two.scm
csi -q -b mwe-ko-run.scm

Attachments (5)

mwe-ok.scm (507 bytes) - added by Dominik Joe Pantůček 7 weeks ago.
Working example.
mwe-ko-common.scm (491 bytes) - added by Dominik Joe Pantůček 7 weeks ago.
Non-working example, module with base syntax.
mwe-ko-one.scm (91 bytes) - added by Dominik Joe Pantůček 7 weeks ago.
Non-working example, module with first generated syntax.
mwe-ko-two.scm (87 bytes) - added by Dominik Joe Pantůček 7 weeks ago.
Non-working example, module with second generated syntax.
mwe-ko-run.scm (78 bytes) - added by Dominik Joe Pantůček 7 weeks ago.
Non-working example, main module to run.

Download all attachments as: .zip

Change History (7)

Changed 7 weeks ago by Dominik Joe Pantůček

Attachment: mwe-ok.scm added

Working example.

Changed 7 weeks ago by Dominik Joe Pantůček

Attachment: mwe-ko-common.scm added

Non-working example, module with base syntax.

Changed 7 weeks ago by Dominik Joe Pantůček

Attachment: mwe-ko-one.scm added

Non-working example, module with first generated syntax.

Changed 7 weeks ago by Dominik Joe Pantůček

Attachment: mwe-ko-two.scm added

Non-working example, module with second generated syntax.

Changed 7 weeks ago by Dominik Joe Pantůček

Attachment: mwe-ko-run.scm added

Non-working example, main module to run.

comment:1 Changed 12 days ago by sjamaan

The problem is clearly strip-syntax - that should not be used. It's used because we don't want to emit gensymed names, as those won't be resolvable when loading the import library (that's a different compilation pass, which doesn't have the same aliases database).

A potential solution might involve something akin to canonicalize-expression on the syntax form, leaving any unresolved symbols as is (so keeping the gensymed aliases in place). There'd still be a risk of capture since those names won't be gensymed anymore, but it'd be less likely since they'd still be obfuscated.

I think if this works, we won't need the eval for the module-import-forms anymore either, as everything will be fully resolved.

Finally, I think we'd do well to simplify this example a bit. The code is quite hard to follow.

comment:2 in reply to:  1 Changed 12 days ago by sjamaan

Replying to sjamaan:

A potential solution might involve something akin to canonicalize-expression on the syntax form

Hm, after thinking about this some more, I believe this would require teaching the compiler about syntax-rules and how to canonicalize its "templates".

Somehow that "feels" Very Wrong - we don't want to have to special case something like this. Users should be able to add their own expanders without requiring a special case for it.

Note: See TracTickets for help on using tickets.