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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id D06657ED7A for ; Tue, 18 Sep 2012 23:31:15 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=209.85.219.54; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of mmatalka@gmail.com designates 209.85.219.54 as permitted sender) identity=mailfrom; client-ip=209.85.219.54; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-oa0-f54.google.com) identity=helo; client-ip=209.85.219.54; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-oa0-f54.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoDALLnWFDRVds2m2dsb2JhbABFqk+QbAN9CCMBAQEBAQgJCwkUJ4IgAQEBBBICLAEbEgsBAwwGBQsNDSEhAQERAQUBChIGExIQh04BAwwLm1sJA4wlgnOFJQoZJwMKWYh0AQUMii1ia4YFA5QOgVWBFIoDgysWKYQI X-IronPort-AV: E=Sophos;i="4.80,445,1344204000"; d="scan'208";a="156182590" Received: from mail-oa0-f54.google.com ([209.85.219.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 18 Sep 2012 23:31:14 +0200 Received: by oagm1 with SMTP id m1so641617oag.27 for ; Tue, 18 Sep 2012 14:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tbG6KhqwPXbwl834Lx5dqV5PNFXX+yjr4/B7xH1dj3Q=; b=dN+2uJnxtHirU3ecM43xpfTrgfpGrwS08n4fp7svEYhU5iPxDigciU+3Yx11Z+xSfF dK2UcnEnRq59IIY7iwDB40Y85KHkm/ZxFo70F6/WEjuIP4308gSdzga37aSLrsnOiNGp gSj9C6W0EuhzHBE+qtJlupr1mBY+XadcGz4q2mGqEx5pt3yPp5mu1csaE+4yUFMQHnHm IYQwZ1ZQ29Li7T3lRdz1rEkCBUsfBAki6qkddcAQ98gJjhRnZDHDTQ5UEueAqFdQKws8 CAIW37r9U2GIHDt15S9Oc9PpOj2m1lT4Y6OgokhnnNSkvKsTzxjSxhLxIBseKZ1Gf6Kw nSZg== MIME-Version: 1.0 Received: by 10.60.2.161 with SMTP id 1mr1427674oev.48.1348003873474; Tue, 18 Sep 2012 14:31:13 -0700 (PDT) Received: by 10.76.23.9 with HTTP; Tue, 18 Sep 2012 14:31:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Sep 2012 23:31:13 +0200 Message-ID: From: Malcolm Matalka To: Gabriel Scherer Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Expressing module sig and impl in mli file 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 >>