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 DD7FE80211 for ; Fri, 27 Oct 2017 15:53:37 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=oleg@okmij.org; spf=Pass smtp.mailfrom=oleg@okmij.org; spf=None smtp.helo=postmaster@mail1.g3.pair.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of oleg@okmij.org) identity=pra; client-ip=66.39.3.114; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="oleg@okmij.org"; x-sender="oleg@okmij.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of oleg@okmij.org designates 66.39.3.114 as permitted sender) identity=mailfrom; client-ip=66.39.3.114; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="oleg@okmij.org"; x-sender="oleg@okmij.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@mail1.g3.pair.com) identity=helo; client-ip=66.39.3.114; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="oleg@okmij.org"; x-sender="postmaster@mail1.g3.pair.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3Ai0QKdBW4pW3Fcib1n4fNaIGBN0XV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYZRCGt8tkgFKBZ4jH8fUM07OQ6P+wHzFYqb+681k8M7V0Hycfjs?= =?us-ascii?q?sXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aSV3DMl9v?= =?us-ascii?q?J+/1MofUicmn1un0/IfcMCtSgz/oRrd/I13iqgHcueERgo5jKOA20BSf8SgAQP?= =?us-ascii?q?hf2W49fQHbpB37/MrlpJM=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAQB6OfNZh3IDJ0JcHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBhBhuJ48Njh6BepZSggEKI4QDAYEUAoRKQxQBAQEBAQEBAQEBARI?= =?us-ascii?q?BAQEKCwkIKC+COCKCRAECAzo6BRsYCTQFdYoKEKs7imsBCyaDLoIHgU+EB4ENg?= =?us-ascii?q?wqBPyZigniCMgWSbI8XgxiETo0JDYJzgROPJ4xfiTGBOTaCCVUyCEmCZAmCUxA?= =?us-ascii?q?MgXZoi2UBAQE?= X-IPAS-Result: =?us-ascii?q?A0BBAQB6OfNZh3IDJ0JcHAEBBAEBCgEBFwEBBAEBCgEBhBh?= =?us-ascii?q?uJ48Njh6BepZSggEKI4QDAYEUAoRKQxQBAQEBAQEBAQEBARIBAQEKCwkIKC+CO?= =?us-ascii?q?CKCRAECAzo6BRsYCTQFdYoKEKs7imsBCyaDLoIHgU+EB4ENgwqBPyZigniCMgW?= =?us-ascii?q?SbI8XgxiETo0JDYJzgROPJ4xfiTGBOTaCCVUyCEmCZAmCUxAMgXZoi2UBAQE?= X-IronPort-AV: E=Sophos;i="5.44,304,1505772000"; d="scan'208";a="298231637" Received: from mail1.g3.pair.com ([66.39.3.114]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2017 15:53:36 +0200 Received: from mail1.g3.pair.com (localhost [127.0.0.1]) by mail1.g3.pair.com (Postfix) with ESMTP id 23BC63FB913; Fri, 27 Oct 2017 09:53:34 -0400 (EDT) Received: from Magus.localnet (g.sf.ecei.tohoku.ac.jp [130.34.192.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.g3.pair.com (Postfix) with ESMTPSA id F363E582CB8; Fri, 27 Oct 2017 09:53:32 -0400 (EDT) Date: Fri, 27 Oct 2017 22:58:19 +0900 From: Oleg To: rich@annexia.org Cc: ptoscano@redhat.com, caml-list@inria.fr Message-ID: <20171027135819.GA4340@Magus.localnet> Mail-Followup-To: Oleg , rich@annexia.org, ptoscano@redhat.com, caml-list@inria.fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171025083530.gvggcenrgxolduse@annexia.org> User-Agent: Mutt/1.6.1 (2016-04-27) Subject: Re: [Caml-list] What if exn was not an open type? 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.