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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 1E5647F7C2 for ; Wed, 5 Feb 2014 21:10:46 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of martin.jambon@ens-lyon.org) identity=pra; client-ip=66.111.4.28; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible Received-SPF: Neutral (mail2-smtp-roc.national.inria.fr: domain of martin.jambon@ens-lyon.org does not assert whether or not 66.111.4.28 is permitted sender) identity=mailfrom; client-ip=66.111.4.28; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@out4-smtp.messagingengine.com) identity=helo; client-ip=66.111.4.28; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="postmaster@out4-smtp.messagingengine.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkBALeZ8lJCbwQcm2dsb2JhbABZhxy7ToEQFg4BAQEBAQYLCwkUKIIlAQEEASMEEQgrDQEBDwsYAgIFFgsCAgkDAgECAUUGDQEHAQGHeQisXnaDYp1WEQaBKY0ZMweCb4FJAYlMlSqPJw X-IPAS-Result: ApkBALeZ8lJCbwQcm2dsb2JhbABZhxy7ToEQFg4BAQEBAQYLCwkUKIIlAQEEASMEEQgrDQEBDwsYAgIFFgsCAgkDAgECAUUGDQEHAQGHeQisXnaDYp1WEQaBKY0ZMweCb4FJAYlMlSqPJw X-IronPort-AV: E=Sophos;i="4.95,788,1384297200"; d="scan'208";a="57034759" Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 05 Feb 2014 21:10:45 +0100 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id F06D821436; Wed, 5 Feb 2014 15:10:43 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 05 Feb 2014 15:10:43 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=iT+D8J6aP8WzR2PEc1OllP 2Ze/o=; b=bMVJrXO/ZYVKd9wpJ/Nho9Ndw/EYlaMkbueQLD6XderM7YA6CImUP2 UiHTC8ClC+fzetLTLfE8rYG8+/aXDeZNzyQMK5nL6GEwE0f8Oy9WQYDYHBH/vI7Z RfqdL7F67rFbGkakGirpceSxUp7BowOklEkpSg2+afXhfbz3/ZFIA= X-Sasl-enc: 6LUU8npHMcSRRe0x3NjbbNivBzBqM6iftYaWw5fK6jbO 1391631043 Received: from [172.16.71.72] (unknown [50.193.45.145]) by mail.messagingengine.com (Postfix) with ESMTPA id 77D5E6801B5; Wed, 5 Feb 2014 15:10:43 -0500 (EST) Message-ID: <52F29AC2.1070700@ens-lyon.org> Date: Wed, 05 Feb 2014 12:10:42 -0800 From: Martin Jambon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Yotam Barnoy CC: Ocaml Mailing List References: <52F2944A.3000908@ens-lyon.org> In-Reply-To: <52F2944A.3000908@ens-lyon.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Default methods for module signatures On Wed 05 Feb 2014 11:43:06 AM PST, Martin Jambon wrote: > On Wed 05 Feb 2014 10:49:29 AM PST, Yotam Barnoy wrote: >> Hello List >> >> I would like the following feature, and I'm not enough of an expert in >> module-fu to know if something like this is doable. >> >> Suppose I have a module signature of >> >> module type Monad = sig >> type 'a m >> val return : 'a -> 'a m >> val (>>=) : 'a m -> ('a -> 'b m) -> 'b m >> val (>>) : 'a m -> 'b m -> 'b m >> end >> >> I would like to have a default implementation for (>>), since a simple >> default implementation is >> >> let (>>) m f = m >>= fun _ -> f >> >> Alternatively, I would like to include this from some DefaultMonad >> module, but have the (>>=) referred to in the function be my newly >> defined (>>=) implementation (ie. late binding). Is there currently >> any way to do this? If not, would there be a way to implement a >> partial default implementation built into or associated with a module >> signature? Something like > > OCaml has functors but they don't support optional fields in their > arguments. > > You can create a functor Monad.Make that takes a module without (>>) > and creates a module with an extra (>>) field. However, if the input > module contains (>>) already, the new implementation will override it > as in this minimal example: > > # module A = struct end;; > module A : sig end > > # module M(A: module type of A) = struct include A let x = 0 end;; > module M : functor (A : sig end) -> sig val x : int end > > # module B = M(struct end);; > module B : sig val x : int end > > # module C = M(struct let x = 1 end);; > module C : sig val x : int end > > # C.x;; > - : int = 0 > > C.x is 0, not 1. > > > There may be clever tricks to support some kind of optional module > field pattern, though. I'll let others scratch their heads. :-) The following works, but each optional field must be explicitely set to None: module type Partial = sig val x : int option end module type Full = sig val x : int end module Complete (X : Partial) : Full = struct include X let x = match X.x with | None -> 0 | Some v -> v end module A = Complete (struct let x = None end) module B = Complete (struct let x = Some 1 end) let () = assert (A.x = 0); assert (B.x = 1) > >> module type Monad = sig... default struct... end >> >> Haskell has this available as part of the semantics of their typeclass >> system, and I think it would be really handy to have (if there isn't >> already a way to do it currently). >> >> -Yotam >> >> >