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] Why must types be always defined at the top level?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-06-23 (16:28)
From: Andreas Rossberg <rossberg@p...>
Subject: Re: [Caml-list] Why must types be always defined at the top level?
skaller wrote:
>>I believe the presence of syntactic names for all generative types is 
>>essential for the theoretical underpinnings of OCaml's type and module 
> This may be so, but I still don't quite understand it.
> In Felix generatives types all have fresh integers
> assigned to them that act as fresh names: there's no 
> separate compilation though. Does that have something
> to do with it?

Don't think so. That could be dealt with easily by a slightly more 
general stamping scheme.

However, a stamp based semantics is a purely operational approach and 
has no proper explanation in type theory. As a consequence, it does not 
scale well to more advanced module features (e.g. functors, particularly 
higher-order ones), and probably other corners of the type system.

And the lack of syntactic types makes communicating errors to the user 

> Oh? Ocaml does not support forward calls of named functions
> across compilation unit boundaries.

Granted, but then it said "intermodule fun calls", not "intermodule fun 
recursion" in your table.

> C++ it is extremely annoying not having functions and their
> scopes as first class .. such a relief to work with Ocaml.
> But then suddenly things that 'just work' in C++ that you 
> take as a 'given' turn out *not* to work in Ocaml.

It is not just nesting functions. Consider local namespaces, template 
namespaces, template typedefs, to name just a few illegal combinations. 
The ways in which the many constructions in C++ can be composed are 
restricted quite arbitrarily and often counter-intuitively.

> Please note the table was not intended to be taken
> seriously on a technical front.

That's understood. Still had to refute some of its more biased content. ;-)


	- Andreas

Andreas Rossberg, rossberg@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

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