[Scheme-reports] EVAL Andre van Tonder (23 Apr 2011 23:47 UTC)
[Scheme-reports] What happened to (UNQUOTE <expression> ...) Andre van Tonder (24 Apr 2011 00:04 UTC)
[Scheme-reports] Are generated toplevel definitions secret? Andre van Tonder (24 Apr 2011 00:15 UTC)
[Scheme-reports] COND, CASE, AND, ... macros are buggy Andre van Tonder (24 Apr 2011 00:24 UTC)
[Scheme-reports] Buggy definition of BEGIN Andre van Tonder (24 Apr 2011 00:33 UTC)
Re: [Scheme-reports] Buggy definition of BEGIN Jussi Piitulainen (24 Apr 2011 06:55 UTC)
[Scheme-reports] Restrictions on internal BEGIN? Andre van Tonder (24 Apr 2011 01:45 UTC)
Re: [Scheme-reports] Restrictions on internal BEGIN? Jussi Piitulainen (24 Apr 2011 07:20 UTC)
[Scheme-reports] Toplevel import scoping Andre van Tonder (24 Apr 2011 02:02 UTC)
Re: [Scheme-reports] Toplevel import scoping Alex Shinn (24 Apr 2011 02:44 UTC)
Re: [Scheme-reports] Toplevel import scoping Aaron W. Hsu (29 Apr 2011 17:11 UTC)
Re: [Scheme-reports] Toplevel import scoping Aaron W. Hsu (29 Apr 2011 17:10 UTC)
Re: [Scheme-reports] Are generated toplevel definitions secret? Andy Wingo (24 Apr 2011 13:40 UTC)
Re: [Scheme-reports] Are generated toplevel definitions secret? Andre van Tonder (24 Apr 2011 15:53 UTC)
(missing)
(missing)
(missing)
Re: Are generated toplevel definitions secret? Aaron W. Hsu (24 May 2011 18:51 UTC)
Re: [Scheme-reports] Are generated toplevel definitions secret? Sztefan Edwards (25 May 2011 14:32 UTC)
Re: Are generated toplevel definitions secret? Aaron W. Hsu (25 May 2011 20:03 UTC)
Re: [Scheme-reports] Are generated toplevel definitions secret? Perry E. Metzger (07 Nov 2011 18:40 UTC)
Re: [Scheme-reports] Are generated toplevel definitions secret? Perry E. Metzger (07 Nov 2011 18:45 UTC)
Re: [Scheme-reports] What happened to (UNQUOTE <expression> ...) Andre van Tonder (24 Apr 2011 03:10 UTC)
Re: [Scheme-reports] EVAL Alex Shinn (24 Apr 2011 02:10 UTC)
Re: [Scheme-reports] EVAL John Cowan (24 Apr 2011 06:56 UTC)

Re: [Scheme-reports] Are generated toplevel definitions secret? Andy Wingo 24 Apr 2011 13:39 UTC

On Sun 24 Apr 2011 02:14, Andre van Tonder <andre@het.brown.edu> writes:

> R5RS didn't specify this, which was always a very annoying obstacle to
> portability.  E.g.,
>
>     (define x 1)
>     (let-syntax ((foo (lambda (e)
>                         (syntax (begin
>                                   (define x 2)
>                                   x)))))
>       (foo))  ;==> 2
>     x         ;==> NOT SPECIFIED IF IT SHOULD BE 1 or 2
>
> It seems from my reading on p. 15 that R7RS doesn't specify it either.
>
> In otehr words, definitions introduced in macros can possibly shadow toplevel
> bindings, which is a major obstacle to safe hygienic macro programming.

How does this relate to modules and separate compilation?  I haven't
figured out a good way to implement this yet.

For example, in a.scm you have:

    (module (a)
      (export x y)
      (begin
        (define-syntax define-constant
          (syntax-rules ()
            ((_ var init)
             (begin
               (define val init)
               (define-syntax var (identifier-syntax val))))))

        (define-constant x 10)
        (define-constant y 20)))

Then in b.scm you have:

    (module (b)
      (import (a))
      (begin
        (display x) (newline)
        (display y) (newline)))

So let's say you compile a.scm to a.so, and then b.scm to b.so.  The
`begin' in module A expands to something like:

    (begin
      (define val-1098321098 10)
      (define-syntax x (identifier-syntax val-1098321098))
      (define val-1243098329 20)
      (define-syntax y (identifier-syntax val-1243098329))

The numbers indicate some attempt at producing a globally-unique
gensym, to preserve hygiene.

But then if you recompile a.scm, to a.so, you would have to generate the
same gensyms, or b.so will fail to link when it is loaded later -- so
the gensyms aren't quite random...

Guile does not currently introduce hygienic bindings for introduced
toplevel identifiers, for this reason.  I think it's the same in
Chicken's case, but they can tell you more about that.

See also:

    http://thread.gmane.org/gmane.lisp.guile.devel/11722
    http://thread.gmane.org/gmane.lisp.guile.devel/12244

I would be happy to implement this behavior if I knew how.  As it is, we
need to treat introduced names as API, which means that we can't
uniquify them.

Andy
--
http://wingolog.org/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports