English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Turning off type-checking
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-05-15 (08:51)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] Turning off type-checking
From: John Prevost <visigoth@cs.cmu.edu>
> >>>>> "mm" == Markus Mottl <markus@oefai.at> 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
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.

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