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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 953F3BBAF for ; Fri, 30 May 2008 03:48:31 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMGADH6Pkg+TcsDVGdsb2JhbACSIAEWBAcIDzScbw X-IronPort-AV: E=Sophos;i="4.27,564,1204498800"; d="scan'208";a="13237205" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 May 2008 03:48:31 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m4U1mS4l018932 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 30 May 2008 03:48:31 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMGADH6Pkg+TcsDVGdsb2JhbACSIAEWBAcIDzScbw X-IronPort-AV: E=Sophos;i="4.27,564,1204498800"; d="scan'208";a="13237202" Received: from a.relay.invitel.net ([62.77.203.3]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 May 2008 03:48:28 +0200 Received: from mail.invitel.hu (mail.invitel.hu [213.163.59.4]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 7BE8D371D90 for ; Fri, 30 May 2008 03:48:27 +0200 (CEST) Received: from ephubudl0046.budapest.epam.com ([93.92.56.245]) by mail.invitel.hu (Invitel Messaging Server) with ESMTPA id <0K1N005E6RORSQ80@invitel.hu> for caml-list@inria.fr; Fri, 30 May 2008 03:48:27 +0200 (CEST) Date: Fri, 30 May 2008 03:48:27 +0200 From: Adam Granicz Subject: Re: [Caml-list] syntax question In-reply-to: <483F54A5.4020808@cs.caltech.edu> To: "caml-list@inria.fr" Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-transfer-encoding: 7BIT References: <483F2CEC.7020701@cs.caltech.edu> <483F54A5.4020808@cs.caltech.edu> User-Agent: Opera Mail/9.24 (Win32) X-Miltered: at concorde with ID 483F5CEC.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; syntax:01 compiler:01 constructors:01 constructors:01 arity:01 afaik:01 syntax:01 foo:01 0200,:01 vanier:01 mvanier:01 afaik:01 ocaml:01 foo:01 0200,:01 Hi Mike, I suspect this was a choice made by the compiler writers - by special-casing constructors (thus making them different from ordinary functions) you avoid some "complications" (and create new ones), for instance no partial constructors (although IMHO there is a valid case for them - instead you have to resort to eta expansion) - this forces that each constructor fulfills its "arity". AFAIK, the revised syntax takes care of the above issues and you can construct testme values as Foo 1 2. Regards, Adam. On Fri, 30 May 2008 03:13:09 +0200, Michael Vanier wrote: > Adam, > > I realize that this is how it works, but I don't understand why it > should work this way. AFAIK elsewhere in ocaml "int * int" always refers > to a tuple. Similarly, if testme's Foo really took two int arguments I > would expect to be able to create Foos as "Foo 1 2" instead of "Foo (1, > 2)" which looks like Foo takes a single tuple argument, not two int > arguments. I don't see why "int * int" and "(int * int)" are different > things. > > Mike > > Adam Granicz wrote: >> Hi Michael, >> In the type definition >> >>> # type testme = Foo of int * int;; >> the constructor Foo takes *two* int arguments (thus, you can not >> construct a testme value supplying only one argument), whereas in >> >>> # type testme2 = Foo2 of (int * int);; >> it takes *one* tuple argument. >> Regards, >> Adam. >> On Fri, 30 May 2008 00:23:40 +0200, Michael Vanier >> wrote: >> >>> Hi everyone, >>> >>> I got bitten by a simple syntax problem: >>> >>> # let a = (1, 2);; >>> val a : int * int = (1, 2) >>> # type testme = Foo of int * int;; >>> type testme = Foo of int * int >>> # Foo a;; >>> The constructor Foo expects 2 argument(s), >>> but is here applied to 1 argument(s) >>> # Foo (1, 2);; >>> - : testme = Foo (1, 2) >>> # type testme2 = Foo2 of (int * int);; >>> type testme2 = Foo2 of (int * int) >>> # Foo2 a;; >>> - : testme2 = Foo2 (1, 2) >>> >>> Why does the compiler treat int * int and (int * int) in type >>> definitions so differently? Is it to give clearer error messages in >>> the typical case? >>> >>> Mike >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> 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