From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA28303; Fri, 22 Aug 2003 16:20:25 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA19087 for ; Fri, 22 Aug 2003 16:20:23 +0200 (MET DST) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h7MEKMT03087 for ; Fri, 22 Aug 2003 16:20:22 +0200 (MET DST) Received: (qmail 23489 invoked from network); 22 Aug 2003 14:20:18 -0000 Received: from unknown (HELO apprentice.genxnet.com) ([64.81.145.152]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Aug 2003 14:20:18 -0000 Date: Fri, 22 Aug 2003 09:27:33 -0500 From: art yerkes To: caml-list@inria.fr Subject: Re: [Caml-list] Using -dtypes output in conjunction with a preprocessor Message-Id: <20030822092733.612218c9.ayerkes@speakeasy.net> In-Reply-To: <20030822090518.GA4616@roke.freak> References: <20030822023949.16fae994.ayerkes@speakeasy.net> <20030822090518.GA4616@roke.freak> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; yerkes:01 ayerkes:01 caml-list:01 michal:01 moskal:01 malekith:01 pld-linux:01 foo:01 baz:01 foo:01 qux:99 baz:01 fragment:01 unspecified:01 swig:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 22 Aug 2003 11:05:18 +0200 Michal Moskal wrote: > > How about: > > let f x y = foo x y > > and: > > let g x y = > let baz = foo x y in > let qux = foo baz baz in > x + 1 Yes, I know that it's not always possible for caml to predict the type, but the user can resolve such a case with a type annotation. Alternately, I can write in the 'default' case that leaves the data unmarshalled. In either case it's just as much an error to try to have the language guess what types C++ needs as it would be in C++. In addition, I have done several experiments which show that Ocaml does correctly type polymorphic applications that have no other possible types. If you examine the -dtypes output for this code fragment, you'll notice that the expression at character 78 (as recokoned by -dtypes) is correctly typed, even though the real type is unspecified: external ___swig___make_point1 : 'a -> 'b -> 'c = "make_point" let _ = match ___swig___make_point1 3 3 with (a,b) -> print_endline ((string_of_int a) ^ "," ^ (string_of_int b)) | _ -> () If it interests you, here is how Ocaml's type inference *actually* works: "typefoo.ml" 3 64 78 "typefoo.ml" 3 64 99 type( int -> int -> int * int ) The reason why Ocaml can do this, in my recokoning is that any other signature given for this expression would be an error. As far as I can tell, Ocaml will always place a concrete type on an unambiguous expression. Perhaps Mr. Leroy or one of the other gurus can set me straight, however. My goal is not necessarily any philosophical purity. I know that some cases do fail to unify, and I believe thats OK. What I'm fighting is a basic disconnect between the notion of a statically typed overloaded application in C++, and the Ocaml rule that a certain named value has exactly one type. I've looked at gcaml for this same reason, B.T.W, but since I'm trying to balance practical with not, I believe that making the most of the standard Ocaml is best. -- "Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration." - S. Kelly-Bootle ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners