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 6B95B7F75C for ; Tue, 9 Sep 2014 17:53:49 +0200 (CEST) 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.169; 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.169 as permitted sender) identity=mailfrom; client-ip=209.85.216.169; 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-qc0-f169.google.com) identity=helo; client-ip=209.85.216.169; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-qc0-f169.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsCAA8iD1TRVdipm2dsb2JhbABZg2BXBIJ4sTuUDIFoh0wBgQUIFhABAQEBAQYLCwkUKoQDAQEBAwESEQQZARsdAQMBCwYFBAcNKgICIQEBEQEFARwGEyKICwEDCQgNmnprizCBcoMQiTIKGScNZoV3AREBBQ6NEoItB4J5gVMFlXGEcoIQgV+NFIRJGCmFLiEvAYJOAQEB X-IPAS-Result: AhsCAA8iD1TRVdipm2dsb2JhbABZg2BXBIJ4sTuUDIFoh0wBgQUIFhABAQEBAQYLCwkUKoQDAQEBAwESEQQZARsdAQMBCwYFBAcNKgICIQEBEQEFARwGEyKICwEDCQgNmnprizCBcoMQiTIKGScNZoV3AREBBQ6NEoItB4J5gVMFlXGEcoIQgV+NFIRJGCmFLiEvAYJOAQEB X-IronPort-AV: E=Sophos;i="5.04,492,1406584800"; d="scan'208";a="93799906" Received: from mail-qc0-f169.google.com ([209.85.216.169]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 09 Sep 2014 17:53:48 +0200 Received: by mail-qc0-f169.google.com with SMTP id m20so1537784qcx.28 for ; Tue, 09 Sep 2014 08:53:47 -0700 (PDT) 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=5gD02HWuUQ8yinKoVIThTHRUfVEwR1/e56dqNY3GSX0=; b=dxhBUH76tWJsEVAvWuiz7ZJArjj6o/CIIOHS2Q2IYr5AsHf7koHveNlom/V63sFtjl BN7usSeN9Jri4hcZI9LUnOp0LPi9J5gDk8gUID00fJxFOCyOnjEX8K4/SVgNy80oDxq/ OAxaAw25hL92IPnc6nCGcuvFB79gf+yY5Jqvuxky38UPGp2TgsNPWj+JmnBH6BmN78jO i5697FcLYmhDe7CoEGmd39AVBh89ieGAYD5o1zEf0fmd36+cWEIy2i5jbgvgqRzB2Uqu +Oavb98LycTftTKcZfKaD9L6/DM/gRPuT/LhHVhOr/vhymajQIxgxQAMRylhuMFlE8GM DzKg== X-Received: by 10.224.161.11 with SMTP id p11mr3920553qax.40.1410278027744; Tue, 09 Sep 2014 08:53:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.174.68 with HTTP; Tue, 9 Sep 2014 08:53:27 -0700 (PDT) In-Reply-To: References: From: Yotam Barnoy Date: Tue, 9 Sep 2014 11:53:27 -0400 Message-ID: To: Jeremy Yallop Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=089e0149d2e8e0dd300502a3f043 Subject: Re: [Caml-list] Implicit module question --089e0149d2e8e0dd300502a3f043 Content-Type: text/plain; charset=UTF-8 Amazing! This is SO cool. I'll definitely give it a try. So here's my followup question: what will it take to have implicits everywhere so we can abolish (ie. deprecate) all polymorphic functions? Is this feasible? Is it as simple as Pervasives declaring implicits for Ord, Eq, Show etc for the basic types? On Tue, Sep 9, 2014 at 11:47 AM, Jeremy Yallop wrote: > On 9 September 2014 16:32, Yotam Barnoy wrote: > > I have a question about the implicit module implementation: Is there any > way to > > combine modules automatically? For example, suppose I have a Show > implicit > > module and an Ord implicit module, and a function receives both, and > wants > > to infer both functionalities for an incoming type so we can run both > show > > and compare on the same type. Does the current model cover such a > use-case? > > Yes, it does. The implicits language is essentially the same as > OCaml's module language, so you can use constraints/equations on the > module types in the regular way. For example, suppose you have module > types for SHOW and ORD together with corresponding top-level > functions: > > module type SHOW = > sig > type t > val show : t -> string > end > > let show (implicit Show : SHOW) (x : Show.t) = Show.show x > > module type ORD = > sig > type t > val compare : t -> t -> int > end > > let compare (implicit Ord : ORD) (x : Ord.t) (y : Ord.t) = Ord.compare x > y > > You can write a function which operates on a value with implicit > instances for both SHOW and ORD by adding some kind of type > constraint. For example, you might write: > > let f (implicit Show: SHOW) (implicit Ord: ORD with type t = > Show.t) (x : Show.t) y = > if compare x y < 0 then show x else show y > > or perhaps > > let f (type a) (implicit Show: SHOW with type t = a) (implicit Ord: > ORD with type t = a) (x : a) y = > if compare x y < 0 then show x else show y > > The inferred type is just as you'd expect: > > val f : > (implicit Show : SHOW with type t = 'a) -> > (implicit Ord : ORD with type t = 'a) -> > 'a -> 'a -> string > > You might like to try out the implementation for yourself, either via > the opam switch or via the IOCaml top-level that Andrew Ray's set up: > > http://andrewray.github.io/iocamljs/modimp_show.html > --089e0149d2e8e0dd300502a3f043 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Amazing! This is SO cool. I'll definitely give it a tr= y.

So here's my followup question: what will it take= to have implicits everywhere so we can abolish (ie. deprecate) all polymor= phic functions? Is this feasible? Is it as simple as Pervasives declaring i= mplicits for Ord, Eq, Show etc for the basic types?

On Tue, Sep 9, 2014 at 11:4= 7 AM, Jeremy Yallop <yallop@gmail.com> wrote:
On 9 September 2014 16:32, Yotam Barnoy= <yotambarnoy@gmail.com>= wrote:
> I have a question about the implicit module implementation: Is there a= ny way to
> combine modules automatically? For example, suppose I have a Show impl= icit
> module and an Ord implicit module, and a function receives both, and w= ants
> to infer both functionalities for an incoming type so we can run both = show
> and compare on the same type. Does the current model cover such a use-= case?

Yes, it does.=C2=A0 The implicits language is essentially the same a= s
OCaml's module language, so you can use constraints/equations on the
module types in the regular way.=C2=A0 For example, suppose you have module=
types for SHOW and ORD together with corresponding top-level
functions:

=C2=A0 module type SHOW =3D
=C2=A0 sig
=C2=A0 =C2=A0 type t
=C2=A0 =C2=A0 val show : t -> string
=C2=A0 end

=C2=A0 let show (implicit Show : SHOW) (x : Show.t) =3D Show.show x

=C2=A0 module type ORD =3D
=C2=A0 sig
=C2=A0 =C2=A0 type t
=C2=A0 =C2=A0 val compare : t -> t -> int
=C2=A0 end

=C2=A0 let compare (implicit Ord : ORD) (x : Ord.t) (y : Ord.t) =3D Ord.com= pare x y

You can write a function which operates on a value with implicit
instances for both SHOW and ORD by adding some kind of type
constraint.=C2=A0 For example, you might write:

=C2=A0 =C2=A0let f (implicit Show: SHOW) (implicit Ord: ORD with type t =3D=
Show.t) (x : Show.t) y =3D
=C2=A0 =C2=A0 =C2=A0if compare x y < 0 then show x else show y

or perhaps

=C2=A0 =C2=A0let f (type a) (implicit Show: SHOW with type t =3D a) (implic= it Ord:
ORD with type t =3D a) (x : a) y =3D
=C2=A0 =C2=A0 =C2=A0if compare x y < 0 then show x else show y

The inferred type is just as you'd expect:

=C2=A0 val f :
=C2=A0 =C2=A0 (implicit Show : SHOW with type t =3D 'a) ->
=C2=A0 =C2=A0 (implicit Ord : ORD with type t =3D 'a) ->
=C2=A0 =C2=A0 'a -> 'a -> string

You might like to try out the implementation for yourself, either via
the opam switch or via the IOCaml top-level that Andrew Ray's set up:
=C2=A0 =C2=A0http://andrewray.github.io/iocamljs/modimp_show.html

--089e0149d2e8e0dd300502a3f043--