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 B9B3E7F7C2 for ; Wed, 5 Feb 2014 22:17:53 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.216.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.216.53 as permitted sender) identity=mailfrom; client-ip=209.85.216.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; 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@mail-qa0-f53.google.com) identity=helo; client-ip=209.85.216.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-qa0-f53.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqECACOq8lLRVdg1lGdsb2JhbABZg0RXqmWLIYhUgQgIFg4BAQEBBwsLCRIqgiUBAQQBJxkBGw8DCwEDAQsGBQsNDSEiAREBBQEKEgYTCAqHXgEDCQgNoRqMXoMJk3MKGScDCmSIKhEBBQyOZQQHhDgEiUmOYoEyjwIYKYJsggse X-IPAS-Result: AqECACOq8lLRVdg1lGdsb2JhbABZg0RXqmWLIYhUgQgIFg4BAQEBBwsLCRIqgiUBAQQBJxkBGw8DCwEDAQsGBQsNDSEiAREBBQEKEgYTCAqHXgEDCQgNoRqMXoMJk3MKGScDCmSIKhEBBQyOZQQHhDgEiUmOYoEyjwIYKYJsggse X-IronPort-AV: E=Sophos;i="4.95,788,1384297200"; d="scan'208";a="57040271" Received: from mail-qa0-f53.google.com ([209.85.216.53]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 Feb 2014 22:17:52 +0100 Received: by mail-qa0-f53.google.com with SMTP id cm18so1435018qab.26 for ; Wed, 05 Feb 2014 13:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7sHRTKGSiEwXfKieNDjXIeqLPsZrrNWh0WcYGWEoUZY=; b=wWjVPKfmPaSWhoHMbYx9xC881w1JGCX5Bm6QzpZn6nX4jy95zTzroHbCw9MW5AWEOM 2gOtDzPY4wcs79GWYukuM0HOXAM/1SGDv3fjQCKqTxvk02VXGRuDf1Gsm1uN0rKCWUog iSNCrKtNE6RwP/uKATds5ARWmO+AfhtGu1GKdUccXoI0RDCl9bSCG499w8UlMu74bdQ+ 1vSn1AXT+Y+EqYEN8IMCgN7kqlT1CyiT7jk/QdrwVDT5uZVZMyR8JGLABZ+VocLUkvnq VW1EXV41r2fdUfoWF42x6rFabfYqc7E3deV+ExAHB1m3ero41AMxBBcU2o/wUYyVHw36 IPuA== X-Received: by 10.224.60.69 with SMTP id o5mr6388216qah.92.1391635071825; Wed, 05 Feb 2014 13:17:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.106.137 with HTTP; Wed, 5 Feb 2014 13:17:31 -0800 (PST) In-Reply-To: <52F29F45.6070003@frisch.fr> References: <52F29F45.6070003@frisch.fr> From: Yotam Barnoy Date: Wed, 5 Feb 2014 16:17:31 -0500 Message-ID: To: Alain Frisch Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a11c3e4881cfa8904f1af4a48 Subject: Re: [Caml-list] Default methods for module signatures --001a11c3e4881cfa8904f1af4a48 Content-Type: text/plain; charset=ISO-8859-1 Very nice proposal. I'm not crazy about the word 'virtual' since it doesn't really mean anything (and has been brutally abused in C++), but that's obviously a minor nitpick. Any reason this patch wasn't picked up? -Yotam On Wed, Feb 5, 2014 at 3:29 PM, Alain Frisch wrote: > I proposed (13 years ago...) a small patch to support optional fields in > modules. This would help achieving the desired effect. See: > > http://alain.frisch.fr/info/patch-option-announce > http://alain.frisch.fr/info/patch-option > > -- Alain > > > > On 2/5/2014 7:49 PM, 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 >> >> 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 >> >> >> > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --001a11c3e4881cfa8904f1af4a48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Very nice proposal. I'm not crazy about the word = 'virtual' since it doesn't really mean anything (and has been b= rutally abused in C++), but that's obviously a minor nitpick. Any reaso= n this patch wasn't picked up?

-Yotam


On Wed, Feb 5, 2014 at 3:29 PM, Alain Frisch <alain@frisch.fr> wrote:
I proposed (13 years ago...) a small patch t= o support optional fields in modules. =A0This would help achieving the desi= red effect. See:

http://alain.frisch.fr/info/patch-option-announce
http= ://alain.frisch.fr/info/patch-option

-- Alain



On 2/5/2014 7:49 PM, Yotam Barnoy wrote:
Hello List

I would like the following feature, and I'm not enough of an expert in<= br> module-fu to know if something like this is doable.

Suppose I have a module signature of

module type Monad =3D sig
=A0 =A0type 'a m
=A0 =A0val return : 'a -> 'a m
=A0 =A0val (>>=3D) : 'a m -> ('a -> 'b m) -> = 9;b m
=A0 =A0val (>>) : 'a m -> 'b m -> 'b m
end

I would like to have a default implementation for (>>), since a simpl= e
default implementation is

let (>>) m f =3D m >>=3D fun _ -> f

Alternatively, I would like to include this from some DefaultMonad
module, but have the (>>=3D) referred to in the function be my newly<= br> defined (>>=3D) 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

module type Monad =3D 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




--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners<= /a>
Bug reports: http://caml.inria.fr/bin/caml-bugs

--001a11c3e4881cfa8904f1af4a48--