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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 26314BBCA for ; Thu, 3 Apr 2008 21:50:42 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMfR9EfAXQIm/2dsb2JhbACmVYVx X-IronPort-AV: E=Sophos;i="4.25,599,1199660400"; d="scan'208";a="9165341" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 03 Apr 2008 21:50:42 +0200 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m33JofNE001097 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 3 Apr 2008 21:50:41 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMBAMfR9EdC+Vyqc2dsb2JhbACRVQEMAwQFCRSUSoVx X-IronPort-AV: E=Sophos;i="4.25,599,1199660400"; d="scan'208";a="24569209" Received: from ug-out-1314.google.com ([66.249.92.170]) by mail4-smtp-sop.national.inria.fr with ESMTP; 03 Apr 2008 21:50:41 +0200 Received: by ug-out-1314.google.com with SMTP id k40so832832ugc.18 for ; Thu, 03 Apr 2008 12:50:40 -0700 (PDT) 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:content-transfer-encoding:content-disposition:references; bh=s/CRZNgFxPgjW8Hn24n+2ARDFJy8gg0nXlBz/erggmE=; b=hKJE0GjV1F8PGYy5HL9QywS+Xh6NF/zAcQj4Ka6HK4YQLwvmG31+buXjkB7n+ynOE/ex46wX8kyWCVLrxI/ZXHl1HlhDHMGEAsopH7BCMDdlx5xt13IbqgylorPlnFSWqxfaoF+Q1sbqiD2i30joPtWnI+UvdmWivyGz5HJDMAY= 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:content-transfer-encoding:content-disposition:references; b=EkZ0EUzZSGjBdP1wm5ENhy2mYX7WYYzM5gjA4c+yzzpWaDcFN+gSVzXoSw/L2x/IxhxiBIoewcYK7oGUi9O0dTwHQH8R2jDLm76cEiE4c7uDCLzXecrGfPUI0Q7lEFocsQDkdKUBFPO+d5wti2qAkoeqhOm1pH3r9tzfaAFdYxE= Received: by 10.67.15.2 with SMTP id s2mr132279ugi.52.1207252240676; Thu, 03 Apr 2008 12:50:40 -0700 (PDT) Received: by 10.67.95.3 with HTTP; Thu, 3 Apr 2008 12:50:40 -0700 (PDT) Message-ID: <906164100804031250k1d77b639ie1dbd203943904c0@mail.gmail.com> Date: Thu, 3 Apr 2008 21:50:40 +0200 From: "=?ISO-8859-2?Q?Micha=B3_Maciejewski?=" To: caml-list@inria.fr Subject: Re: [Caml-list] Operators for Int64 and Int32 In-Reply-To: <002201c8959e$cb9e74f0$017ca8c0@countertenor> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <906164100804030708p3e2788a0p29b69f4d46600622@mail.gmail.com> <002201c8959e$cb9e74f0$017ca8c0@countertenor> X-Miltered: at discorde with ID 47F53511.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; michal:01 ocaml:01 intentional:01 overloading:01 ocaml:01 imho:01 imho:01 ints:01 caml-list:01 int:01 int:01 writes:01 strings:01 strings:01 rarely:02 2008/4/3, David Allsopp : > > 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. > That was just an example, but I think that names of those operators are as funny as the symbol '@' . I don't see any relation between "@" and lists. Just like between '!' and references, or '^' and strings. In C you have the same operator '+' for ints and floats. OCaml provides you with '+' and '+.' . So why not to have corresponding operators for other types? It's better to have one rule than set of rules to learn. Besides mathematical expressions in functional languages should be IMHO as compact as it's possible. Best regards, Mlchal Maciejewski