From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id CFDFEBB81 for ; Fri, 24 Feb 2006 14:40:15 +0100 (CET) Received: from irma.motion-twin.com (irma.motiontwin.com [213.186.50.39]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k1ODeF3n011674 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 24 Feb 2006 14:40:15 +0100 Received: from [61.213.94.147] (helo=[192.168.5.12]) by irma.motion-twin.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.54) id 1FCdB5-00025N-3s; Fri, 24 Feb 2006 14:40:11 +0100 Message-ID: <43FF0CA9.8000500@motion-twin.com> Date: Fri, 24 Feb 2006 22:39:53 +0900 From: Nicolas Cannasse User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jacques Garrigue Cc: lukstafi@gmail.com, caml-list@yquem.inria.fr Subject: Re: [Caml-list] (int * int) <> int*int ? References: <00c201c638b1$b2b96860$1f570b50@mshome.net> <20060224.090116.89069794.garrigue@math.nagoya-u.ac.jp> <4a708d20602231618r4839fe7wa695e9084df8fd40@mail.gmail.com> <20060224.111728.88698334.garrigue@math.nagoya-u.ac.jp> In-Reply-To: <20060224.111728.88698334.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 43FF0CBF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; cannasse:01 ncannasse:01 motion-twin:01 caml-list:01 syntax:01 variants:01 syntax:01 constructors:01 constructors:01 polymorphic:01 constructor:01 argument:01 argument:01 int:01 int:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 >>>This unfortunate syntax has consequences down to polymorphic variants, >>>which otherwise could be represented more efficiently. >>> >> >>This is interesting, could you explain it shortly? > > > The tuple based syntax for constructors is ambiguous: there is no way > to know syntactically whether a constructor takes as argument a tuple > or separate arguments. This is the reason for this whole discussion. Yes this is not a very big problem but is quite often reported. The reason I see is that (int * int) and int * int are perceived the same because parenthesis are optional when applying the * operator in calculus. In order to fix this, I choose to always have parenthesis for multiple arguments constructors in NekoML : type a { A : int; B : (int , int); // 2 arguments C : ((int , int)); // 1 tuple argument } It is then more easy to understand the difference between B and C, although this is in the end just a matter of using an appropriate syntax. The parenthesis are just abusely used in different manners in most of languages syntax. Nicolas