(Previous discussion continued)
Re: propositions, oppositions, and some minor details Jens Axel Søgaard 14 Sep 2004 12:54 UTC

Re: propositions, oppositions, and some minor details Jens Axel Søgaard 14 Sep 2004 12:54 UTC

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.
>
Since it is common to use (define-record foo) to make a disjointly typed
object, it is seems most natural to me, to let two separate evaluations
of (define-record foo) generate two disjoint types. If two programmers
use this idiom in two different libraries and accidently use the same name,
a program using both libraries at the same time will still work.

Winkelmann is right though, that this does provide a challenge for
implementations supporting separate compilation. I am not entirely
convinced that a refactoring is always possible. From my point of view,
the responsibility og getting this right belongs to the module system.
If both a.scm and b.scm needs to use a record type defined in d.scm,
then the module system should provide a way to instantiate d.scm
before the actual compilation a.scm starts. I thus see the problem (and
the solution) to be parallel to our (between Felix and I) discussion
about <http://www.scheme.dk/macros-and-modules2.txt>.

In short, I agree with Shinn that define-record should be generative,
but I acknowledge that there is an actual choice here.

--
Jens Axel Søgaard