Re: bindings for free identifiers in (ice-9 syncase)

[Neil Jerram]

Andy Wingo <address@hidden> writes:

> Hi Julian,
>
> Just to add to the melee, I have been thinking hard about this too.
> Somehow output produced by a macro must have its free identifiers scoped
> in the module that was current when the macro was defined.

I've been reaching that conclusion too.  (For others following this,
I've appended some notes / a draft email to explain why, after my
sig.)  There are a couple of relevant bits of R6RS.  From section 7.1:

  Bindings defined with a library are not visible in code outside of
  the library, unless the bindings are explicitly exported from the
  library. An exported macro may, however, implicitly export an
  otherwise unexported identifier defined within or imported into the
  library. That is, it may insert a reference to that identifier into
  the output code it produces.

And from section 9.2:

  If a macro transformer inserts a free reference to an identifier,
  the reference refers to the binding that was visible where the
  transformer was specified, regardless of any local bindings that may
  surround the use of the macro. 

I don't believe there's any guidance from the specs prior to R6RS,
because none of them had modules/libraries.

> This could mean that syntax objects need a new field, and that output
> should be serialized with the `@@' syntax, but I don't know right now.

It also means, I think, that a module/library has to have a lexical
effect.  Basically the reader needs to know what the current module is
at any point, and to mark each read identifier with that module.

Guile's modules are technically determined at eval time, so don't
conform to that.  On the other hand, the common practice, using
(define-module ...), and the fact that Guile reads and evaluates forms
from a file (or stdin) sequentially, together could give us a close
approximation to the necessary lexical effect.

Regards,
        Neil



Notes on the lexical effect thing, or "Hmmm...  I remember now that
this problem is actually harder than it looks."

It helps to consider define-macro, defmacro and
procedure->memoizing-macro first.  With all of these, it's clear that
you are really defining a procedure that will transform the supplied
expression into an expanded expression.  For example:

(define (foo-function a)
  ...)

(define-macro (foo-macro arg)
  `(foo-function ,arg))

(export-syntax foo-macro)

and then in another module, a call

(foo-macro bar)

will be expanded to

(foo-function bar)

At this point, the programmer thinks it is obvious that foo-function
should be looked up in the environment of the (define-macro ...) call,
and that bar should be looked up in the environment of the (foo-macro
...) call.  But as far as Guile is concerned, it now sees just
(foo-function bar), and has no idea that the environments for
foo-function and bar should be different.

And the same applies to (ice-9 syncase), because Guile's
implementation of syncase (from Dybvig) also boils down to defining a
transformer procedure.