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 0A64280211 for ; Fri, 27 Oct 2017 16:25:04 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=philippe.veber@gmail.com; spf=Pass smtp.mailfrom=philippe.veber@gmail.com; spf=None smtp.helo=postmaster@mail-oi0-f47.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of philippe.veber@gmail.com) identity=pra; client-ip=209.85.218.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="philippe.veber@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of philippe.veber@gmail.com designates 209.85.218.47 as permitted sender) identity=mailfrom; client-ip=209.85.218.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="philippe.veber@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-oi0-f47.google.com) identity=helo; client-ip=209.85.218.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="postmaster@mail-oi0-f47.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AHN1mOh34a3gCxN4XsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?sekWKPad9pjvdHbS+e9qxAeQG96Eu7QZ06L/iOPJZy8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL3WbmHC57CYTFxPjLkI1?= =?us-ascii?q?Y72tQs+Buf+qzPi/8IH/ZABBhTz1Ie8jbUb+kQKEkc0bjsM2LaI8xTPOoX5Jea?= =?us-ascii?q?JR32w+YRrZpRf35s6q8NZctQEW89Am8cNbG+2uZaUzTZRRCjIrI2E8osrxuk+H?= =?us-ascii?q?BROT4WAXW2MRugBFDwjM8FfxWZK1+iDzs+41xTKXJ9a+Gbs9XDDn66ZwVDfpjj?= =?us-ascii?q?0GPng36jeEpNZ3ifdjoBOlpgRnzsbqbYuYLrIqZqPcedICXWcHQMtbWjZpDYa1?= =?us-ascii?q?bo9JBO0Ea7UL57LhrkcD+EPtTTKnA/nin3oV33I=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAQB1QPNZhi/aVdFcHAEBBAEBCgEBF?= =?us-ascii?q?QEBAQECAQEBAQgBAQEBhBhuJweDc4E2l3uBeoJShm2HPoVVggEKI4QDAYEUAoR?= =?us-ascii?q?DB0MUAQEBAQEBAQEBAQESAQEBCAsLCCgvgjgFAR4GgjsBAQEBAgEjHQEbEgYGA?= =?us-ascii?q?wwGAwILDQ0dAgIiAREBBQEKEgYBEggKB4lxAQMNCBCLJpEbQIwMggUFARyDCQW?= =?us-ascii?q?DYwoZJwMKWIJLAQEIAQEBARwCBhKDHIIHgVCEBoENgwqBPxURQ4JogmEBBIg9D?= =?us-ascii?q?Jk6gjCFNo0WgnOQOoxfiR0UBR+BFQ8nggk0ISVeNYIvCYIaKg8QDIFpPzaJIW+?= =?us-ascii?q?BVQEBAQ?= X-IPAS-Result: =?us-ascii?q?A0BaAQB1QPNZhi/aVdFcHAEBBAEBCgEBFQEBAQECAQEBAQg?= =?us-ascii?q?BAQEBhBhuJweDc4E2l3uBeoJShm2HPoVVggEKI4QDAYEUAoRDB0MUAQEBAQEBA?= =?us-ascii?q?QEBAQESAQEBCAsLCCgvgjgFAR4GgjsBAQEBAgEjHQEbEgYGAwwGAwILDQ0dAgI?= =?us-ascii?q?iAREBBQEKEgYBEggKB4lxAQMNCBCLJpEbQIwMggUFARyDCQWDYwoZJwMKWIJLA?= =?us-ascii?q?QEIAQEBARwCBhKDHIIHgVCEBoENgwqBPxURQ4JogmEBBIg9DJk6gjCFNo0WgnO?= =?us-ascii?q?QOoxfiR0UBR+BFQ8nggk0ISVeNYIvCYIaKg8QDIFpPzaJIW+BVQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,304,1505772000"; d="scan'208,217";a="298237772" Received: from mail-oi0-f47.google.com ([209.85.218.47]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 Oct 2017 16:25:01 +0200 Received: by mail-oi0-f47.google.com with SMTP id w197so11108378oif.6 for ; Fri, 27 Oct 2017 07:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EzLOvCCiI5kqJuCr/tLklT6R0VcAtbZ/ABROde14TMY=; b=pEDBUl7ohu33zBIp/p5FNjX744bpu4mEfA0kNYNhgL0YX/fh0s9XJTu1V0jxytfmEd PD/T3EjdLBNVxft1E0eaN4Wsdzu+rjCaOa1vBAQUEJQmexwo3n56gFhzEU3c7Un09XIp CCha9IcpZgbUl9382p7cIOchqxPVJ694SUY/5stIWGZbaTcRPyrXWJP8Hd9ajOxyQHWU lVnEE+C7Q2HXUUjhVToaXs879l9X9YkHhbwzYeli282Qqs1LyqJ4HDinj6FVABwrdcUS SFmgzsLrKiSgbnqUviU6rhxKwu63Q/rycWrh4AGu4Yn7PNcMnDmMzNwAdA6gRXXZ2BTq krRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=EzLOvCCiI5kqJuCr/tLklT6R0VcAtbZ/ABROde14TMY=; b=HxDtD2h9fosylKdGL00OhViUVjRn6Meh9KxOQd5AFhk8rEEhAJvPeDs3C4SPVm+SUp YnuES7G1wIh1zo30qYXdMYI4OqUjiORvDdKUbCtfdJKJwchhQAIgqoLy+jg0BPSgdhZD ZUIDfc0jGhm3DqKjlub2AHLcAP4iu3YDU4+g+Xzk3H2fWBkuDYBDVgn3dIUH/zRstDUu ilS6blX+Vz/hM53D2J/rkx0HbvTqjzVpNeezq6ImlEBbz07vW+2qudfvkeuyco/hjx4w Ww0JE2GV6tqapoqeVZGExfoyIR58QEgF6PXhdQa8NgvxcE/PRmT4Cs98Z++rdvqRz+5F 5XKQ== X-Gm-Message-State: AMCzsaVLUpW+cOxc1NBn8s1iZ3hNAFFYnMLGwvynsK0o/ks6be0CRv5m ys45M1DKq8v1TBhcPXEY6Eb1wNkrIwGrxRIl4Lw= X-Google-Smtp-Source: ABhQp+RW26s/HjnZoz8jShVFseDD6b9sG+50YCMrU090F3q/4ReWV/q+QVDJl+wcXAOBn9MAj/4QFtdl8k8Q4dIxf9k= X-Received: by 10.157.89.225 with SMTP id u33mr394850otg.203.1509114299229; Fri, 27 Oct 2017 07:24:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.34.77 with HTTP; Fri, 27 Oct 2017 07:24:38 -0700 (PDT) In-Reply-To: <20171027135819.GA4340@Magus.localnet> References: <20171025083530.gvggcenrgxolduse@annexia.org> <20171027135819.GA4340@Magus.localnet> From: Philippe Veber Date: Fri, 27 Oct 2017 16:24:38 +0200 Message-ID: To: Oleg , "Richard W.M. Jones" , ptoscano@redhat.com, caml users Content-Type: multipart/alternative; boundary="f4030435b8d8bb2b76055c880d9b" X-Validation-by: philippe.veber@gmail.com Subject: Re: [Caml-list] What if exn was not an open type? --f4030435b8d8bb2b76055c880d9b Content-Type: text/plain; charset="UTF-8" Thanks Oleg, this is very interesting! I thought one big selling argument of monads was also that the type of the functions shows which effect it performs. As I understand it, it is not the case for effects, at least not in existing implementations like multicore ocaml. Isn't this considered a concern, just like exception-raising functions are increasingly discouraged at the benefit of explicitly specifying partial functions with a result type? Also, would you know a reference that shows that effects compose indeed a lot more easily than monads? In my (very limited) experience, composing two monads sometimes require a little thinking and not so trivial implementation to be defined. 2017-10-27 15:58 GMT+02:00 Oleg : > > It is interesting that we have this discussion about, even advocacy > for, monads at the time effects are coming to the front stage. The > language Eff (http://eff-lang.org), which is essentially OCaml, states > right upfront its advantages over monads. (Monads do not compose.) > Daan Leijen talk past month about the web server implemented in Koka > stressed the absence of monads. In Koka, if we need an effectful > operation, we just do it. As the Multicore OCaml project has shown, > effects can be very efficiently implemented. > > I fully agree with Ivan Gotovchits that recommends Rich Jones' code > rely on exceptions rather than monads. Where I disagree is the > contention that ``When you need to write system code or any code that > deals with effects, monads become inevitable sooner or later unless > you're willing to use the escape hatch of mutability.'' Monads are not > inevitable! > > First of all, not all effects can be represented as monads (which was > pointed long time ago by Wadler himself). My talk at the ML workshop > last month > http://okmij.org/ftp/tagless-final/nondet-effect.html > described several other effects that aren't monadic and that > commitment to monads precludes several useful implementations (e.g., > code generation, which cannot be thought in monadic terms). Hence, > there is real harm in trying to squeeze everything into a > monad. Incidentally, alternative ideas of effects as interactions go > back to 1970s. > > Richard W.M. Jones wrote: > > Having said all that I was writing a little ML language last > > year and I tried to implement a return statement, but it was very > > awkward to work out how to map that to my lambda calculus, so > > I understand how return statements are rather difficult to implement > > in practice. > > Perhaps this gives a hint that lambda-calculus isn't the best model of > computation -- as the Founding Father has recognized very early > on. There is a reason he spent his life after ML working on process > calculi. Indeed, it takes lots of hops to implement a simple return > statement -- not to speak about real IO -- whereas it a process > calculus, we just say !a. Done. Sending the result to another process > (or to the context) is a built-in operation. There are no > continuations to pass around or capture, no monads (which become > totally unnecessary), no binding. Erlang has shown very well that this > way of programming is realistic, and rather effective. > > lambda-calculus has its uses: it works spectacularly well for what it > has been designed for: expressing definitions (and logical > derivations). However, just because it is possible to express > arithmetic in lambda-calculus does not mean that we should be stuck > with Church-numerals. There are better ways to handle numbers -- and > there are better ways to handle communication and control -- outside > lambda-calculus. > > -- > 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 > --f4030435b8d8bb2b76055c880d9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Oleg, this is very interesting! I thought one big s= elling argument of monads was also that the type of the functions shows whi= ch effect it performs. As I understand it, it is not the case for effects, = at least not in existing implementations like multicore ocaml. Isn't th= is considered a concern, just like exception-raising functions are increasi= ngly discouraged at the benefit of explicitly specifying partial functions = with a result type? Also, would you know a reference that shows that effect= s compose indeed a lot more easily than monads? In my (very limited) experi= ence, composing two monads sometimes require a little thinking and not so t= rivial implementation to be defined.
2017-10-27 15:58 GMT+02:00 Oleg <oleg@okmij.org<= /a>>:

It is interesting that we have this discussion about, even advocacy
for, monads at the time effects are coming to the front stage. The
language Eff (http://eff-lang.org), which is essentially OCaml, states
right upfront its advantages over monads. (Monads do not compose.)
Daan Leijen talk past month about the web server implemented in Koka
stressed the absence of monads. In Koka, if we need an effectful
operation, we just do it. As the Multicore OCaml project has shown,
effects can be very efficiently implemented.

I fully agree with Ivan Gotovchits that recommends Rich Jones' code
rely on exceptions rather than monads. Where I disagree is the
contention that ``When you need to write system code or any code that
deals with effects, monads become inevitable sooner or lat= er unless
you're willing to use the escape hatch of mutability.'' = Monads are not
inevitable!

First of all, not all effects can be represented as monads (which was
pointed long time ago by Wadler himself). My talk at the ML workshop
last month
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://okmij.org/ft= p/tagless-final/nondet-effect.html
described several other effects that aren't monadic and that
commitment to monads precludes several useful implementations (e.g.,
code generation, which cannot be thought in monadic terms).=C2=A0 Hence,
there is real harm in trying to squeeze everything into a
monad. Incidentally, alternative ideas of effects as interactions go
back to 1970s.

Richard W.M. Jones wrote:
> Having said all that I was writing a little ML language last
> year and I tried to implement a return statement, but it was very
> awkward to work out how to map that to my lambda calculus, so
> I understand how return statements are rather difficult to implement > in practice.

Perhaps this gives a hint that lambda-calculus isn't the best mo= del of
computation -- as the Founding Father has recognized very early
on. There is a reason he spent his life after ML working on process
calculi. Indeed, it takes lots of hops to implement a simple return
statement -- not to speak about real IO -- whereas it a process
calculus, we just say !a. Done. Sending the result to another process
(or to the context) is a built-in operation. There are no
continuations to pass around or capture, no monads (which become
totally unnecessary), no binding. Erlang has shown very well that this
way of programming is realistic, and rather effective.

lambda-calculus has its uses: it works spectacularly well for what it
has been designed for: expressing definitions (and logical
derivations). However, just because it is possible to express
arithmetic in lambda-calculus does not mean that we should be stuck
with Church-numerals. There are better ways to handle numbers -- and
there are better ways to handle communication and control -- outside
lambda-calculus.

--
Caml-list mailing list.=C2=A0 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

--f4030435b8d8bb2b76055c880d9b--