Re: Confusing problems with (ice-9 syncase) and sc-expand3.

[Marius Vollmer]

Rob Browning <address@hidden> writes:

> However, when I try to get this to work right, I get unexpected
> behavior.  In particular, if I try to have a "compilation" module that
> uses sc-expand3, it doesn't work right.  Client code can't just
> (use-modules (test-compiler)).  They must also (use-modules (ice-9
> syncase)).  This is true, even if I try and export *all* of syncase's
> public symbols from the test-compiler module.

I've got it, I think.  The problem was that `module-export!' (which
underlies `export') always clones the exported variables.  Syncase
keys important properties on variables, and it gets confused when
variables are duplicated.

I fixed this by changing `module-export!' so that it doesn't clone
variables any longer.

I think we could extend the semantics of the module system so that it
binds symbols not only to variables, but also to other things, like
syntax transformers.  This is different from storing special #<macro>
objects in variables, and would be the right thing IMO.

> For example.  I have a dummy module to demonstrate called rlb-dummy,
> and it just says:
> 
>   (define-module (ice-9 rlb-dummy))
>   (use-modules (ice-9 syncase))
> 
>   ;; re-export all of syncase's public symbols
>   (module-for-each
>    (lambda (name binding)
>      (display "Exporting ") (display name) (newline)
>      (module-export! (current-module) (list name)))
>    (module-public-interface (resolve-module '(ice-9 syncase))))

This works now, but it does not work when you don't re-export syncase.
This is kind of right, since `eval-when' is defined in (ice-9
syncase), and you don't see it unless you use that module.  Thus, it
shouldn't be recognized as a special form either.