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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id BBE667F0A6 for ; Fri, 21 Aug 2015 14:28:12 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of becker.nils@gmx.net) identity=pra; client-ip=212.227.15.19; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="becker.nils@gmx.net"; x-sender="becker.nils@gmx.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of becker.nils@gmx.net designates 212.227.15.19 as permitted sender) identity=mailfrom; client-ip=212.227.15.19; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="becker.nils@gmx.net"; x-sender="becker.nils@gmx.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.gmx.net) identity=helo; client-ip=212.227.15.19; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="becker.nils@gmx.net"; x-sender="postmaster@mout.gmx.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DmAQDnGNdVnBMP49Rdh32nSZpuAiuBD0wBAQEBAQESAQEBAQEGDQkJIS6EJAEBBCMqHwoTBSACJgICSwYCAgIqiAcBFQStCotxj2sBhlqBIo5ScBeCFwwvEoExBYxliEcBjTyII5FOhCWDOwIBAg X-IPAS-Result: A0DmAQDnGNdVnBMP49Rdh32nSZpuAiuBD0wBAQEBAQESAQEBAQEGDQkJIS6EJAEBBCMqHwoTBSACJgICSwYCAgIqiAcBFQStCotxj2sBhlqBIo5ScBeCFwwvEoExBYxliEcBjTyII5FOhCWDOwIBAg X-IronPort-AV: E=Sophos;i="5.15,721,1432591200"; d="scan'208";a="143445956" Received: from mout.gmx.net ([212.227.15.19]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Aug 2015 14:28:12 +0200 Received: from [129.206.253.147] by 3capp-gmx-bs47.server.lan (via HTTP); Fri, 21 Aug 2015 14:28:11 +0200 MIME-Version: 1.0 Message-ID: From: "Nils Becker" To: caml-list@inria.fr Content-Type: text/plain; charset=UTF-8 Date: Fri, 21 Aug 2015 14:28:11 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <20150821100011.4BF127F0D7@sympa.inria.fr> References: <20150821100011.4BF127F0D7@sympa.inria.fr> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:pKFinWVsQRLtOV86k9kkzdjLmiD+CjWvJo8SnOBi+2k hb84xWvmDaPZ+mpuKa60Fm/P4wuFWQ+RFBvCOtTtlbdd70KFwp xTeNCsHazFc3ZRXH4x/yVXlBNr5w88GltK/BQMu68v6nsMyxEL 5j2L7nGjlmtiLHTBF6ys4EqTqwRNAA2CKYf2j/mIb1u8AkUuq1 kEYy+A/5FV+jMm/yn5fN4cQYkUnSszxMZg6+Uud3p1UQBWet9x u2enjIhhs42QBnNSj3oniMp94u87hCikPLjHeUR9ZSky/w5L6O 7bbq74= X-UI-Out-Filterresults: notjunk:1;V01:K0:Lgf7xXXtnl0=:+2xvBmE3UVYttAFRM8bAMh uKxduDlz01E4JWlANuFgwblmlgtpKPfvbc0mlaDqc+HxNumka46eqS6IAPhUE3jqeXp1vYLYr eJ7p7a4IqTmPHSXHTlFja4Wi/6baPn+wyPsVlmz76DuzGotPldqxZmptTtOKnLLpxJ0I6Eqm2 5iJjX64PlPU90ULwzP/RUqp4BTVvqj07bvzuGZVkyKK0qYsXEjT46AsIYwL92Vg3fSCSD4ELq VHlNdpxrSh7zwN/STvGvQSrthWdcw9tsCe65gACDK0y2iHtGL2oxBhm2SczbrhJQIwEZlgSYj 02Q2K8LGjsXvY/MEGlryJlLq/uaOs3ap5sRdXtQVBiqW/6uGUIm+rV28sRBbGAdpabHYascFd n3nsNaOw0UMVVu7dSQP2xsn/mzRAaBmOxiK9sJcyhCHzuGYjgux5IBsrvQ3LPc1+nwvh7HXwd jjGUGcjGvQ== Subject: [Caml-list] hi, > > - Local opens are somewhat of an anti-pattern in OCaml, because they're > > usually used in places where you have the same names defined in > > multiple modules: > > While this is certainly a very popular use case in particular when > dealing with operators, I find myself using the local 'let open' form > very often in other contexts. In fact, I don't ever seem to find myself > using it for redefining identifiers. as another data point: i do the same. a typical function definition would be let process_list list = let open List in list |> map fun1 |> map2 fun2 another_list |> iter fun3 basically whenever i can save more than 3 List. qualifiers in the body of a short function where the context is clear, i will do it. i don't see where the problem is with this usage; the standard modules i open are not subject to a lot of change. i think the readability gain is worth it. >> (** Rotation on the vect(x,y) plane with an angle t >> precondition: x and y are orthonormal *) >> let rotation (x,y) t v = 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 +1. this is the kind of code that i would like to write as readable as possible with a short local open. it's basically a remedy for not having operator overloading. > - In the absence of Modular Implicits, as Petter mentioned, it would be > nice to have the warnings/potential errors only generated when the same > names have the same types. In case of different types with the same name, > the type system should take care of any issues. this sounds like an elegant way to allow freedom of shadowing while keeping bugs under control. another maybe trivial point: there are larger libraries that are designed to be opened destructively (Batteries etc); if the warning policy is changed in the same way for short and long opens, it should remain possible to do open! Batteries without a warning.