Browse thread
[Caml-list] Why must types be always defined at the top level?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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 >>system. > > 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 harder... > 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. ;-) Cheers, - 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