From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: *** X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,DNS_FROM_RFC_POST, DNS_FROM_SECURITYSAGE,HTML_MESSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 97184BBAF for ; Thu, 20 Nov 2008 15:46:34 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAHAHJUlKfU4aimdsb2JhbACCQDCQLT4BAQEKCQwHDwWxSoEGiyEBAwEDgnk X-IronPort-AV: E=Sophos;i="4.33,639,1220220000"; d="scan'208";a="19380711" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 20 Nov 2008 15:46:33 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id mAKEkWpE002646 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 20 Nov 2008 15:46:33 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAHAHJUlKfU4aimdsb2JhbACCQDCQLT4BAQEKCQwHDwWxSoEGiyEBAwEDgnk X-IronPort-AV: E=Sophos;i="4.33,639,1220220000"; d="scan'208";a="19380690" Received: from ey-out-2122.google.com ([74.125.78.26]) by mail3-smtp-sop.national.inria.fr with ESMTP; 20 Nov 2008 15:46:04 +0100 Received: by ey-out-2122.google.com with SMTP id 25so181280eya.33 for ; Thu, 20 Nov 2008 06:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=qCZ10IFZe+qgWl2KvLhOZViSmKo75mDs3DFdSjRJYhk=; b=srXIVV8/DZaQN+9qdo+qntFI1BsuZc0SwpisLKVAEwhXAIGQU3ZIi7P8NkQdMRQzVF GyxAryO6ySi7uNIIsn58HL3axdfTytbzhPirWkmpV5GCgi9FfiDXrnKvXdR+HwmBx/y4 heTk9ICQQDOycACnfmLn3jq3JGnUIsWoyXidQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=Bv37nCg0mEsAJOW1aDaUwju7TnptV2p+yVWd2B+k7hc1xtiEQYVtXfv8AOPETevA7r KvArkz32BQYtjEo504mTe2tTyNiB0Cu1qdGI4faaYG/apmWzyBGxdE4NRrdg3KBrG1ru CdEJ/WDIFiscl4+qrifp1+lPXef1fHJF8d8RU= Received: by 10.86.79.19 with SMTP id c19mr1621172fgb.41.1227192364270; Thu, 20 Nov 2008 06:46:04 -0800 (PST) Received: by 10.86.79.18 with HTTP; Thu, 20 Nov 2008 06:46:04 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 09:46:04 -0500 From: "Ashish Agarwal" To: "Caml List" Subject: Re: [Caml-list] open Module (not?) considered harmful In-Reply-To: <000001c94b03$4f55d4e0$ee017ea0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_114771_11770468.1227192364247" References: <1227002178.6170.25.camel@Blefuscu> <200811182330.03947.jon@ffconsultancy.com> <1227076192.6290.7.camel@Blefuscu> <4b5157c30811190146l2c6a5e2cv4a085bcc14ae5f4@mail.gmail.com> <20081119211124.51610ae9@alcazar.inria.fr> <1227172839-sup-5973@ausone.inria.fr> <20081120103303.GA25346@annexia.org> <20081120104914.GA14355@usha.takhisis.invalid> <000001c94b03$4f55d4e0$ee017ea0$@com> X-Miltered: at discorde with ID 49257848.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; avoided:01 zacchiroli:01 printf:01 swapped:01 refactor:01 iirc:01 ocaml:01 syntax:01 foo:01 trivial:01 camlp:01 syntax:01 beginner's:01 ocaml:01 bug:01 ------=_Part_114771_11770468.1227192364247 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > Consider > > open Array;; > open List;; I doubt anyone is recommending this. The module design dictates, to some extent, whether the module should be opened. Array and List clearly should not since they have commonly used function names. However, the proposed Data.Containers certainly should be opened. There is no confusion about private names in this case. If I am using Batteries, it will be clear which module "List" refers to. The bureaucracy of writing open statements at the top of every file would get cumbersome, but that can be avoided by the proposed short-circuiting. On Thu, Nov 20, 2008 at 6:29 AM, David Allsopp wrote: > On 20 November 2008 10:49, Stefano Zacchiroli wrote: > > On Thu, Nov 20, 2008 at 10:33:03AM +0000, Richard Jones wrote: > > > Encouraging developers to open modules is also usually a bad idea, > > > except in very limited circumstances (hello Printf). > > > > Why? You and others failed me to convince of this. Or, better, I'm > > sure there are problems with that, but they just show deficiencies > > inherited from other parts of the language. > > Consider > > open Array;; > open List;; > > (* Hundreds of lines of code *) > > length [];; > > The code is now is brittle in terms of the order of the open statements at > the top of the file and will fail to compile if they're swapped. Of course, > if you don't care about that kind of subtle refactoring error then open is > completely fine. Personally, I find that kind of brittleness irritating - > and it also has the potential to waste a huge amount of time if you have to > refactor the code. > > Whether you find code less readable with or without module names is of > course a matter taste and IIRC, OCaml 3.11 .annot files contain the > necessary information to expand them so there could be a nice editor plugin > to expand or remove module paths... > > > > The most straightforward solution to this problem to me looks like > > > providing a syntax equivalent like "from Module import foo, bar" > > > which selectively imports only some identifiers from a given module. > > Which, for values only, is of course a trivial camlp4 extension... and > could > be generalised to include type declarations and so on with only a little > more work. The .NET languages have a syntax for selectively importing > classes from a namespace rather than the entire namespace (and it's > different from Java's in that you can rename the class while you do it). > > > David > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ------=_Part_114771_11770468.1227192364247 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
> Consider
>
> open Array;;
> open List;;

I doubt anyone is recommending this. The module design dictates, to some extent, whether the module should be opened. Array and List clearly should not since they have commonly used function names. However, the proposed Data.Containers certainly should be opened. There is no confusion about private names in this case. If I am using Batteries, it will be clear which module "List" refers to. The bureaucracy of writing open statements at the top of every file would get cumbersome, but that can be avoided by the proposed short-circuiting.


On Thu, Nov 20, 2008 at 6:29 AM, David Allsopp <dra-news@metastack.com> wrote:
On 20 November 2008 10:49, Stefano Zacchiroli wrote:
> On Thu, Nov 20, 2008 at 10:33:03AM +0000, Richard Jones wrote:
> > Encouraging developers to open modules is also usually a bad idea,
> > except in very limited circumstances (hello Printf).
>
> Why? You and others failed me to convince of this. Or, better, I'm
> sure there are problems with that, but they just show deficiencies
> inherited from other parts of the language.

Consider

open Array;;
open List;;

(* Hundreds of lines of code *)

length [];;

The code is now is brittle in terms of the order of the open statements at
the top of the file and will fail to compile if they're swapped. Of course,
if you don't care about that kind of subtle refactoring error then open is
completely fine. Personally, I find that kind of brittleness irritating -
and it also has the potential to waste a huge amount of time if you have to
refactor the code.

Whether you find code less readable with or without module names is of
course a matter taste and IIRC, OCaml 3.11 .annot files contain the
necessary information to expand them so there could be a nice editor plugin
to expand or remove module paths...

> >   The most straightforward solution to this problem to me looks like
> >   providing a syntax equivalent like "from Module import foo, bar"
> >   which selectively imports only some identifiers from a given module.

Which, for values only, is of course a trivial camlp4 extension... and could
be generalised to include type declarations and so on with only a little
more work. The .NET languages have a syntax for selectively importing
classes from a namespace rather than the entire namespace (and it's
different from Java's in that you can rename the class while you do it).


David

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

------=_Part_114771_11770468.1227192364247--