On Tue, 14 Sep 2004, Alex Shinn wrote:

>At Mon, 13 Sep 2004 10:33:15 +0200, Felix Winkelmann wrote:

>> That leads me to another issue: What about separate compilation?
>> The problem is here that I might have two source-files, using the
>> same record type, compiled separately in two different instances of
>> the compiler. How can I make sure that
>>
>> ; a.scm
>>
>> (define-record foo ...)
>>
>> ; b.scm
>>
>> (define-record foo ...)
>>
>> Refer to the same type?

> My assumption would be that they in fact refer to different types, and
> if you wanted both to refer to the same foo definition then you would
> refactor that into c.scm.  This is based on treated records as (at
> least potentially) first class objects, as opposed to C where they are
> simple header declarations and it doesn't matter how often you
> redefine them.

My assumption is that, if these two definitions occur in the same lexical
scope (or both at top level), they are an error.  Implementations may
signal an error or assign it some random semantics (probably by treating
the second form as mutation rather than definition).  If they occur in
disjoint lexical scopes, they refer to different types, both named
"foo".  And if one occurs inside the other, it creates a local
definition for "foo" that shadows the one in the larger scope.

We don't really have a firm model yet for the top-level namespace in
separate compilation, and issues like this make it show.  There are
many configuration sublanguages for managing top-level namespace in
different implementations: usually "export" or "provide" or something
designates things to go into the top level namespace, and other
definitions in a file are handled as though in a "let" statement
having the file beginning and ending be the open and close parens.

				Bear