This page is part of the web mail archives of SRFI 57 from before July 7th, 2015. The new archives for SRFI 57 contain all messages, not just those from before July 7th, 2015.
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