Summary

cannot import procedure from one egg during macro expansion in another egg.

Metadata

Attachments

Description

I have two eggs, m0 and m1.

m0 defines a single procedure, f0.

m1 contains an ir-macro make-f1, which defines the procedure f1. It calls m0#f0 during macro expansion.

I get the following error during macro expansion, claiming f1 is undefined:

Error: during expansion of (make-f1 ...) - unbound variable: f0

I believe f0 is bound, and that this expansion should succeed. See attached files.

my csc version:

--(>:)-- csc -V (c) 2008-2013, The Chicken Team (c) 2000-2007, Felix L. Winkelmann Version 4.8.0.5 (stability/4.8.0) (rev f60b2b6) openbsd-unix-gnu-x86 [[|manyargs dload ptables ]] compiled 2013-12-10 on celia.c0redump.org (OpenBSD)

Changes and comments

[2013-12-28 00:58:05 UTC] alanpost attached m0.scm (description=m0.scm)

[2013-12-28 00:58:14 UTC] alanpost attached m1.scm (description=m1.scm)

[2013-12-28 00:58:26 UTC] alanpost attached doit (description=doit)

[2013-12-28 00:58:37 UTC] alanpost attached main.scm (description=main.scm)

[2013-12-28 01:01:05 UTC] alanpost changed priority from major to not urgent at all

[2013-12-28 01:01:05 UTC] alanpost wrote:

evhan, on IRC, found the appropriate invocation:

(begin-for-syntax

(require-library m0))

(import-for-syntax m0)

Is this still a bug? Since there is a workaround, I'm dropping the priority.

[2013-12-28 01:05:22 UTC] alanpost set cc to alanpost@sunflowerriver.org

[2013-12-28 03:54:36 UTC] evhan wrote:

I think the important difference in the working paste is actually just having (import scheme) before the begin-for-syntax form. As long as that's true, any other permutation of the imports works:

 (import-for-syntax scheme)
 (import-for-syntax chicken)
 (import scheme)
 (begin-for-syntax (use m0))
 (import chicken)
 ;; ... whatever else ...

This is because the scheme namespace is the one that provides begin-for-syntax, so without it the begin-for-syntax isn't expanded and m0 isn't loaded in m1 at expansion time (making f0 a run-of-the-mill unbound variable). I'd call this a gotcha rather than a bug, though maybe a warning for forms that are probably meant to be syntax like this (such as the {import,require,use}[[-for-syntax]|] family) would be helpful?

[2015-09-26 11:21:41 UTC] evhan set resolution to invalid

[2015-09-26 11:21:41 UTC] evhan wrote:

Closing as invalid after looking into this again. The current behaviour is as expected, just a bit obscured by the macrology.

[2015-09-26 11:21:41 UTC] evhan changed status from new to closed