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 KAA06775; Wed, 15 May 2002 10:51:22 +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 KAA06773 for ; Wed, 15 May 2002 10:51:21 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g4F8pJH01553 for ; Wed, 15 May 2002 10:51:19 +0200 (MET DST) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id RAA08578; Wed, 15 May 2002 17:51:01 +0900 (JST) To: visigoth@cs.cmu.edu Cc: markus@oefai.at, caml-list@inria.fr Subject: Re: [Caml-list] Turning off type-checking In-Reply-To: <86ptzyb8x8.fsf@laurelin.dementia.org> References: <20020514233326Q.garrigue@kurims.kyoto-u.ac.jp> <20020514231719.GA21332@fichte.ai.univie.ac.at> <86ptzyb8x8.fsf@laurelin.dementia.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020515175100E.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 15 May 2002 17:51:00 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: John Prevost > >>>>> "mm" == Markus Mottl writes: > > mm> I don't think that I really hit the exponential wall anywhere > mm> so it's probably just that type-checking takes much longer > mm> than I had expected. Well, I can live with it... > > Note that it's not type-checking that's painful so much as type > reconstruction. If it were possible to provide O'Caml with an > explicitly typed representation, simply checking the types should be > quite easy. (Is it well typed? Is it not well typed?) Type > reconstruction, on the other hand, requires term unification and the > like, and takes a bit more effort. That's not so clear. Unification in itself is not very expensive, not necessarily more than matching. Things only become slow when types are big, and this would be the same in a language without type reconstruction. The fact is that you get much more easily big types in ocaml, just because you don't have to write them :-) and also because lots of type equalities are by structure. Yet, I believe that ocamlc is faster than most java compilers, and java doesn't have type reconstruction. > How hard would it be (probably difficult) to expose an explicitly > typed layer from the system for automatic code generators? This would be easy, but dangerous. And you would have to do your own type inference anyway, to put the proper types on the nodes, so I'm not sure you would gain anything. If you want to try, the code is in driver/compile.ml. Just get rid of the beginning of Compile.implementation: Pparse.file and Typemod.type_implementation. For efficiency you probably want to build your tree with another program, dump it with output_value, and recover it here with input_value. If all internal types are very simple, this may be efficient. Jacques ------------------- 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