Re: porting from Ikarus to PLT

Abdulaziz Ghuloum wrote:
Derick Eddington wrote:
On Oct 28, 3:44 am, Jens Axel Soegaard
What happens in the following situation:

Library A:

(define-syntax foo (lambda (stx) ---1))

Library B imports A:

(define-syntax foo (lambda (stx) ---2))

(define-syntax bar (lambda (stx) --- foo ---))

Will PLT and Ikarus behave the same here?

No:

I was a bit unclear on how B imports A (because I didn't
think the question through).

Let's try a few examples in the "Pretty Big" language.
First let's try Derrick's example, which gave the
provoked the exception "multiple definitions of identifier"
in Ikarus.

(module a scheme
(provide foo)
(define-syntax foo (syntax-rules () [(_) "A:foo"])))

(module b scheme
(require-for-syntax 'a)
(provide foo bar)
(define-syntax foo "b:foo")
(define-syntax bar (lambda (_) #`'(b:bar #,(foo)))))

(require 'b)
(bar)

expand: unbound identifier in module (in the transformer
environment, which does not include the macro definition
that is visible to run-time expressions) in: foo
(the use of foo i.e. (foo) is colored red)


Now let's try importing A in a different phase:

(module a scheme
(provide foo)
(define-syntax foo (syntax-rules () [(_) "A:foo"])))

(module b scheme
(require 'a)
(provide foo bar)
(define-syntax foo "b:foo")
(define-syntax bar (lambda (_) #`'(b:bar #,(foo)))))

(require 'b)
(bar)

This gives the error:

module: identifier is already imported in: foo
(the foo in module B is colored red)

Finally let's import A with (for-meta 1 a)

(module a scheme
(provide foo)
(define-syntax foo (syntax-rules () [(_) "A:foo"])))

(module b scheme
(require (for-meta 1 'a))
(provide foo bar)
(define-syntax foo "b:foo")
(define-syntax bar (lambda (_) #`'(b:bar #,(foo)))))

(require 'b)
(bar)

This runs and gives:

(b:bar "A:foo")


What I was hoping was to find a situation similar to:

> MzScheme does not like it if you do:
> (define-syntax foo (lambda (stx) ---))
> (define-syntax bar (lambda (stx) --- foo ---))
> while Ikarus allows it. Ikarus says: hey, we have the transformer,
> so, we might as well make it available. MzScheme says: hey, if you
> can't access run-time variables, then you can't access run-time
> macros either.

Since the first example gave this error,

expand: unbound identifier in module (in the transformer
environment, which does not include the macro definition
that is visible to run-time expressions) in: foo
(the use of foo i.e. (foo) is colored red)

I think the conclusion is that MzScheme detects the situation,
and thus Matthew deliberately chose this behaviour. But why?


Regardless of phasing semantics, R6RS specifies the following:

Quote from R6RS:

An identifier can be imported with the same local name from two or more libraries or for two levels from the same library only if the binding exported by each library is the same (i.e., the binding is defined in one library, and it arrives through the imports only by exporting and re-exporting). Otherwise, no identifier can be imported multiple times, defined multiple times, or both defined and imported. No identifiers are visible within a library except for those explicitly imported into the library or defined within the library.

End of Quote

So, the you cannot have foo both defined in a library and at the same
time imported into that library. Similarly, you cannot have two
different foos defined in two different libraries imported into the
same place, regardless of phasing.

E.g., if you have:

(library (A) (export x) (import (rnrs)) (define x ---))

and

(library (B) (export x) (import (rnrs)) (define x ---))

then the following is not a valid library definition:

(library (C) (export) (import (for (A) run) (for (B) expand)))

And indeed, it fails under all of Ikarus, Larceny, and Ypsilon
with a clear description of the error.

You need to confirm with Matthew whether this behavior of mzscheme
was intended or just an oversight.

I think it was an oversigt, due to the error messages in the
first two examples above.

--
Jens Axel Søgaard

.

Relevant Pages

  • Multiple import of the same module under different names
    ... situations (absolute imports, explicit relative imports, implicit ... Failed to import foo from mod2: ... from subpkg import foo ...
    (comp.lang.python)
  • Re: Quickly exiting from nested calls
    ... functions) detects an error serious enough that whatever foo ... in the library opens a stream, ... bar2 breaks the content of the buffer into ... for libraries for which such a design is considered ...
    (comp.lang.c)
  • dlopen and -+ option and -bexpall
    ... libraries which depends on static libraries linked into our executable ... dlsym(ptr, "foo") ... bar.c print "bar" -> produce libbar.a as archive file ... void main ...
    (comp.unix.aix)
  • Re: SVN/CVS and Branching
    ... Say my project is called foo, ... So there are imports that may look like `import foo.bar` ... your python projects. ... level module starting imports all over the place, ...
    (comp.lang.python)
  • Re: SVN/CVS and Branching
    ... think of is that I believe svn will store links correctly (while CVS ... is to branch the entire project, leave the foo module ... So there are imports that may look like `import foo.bar` ... your python projects. ...
    (comp.lang.python)