From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 97AAE7ED7A for ; Wed, 19 Sep 2012 04:11:27 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of thelema314@gmail.com) identity=pra; client-ip=209.85.223.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="thelema314@gmail.com"; x-sender="thelema314@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of thelema314@gmail.com designates 209.85.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="thelema314@gmail.com"; x-sender="thelema314@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ie0-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="thelema314@gmail.com"; x-sender="postmaster@mail-ie0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmACANwoWVDRVd+2m2dsb2JhbABFqk2RbQgjAQEBAQEICQsJFCeCIAEBAQMBEgIkCAEbEgwDAQsGBQsNCQQhDwIQAhEBBQEKEhMGAgEBDhCHTgEDBgYLm10JA4wlgnOFHwoZJwMKWYh0AQUMii5ihkEDlA6BVYEUhEyFN4MrP4Qi X-IronPort-AV: E=Sophos;i="4.80,446,1344204000"; d="scan'208";a="173734484" Received: from mail-ie0-f182.google.com ([209.85.223.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Sep 2012 04:11:26 +0200 Received: by iea17 with SMTP id 17so1349193iea.27 for ; Tue, 18 Sep 2012 19:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=iUQq73XZAwAWhx//WJCHAcVXrQOMv0q2sUGMpX9zRPM=; b=Z+9+7RJyqHghnqobFjhMsYGWBgtV9skUFZA0VvirsUynbkNZbcwzDFDymAD2WAzoh7 W4ryns+PDZvw7tozlSLawt/Pxq7LVTMvCf/OHf1EdAaL9ZKy0wuPkmeqD5i6oxJSPlpi rSDQscqpjuPvOGLptW+Vx3tGZAw9QTuTI3G8GBLwXwCpKB/IQA4UelYHe3FW+h5JXN2V 31C9WUnr0n+bxudrjKbM7HaNBEEvKEy71fxE5O5bspKN5U0//dVy6cO2KYunb3E+aFUp UGTSpmQ9N9xoXqQ9HV1K/28PcwbEf3KDF/pg53aziXYT4oQNcDweeTIIb5fzzNQZZ3u8 ZpQw== Received: by 10.42.129.83 with SMTP id p19mr1463716ics.9.1348020685399; Tue, 18 Sep 2012 19:11:25 -0700 (PDT) Received: from [192.168.1.73] (99-121-78-10.lightspeed.lnngmi.sbcglobal.net. [99.121.78.10]) by mx.google.com with ESMTPS id q1sm2422604igj.15.2012.09.18.19.11.24 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 19:11:24 -0700 (PDT) Message-ID: <505929CD.70206@gmail.com> Date: Tue, 18 Sep 2012 22:11:25 -0400 From: Edgar Friendly User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: caml-list@inria.fr References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Expressing module sig and impl in mli file > 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 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 >> 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 = " is equivalent to >>> "module M = ( : Ty)" which coerces into the signature Ty >>> (where "t" is abstract), and no richer. A workaround is to define >>> "module M = " 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) = ". 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 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 >>>>