Re: Signature matching question?

From: Xavier Leroy (Xavier.Leroy@inria.fr)
Date: Fri Feb 19 1999 - 16:29:30 MET


Date: Fri, 19 Feb 1999 16:29:30 +0100
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Manuel Fahndrich <maf@microsoft.com>,
Subject: Re: Signature matching question?
In-Reply-To: <25983782061AD111B0800000F86310FE1026CAFD@RED-MSG-42>; from Manuel Fahndrich on Thu, Feb 11, 1999 at 05:47:39PM -0800

> I've run into the following problem with signature matching.
>
> module type FOO =
> sig
> type bar
> module A : sig val fresh : unit -> bar end
> end
>
> module Foo : FOO =
> struct
> module A =
> struct type t = {foo: int} let fresh () = {foo=1} end
> type bar = A.t
> end
>
> [... Signature mismatch ...]

> Is this intended behavior, or a bug? I would assume that within a module,
> delcarations are treated as an unordered set.

It is a bug. The intent is, as you say, to perform signature matching
independently of the order of module components. The typing rules
currently implemented get it right when there are only type and value
components, something is wrong with nested modules as in your example.

Indeed, your example type-checks when rewritten as follows:

> module Foo1 =
> struct
> module A =
> struct type t = {foo: int} let fresh () = {foo=1} end
> type bar = A.t
> end
> module Foo : FOO = Foo1

The naming of the structure allows the type-checker to get its type
names right.

It's not obvious how to change the signature matching rules, though,
so I don't promise a quick fix.

- Xavier Leroy



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:20 MET