From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id EDE277EEBF for ; Wed, 19 Aug 2015 23:15:10 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of octa@polychoron.fr) identity=pra; client-ip=217.70.183.195; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="octa@polychoron.fr"; x-sender="octa@polychoron.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of octa@polychoron.fr) identity=mailfrom; client-ip=217.70.183.195; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="octa@polychoron.fr"; x-sender="octa@polychoron.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@relay3-d.mail.gandi.net) identity=helo; client-ip=217.70.183.195; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="octa@polychoron.fr"; x-sender="postmaster@relay3-d.mail.gandi.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBwDK8NRVnMO3RtldhF6DH6ZbBpkAglgCgUZMAQEBAQEBEgEBAQEBBg0JCSEuQQECAYNfAQEEI1URCwQdFgsCAgkDAgECAUUTCAEBiC65PZZGhiCEMIEDhRGCaYFDBZIUgxCBQ4x0hySNW4NmAoQlgjeBBAEBAQ X-IPAS-Result: A0AgBwDK8NRVnMO3RtldhF6DH6ZbBpkAglgCgUZMAQEBAQEBEgEBAQEBBg0JCSEuQQECAYNfAQEEI1URCwQdFgsCAgkDAgECAUUTCAEBiC65PZZGhiCEMIEDhRGCaYFDBZIUgxCBQ4x0hySNW4NmAoQlgjeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,712,1432591200"; d="scan'208,217,223";a="143298397" Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 19 Aug 2015 23:15:10 +0200 Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id A7568A80AD for ; Wed, 19 Aug 2015 23:15:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id EV8M2WbYIX4y for ; Wed, 19 Aug 2015 23:15:08 +0200 (CEST) X-Originating-IP: 92.150.209.123 Received: from [192.168.1.11] (AMarseille-655-1-588-123.w92-150.abo.wanadoo.fr [92.150.209.123]) (Authenticated sender: octa@polychoron.fr) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 1E94EA80AC for ; Wed, 19 Aug 2015 23:15:07 +0200 (CEST) To: caml-list@inria.fr References: <55BF75F6.1040006@bioquant.uni-heidelberg.de> <8E1A640CE3374EB492981ADB0A2DA5C6@erratique.ch> <20150804092633.GC5689@frosties> <5C2023F4AF0549F58F3E4C9A6F8ABE84@erratique.ch> <20150814105551.GD31364@frosties> <55CDD0F2.1090200@zoho.com> <20150818111134.GA11154@frosties> From: octachron Message-ID: <55D4F1DB.5090906@polychoron.fr> Date: Wed, 19 Aug 2015 23:15:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040806060503070007030704" Subject: Re: [Caml-list] destructive local opens This is a multi-part message in MIME format. --------------040806060503070007030704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable From my point of view, a prefixed notation M.+ does not replace all use=20 case of local opens, for at least two reasons: 1. It makes operators harder to spot since I can not rely any more=20 on the first character 2. It adds syntactic noise and thus decreases readability within=20 the DSL As an illustration, a simple rotation (** Rotation on the vect(x,y) plane with an angle t precondition: x and y are orthonormal *) let rotation (x,y) t v =3D let open V in v + R.( ( cos t - 1. ) * (v|*|x) - sin t * (v|*|y) ) * x + R.( sin t * (v|*|x) + ( cos t - 1. ) * (v|*|y) ) * y (where V is a vector module, R the associated real-like field and |*|=20 the scalar product) becomes let rotation (x,y) t v =3D v V.+ ( ( cos t R.- 1. ) R.* ( v V.|*| x ) R.- sin t R.* ( v V.|*| y ) ) V.* x V.+ ( sin t R.* ( v V.|*| x ) R.+ ( cos t R.- 1. ) R.* ( v V.|*| y ) ) V.* y with your proposition. In this second version, I have a hard time separating the different=20 subexpressions, and I don't think it would improve much with a better=20 familiarity with the syntax. At the same time, I do agree that it would be nice to be able to use=20 operators as operators without having to bring them in the local scope. -- octachron Le 08/19/15 17:55, Simon Cruanes a =C3=A9crit : > This whole thread makes me wonder whether local opens are worth it. I=20 > don't like global open (at all), and shadowing is harmful even in=20 > smaller scopes. Local open seems to be used for DSL that have a lot of=20 > infix operators (maths, etc.) as demonstrated by the proposal of new=20 > warnings and syntax about shadowing of infix operators. > > If modules have short names (Z, Q from Zarith come to mind, but=20 > module-aliasing your favorite monad to "M" would do too), would M.+ be=20 > a reasonable infix operator? I would be ready to have slightly more=20 > verbose calls to M.>>=3D if it removes ambiguity and potential shadowing= =20 > bugs. Of course I don't know if this is compatible with the current=20 > syntax. > > --=20 > Simon=20 --------------040806060503070007030704 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From my point of view, a prefixed notation M.+ does not replace all use case of local opens, for at least two reasons:

=C2=A0=C2=A0=C2=A0 1. It makes operators harder to spot since I can n= ot rely any more on the first character
=C2=A0=C2=A0=C2=A0 2. It adds syntactic noise and thus decreases read= ability within the DSL

As an illustration, a simple rotation
(** Rotation on the vect(x,y) plane with an angle t
=C2=A0=C2=A0=C2=A0 precondition: x and y are orthonormal=C2=A0 = *)
let rotation (x,y) t v =3D let open V in
=C2=A0v=C2=A0
=C2=A0 + R.( ( cos t - 1. ) * (v|*|x) - sin t * (v|*|y) ) * x
=C2=A0 + R.( sin t * (v|*|x) + ( cos t - 1. ) * (v|*|y) ) * y
(where V is a vector module, R the associated real-like field and |*| the scalar product)
becomes
let rotation (x,y) t v =3D
=C2=A0v=C2=A0
=C2=A0 V.+ ( ( cos t R.- 1. ) R.* ( v V.|*| x ) R.- sin t R.* (= v V.|*| y ) ) V.* x
=C2=A0 V.+ ( sin t R.* ( v V.|*| x ) R.+ ( cos t R.- 1. ) R.* (= v V.|*| y ) ) V.* y
=C2=A0with your proposition.

In this second version, I have a hard time separating the different subexpressions, and I don't think it would improve much with a better familiarity with the syntax.

At the same time, I do agree that it would be nice to be able to use operators as operators without having to bring them in the local scope.

-- octachron

Le 08/19/15 17:55, Simon Cruanes a =C3=A9crit=C2=A0:
This whole thread makes me wonder whether local opens are worth it. I don't like global open (at all), and shadowing is harmful even in smaller scopes. Local open seems to be used for DSL that have a lot of infix operators (maths, etc.) as demonstrated by the proposal of new warnings and syntax about shadowing of infix operators.

If modules have short names (Z, Q from Zarith come to mind, but module-aliasing your favorite monad to "M" would do too), would M.+ be a reasonable infix operator? I would be ready to have slightly more verbose calls to M.>>=3D if it removes ambiguity and potential shadowing bugs. Of course I don't know if this is compatible with the current syntax.

--
Simon

--------------040806060503070007030704--