Re: [Caml-list] Expressing module sig and impl in mli file

[Edgar Friendly <thelema314@gmail.com>]

> module Bar : Identifier = String
The problem is here; the ": Identifier" removes any details of Bar 
except what's in Identifier.  Just remove this type restriction and 
everything should typecheck.

E.

On 9/18/2012 6:40 PM, Malcolm Matalka wrote:
> I spoke too soon!  Below is my testcase and error.  Where did I go wrong?
>
> foo.mli:
> open Core.Std
>
> module Bar : sig
>    include Identifier with type t = String.t
> end
>
> foo.ml:
> open Core.Std
>
> module Bar : Identifier = String
>
> The error:
>         Type declarations do not match:
>           type t = Bar.t
>         is not included in
>           type t = Core.Std.String.t
>
> /M
>
> On Tue, Sep 18, 2012 at 11:31 PM, Malcolm Matalka <mmatalka@gmail.com> wrote:
>> Thanks for the response.  I think I found another way to express what I'm after:
>>
>> module Foo : sig include Bar with type t = Baz.t end
>>
>> For the specific use case I have (trying to create a module that is an
>> Identifier from Core) this seems to work nicely.
>>
>> /M
>>
>> On Tue, Sep 18, 2012 at 11:13 PM, Gabriel Scherer
>> <gabriel.scherer@gmail.com> wrote:
>>>  From the outside, there is no point in trying to make a difference
>>> between an "interface" and "concrete types": what users see of the
>>> module is exactly its interface, just as what you see of a value
>>> (through an interface boundary) is its type only. There are exotic
>>> cases where you could want to publish a value definition (or module
>>> implementation) through a component boundary, but that's probably not
>>> your concern here.
>>>
>>> So my intuitive answer (but maybe some other posters will differ) is
>>> that, in an interface, only "module Foo : Bar" makes sense. I do not
>>> understand why you would want the implementation to also be available.
>>> You may be facing a problem that is different than the one you think.
>>> Could you provide a concrete example of what you're trying to do?
>>>
>>> Making a guess: a mistake people often make when using the OCaml
>>> module system is to seal a module with abstract types when they
>>> actually don't want to hide the types, but only to check that the
>>> signature are compatible. For example, with the signature "module type
>>> Ty = sig type t end", people will try to write "module M : Ty = struct
>>> type t = int end" and then be surprised than "(1 : M.t)" does not
>>> type-check. This is because "module M : Ty = <Foo>" is equivalent to
>>> "module M = (<Foo> : Ty)" which coerces <Foo> into the signature Ty
>>> (where "t" is abstract), and no richer. A workaround is to define
>>> "module M = <Foo>" and then separately "module M_unused = (M : Ty)" if
>>> you want to make sure that the interface is compatible, or to refine
>>> it with "module M : (Ty with type t = int) = <Foo>". Not sure that is
>>> actually your problem, though.
>>>
>>> Finally, if you have a module implementation and are not sure what its
>>> precise, most permissive signature is, "ocamlc -i" can help you by
>>> printing the inferred interface.
>>>
>>> On Tue, Sep 18, 2012 at 11:02 PM, Malcolm Matalka <mmatalka@gmail.com> wrote:
>>>> I'm sure this question has been asked before but I didn't see it in
>>>> the Ocaml FAQ and I'm not sure how to express it for a search.
>>>>
>>>> In short, how do I express the following line in a .mli file:
>>>>
>>>> module Foo : Bar = Baz
>>>>
>>>> What I want to accomplish is make present the module Foo to the user,
>>>> where they know both the interface and the concerete types on Foo.
>>>>
>>>> Thanks!
>>>>
>>>> /Malcolm
>>>>
>>>> --
>>>> Caml-list mailing list.  Subscription management and archives:
>>>> https://sympa-roc.inria.fr/wws/info/caml-list
>>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>>>