Browse thread
cyclic types
[
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: | brogoff <brogoff@s...> |
| Subject: | Re: [Caml-list] cyclic types |
On Sat, 30 Jan 2005, skaller wrote:
> On Sun, 2005-01-30 at 04:12, brogoff wrote:
> > This comes up relatively frequently, and it is known that having -rectypes
> > as the default is not a good idea. However, wouldn't explicit typing of
> > this case sidestep the known problems and eliminate the need for a
> > -rectypes option here?
>
> Do you mean something like:
>
> type rec forest = forest StringMap.t
>
> where the 'rec' means 'just this type is meant to be cyclic'
> (and treat that type as if -rectypes had been given)?
No, I meant just accept the cyclic types as we do now with -rectypes, but
annotate the functions that use them, something like this (pseudo OCaml)
type ('a, 'b) t = 'a * (('a , 'b) t -> 'b) list
let foo : 'a -> (('a * ('b -> 'c) list as 'b) -> 'c = fun n m ->
(List.assoc n m) m
Nice huh, the type is longer than the actual code :-(. Anyways, I rememeber
someone complaining about the overhead of the connstructor wrapping in order to
do this in real OCaml (that is, without -rectypes) and this does away with that.
If it were just cyclic types, it wouldn't be a big deal, but there are other
places that explicit types driving the typing could pay off. There are a couple
of ways to get nonuniform recursion in OCaml but (with the exception of perhaps
the *experimental* recursive module feature) they're clunky workarounds. The
right way is just to annotate the functions with their types.
-- Brian