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=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 78279BBCA for ; Thu, 3 Apr 2008 17:24:35 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYCAKqT9EfC2fJXfGdsb2JhbACRVwEBCwUCBQkWmhY X-IronPort-AV: E=Sophos;i="4.25,599,1199660400"; d="scan'208";a="10384057" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 03 Apr 2008 17:24:35 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m33FOUNi024176 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 3 Apr 2008 17:24:35 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYCAKqT9EfC2fJXfGdsb2JhbACRVwEBCwUCBQkWmhY X-IronPort-AV: E=Sophos;i="4.25,599,1199660400"; d="scan'208";a="10384053" Received: from anchor-post-37.mail.demon.net ([194.217.242.87]) by mail1-smtp-roc.national.inria.fr with ESMTP; 03 Apr 2008 17:24:30 +0200 Received: from orion.metastack.com ([80.177.38.218]) by anchor-post-37.mail.demon.net with esmtp (Exim 4.68) id 1JhRIj-0003Xk-Pa for caml-list@inria.fr; Thu, 03 Apr 2008 15:24:30 +0000 Received: from countertenor (cpc1-cmbg6-0-0-cust264.cmbg.cable.ntl.com [81.101.137.9]) (authenticated bits=0) by orion.metastack.com (8.13.4/8.13.3) with ESMTP id m33ExdXq001987 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 3 Apr 2008 15:59:41 +0100 From: "David Allsopp" To: References: <906164100804030708p3e2788a0p29b69f4d46600622@mail.gmail.com> Subject: RE: [Caml-list] Operators for Int64 and Int32 Date: Thu, 3 Apr 2008 16:24:21 +0100 Organization: MetaStack Solutions Ltd. Message-ID: <002201c8959e$cb9e74f0$017ca8c0@countertenor> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <906164100804030708p3e2788a0p29b69f4d46600622@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciVkSfDM13WPmkPSZ+t9O5pGUKmUwACpFqw X-Scanned-By: MIMEDefang 2.63 on 172.16.28.218 X-Miltered: at discorde with ID 47F4F6AE.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 intentional:01 overloading:01 sub-modules:01 stdlib:01 mitigate:98 imho:01 readable:01 caml-list:01 int:01 int:01 writes:01 strings:01 snip:02 snip:02 I totally agree that expressions manipulating Int64 and Int32 quickly become illegible, however I don't agree with your suggestions... > Int64.add (Int64.mul (Int64.add a b) b) c;; > > especially when you try to avoid exceeding a limit of 79 characters in > line. OT: May I politely suggest that perhaps your coding standards could do with updating to mitigate part of this. Unless you're still on an 80x25 character terminal limiting yourself to 79 characters per line is pretty archaic. We use 150 character max line limit (and print in landscape if necessary) because every display we work on has a resolution of at least 1280x1024. > The best solutions to those problem would be in my opinion to add > something like this to standard library (to new module): > > let ( +^^ ) a b = Int64.add a b > > let ( +^ ) a b = Int32.add a b My problem with this, as someone who writes a lot of OCaml but uses Int64 and Int32 rarely, is that these operators aren't clearly anything to do with Int64 or Int32 in terms of their "names" (symbols). Defining funny strings of symbols to get around the (intentional) limitations of not having operator overloading is IMHO not something that should be in the standard library. If you're writing code that uses the operations so frequently that clarity requires aliases then your code will be much more readable if you have: (* other, non-Int64/32 code *) let ( +^^ ) a b = ... and ( -^^ ) a b = ... ... in (* * A block of code of reasonable length that makes extremely dense use of * the above operators. *) (* Perhaps more non-Int64/32 code *) That said, you could do it your way and my way with the aid of pa_openin which allows you to open a module just within a block of code which would save writing out the operators every time - for *your* code. cout << "Adding lots of strange-looking operators (even in sub-modules \ that would need to be opened) to the StdLib is one step down the slippery \ slope to C(++) operator hell..." Just my two pennyworth... David