RFH: Values do not match: val bar1 : Foo.foo_t is not included in val bar1 : Foo.foo_t

RFH: Values do not match: val bar1 : Foo.foo_t is not included in val bar1 : Foo.foo_t

[Goswin von Brederlow]

Hi,

I'm playing around with packs and ways to avoid having to duplicate
module signatures all over the place. So I came up with the following
idea: Each module declares an external and internal module type and
restricts itself to the internal type. The pack then further restricts
the module to the external type.

But then I get a type error I can't make heads or tails of:

File "pack.cmx", line 1, characters 0-1:
Error: The implementation (obtained by packing)
       does not match the interface pack.mli:
       Modules do not match:
         sig
           module type Extern = sig val bar1 : Foo.foo_t end
           module type Intern =
             sig val bar1 : Foo.foo_t val bar2 : Foo.foo_t end
           module I : sig val bar1 : Foo.foo_t val bar2 : Foo.foo_t end
           val bar1 : Foo.foo_t
           val bar2 : Foo.foo_t
         end
       is not included in
         sig val bar1 : Foo.foo_t end
       Values do not match:
         val bar1 : Foo.foo_t
       is not included in
         val bar1 : Foo.foo_t
make: *** [all] Error 2


Can anyone explain that to me?

MfG
        Goswin
--

Here is a simple example that gives the above error:
(also on http://mrvn.homeip.net/t/)

---------------[ Makefile ]---------------
all:
        ocamlopt -for-pack Pack -c foo.ml
        ocamlopt -for-pack Pack -c bar.ml
        ocamlopt -c pack.mli
        ocamlopt -pack -o pack.cmx foo.cmx bar.cmx

clean:
        rm -f *.o *.cmx *.cmi *~

---------------[ bar.ml ]---------------
module type Extern = sig
  val bar1 : Foo.foo_t
end

module type Intern = sig
  include Extern
  val bar2 : Foo.foo_t
end

module I : Intern = struct
  let bar1 = Foo.foo2
  let bar2 = Foo.BAZ
  let bar3 = Foo.BLUB
end

include I

---------------[ foo.ml ]---------------
module type Extern = sig
  type foo_t = FOO | BAR | BAZ | BLUB
  val foo1 : foo_t
end

module type Intern = sig
  include Extern
  val foo2 : foo_t
end

module I : Intern = struct
  type foo_t = FOO | BAR | BAZ | BLUB
  let foo1 = FOO
  let foo2 = BAR
  let foo3 = BLUB
end

include I

---------------[ pack.mli ]---------------
module Foo : sig
  include Foo.Extern
end

module Bar : sig
  include Bar.Extern
end

-----------------------------------

Re: [Caml-list] RFH: Values do not match: val bar1 : Foo.foo_t is not included in val bar1 : Foo.foo_t

[Julien Signoles]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

Hello,

2010/5/24 Goswin von Brederlow <goswin-v-b@web.de>

> I'm playing around with packs and ways to avoid having to duplicate
> module signatures all over the place. So I came up with the following
> idea: Each module declares an external and internal module type and
> restricts itself to the internal type. The pack then further restricts
> the module to the external type.
>
> But then I get a type error I can't make heads or tails of:


> File "pack.cmx", line 1, characters 0-1:
> Error: The implementation (obtained by packing)
>       does not match the interface pack.mli:
>       Modules do not match:
>         sig
>           module type Extern = sig val bar1 : Foo.foo_t end
>           module type Intern =
>             sig val bar1 : Foo.foo_t val bar2 : Foo.foo_t end
>           module I : sig val bar1 : Foo.foo_t val bar2 : Foo.foo_t end
>           val bar1 : Foo.foo_t
>           val bar2 : Foo.foo_t
>         end
>       is not included in
>         sig val bar1 : Foo.foo_t end
>       Values do not match:
>         val bar1 : Foo.foo_t
>       is not included in
>         val bar1 : Foo.foo_t
> make: *** [all] Error 2


>
> Can anyone explain that to me?
>

The error message is not very helpful here. But don't refer to an internal
generative type (namely Foo.foo_t) in your packing signature pack.mli. To
solve your issue, you have to declare the type foo_t outside the pack like I
said in a previous message (
http://caml.inria.fr/pub/ml-archives/caml-list/2010/05/b79d812d9dfb99e12c8e924f83d7168c.en.html
).

Hope this helps,
Julien

[-- Attachment #2: Type: text/html, Size: 2397 bytes --]

Re: [Caml-list] RFH: Values do not match: val bar1 : Foo.foo_t is not included in val bar1 : Foo.foo_t

[Goswin von Brederlow]

Julien Signoles <julien.signoles@gmail.com> writes:

> Hello,
>
> 2010/5/24 Goswin von Brederlow <goswin-v-b@web.de>
>
>     I'm playing around with packs and ways to avoid having to duplicate
>     module signatures all over the place. So I came up with the following
>     idea: Each module declares an external and internal module type and
>     restricts itself to the internal type. The pack then further restricts
>     the module to the external type.
>
>     But then I get a type error I can't make heads or tails of: 
>
>
>     File "pack.cmx", line 1, characters 0-1:
>     Error: The implementation (obtained by packing)
>           does not match the interface pack.mli:
>           Modules do not match:
>             sig
>               module type Extern = sig val bar1 : Foo.foo_t end
>               module type Intern =
>                 sig val bar1 : Foo.foo_t val bar2 : Foo.foo_t end
>               module I : sig val bar1 : Foo.foo_t val bar2 : Foo.foo_t end
>               val bar1 : Foo.foo_t
>               val bar2 : Foo.foo_t
>             end
>           is not included in
>             sig val bar1 : Foo.foo_t end
>           Values do not match:
>             val bar1 : Foo.foo_t
>           is not included in
>             val bar1 : Foo.foo_t
>     make: *** [all] Error 2 
>
>
>
>     Can anyone explain that to me?
>
>
> The error message is not very helpful here. But don't refer to an internal
> generative type (namely Foo.foo_t) in your packing signature pack.mli. To solve
> your issue, you have to declare the type foo_t outside the pack like I said in
> a previous message (http://caml.inria.fr/pub/ml-archives/caml-list/2010/05/
> b79d812d9dfb99e12c8e924f83d7168c.en.html).
>
> Hope this helps,
> Julien

That sounds like a bug then.

I was trying hard not to repeat information in different places. That
just ends up with one of them getting out of sync.

MfG
        Goswin