Browse thread
type abbreviation is cyclic
[
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: | Till Varoquaux <till.varoquaux@g...> |
| Subject: | Re: [Caml-list] type abbreviation is cyclic |
Yes, This used to be a FAQ entry: unless you pass the -rectypes option to ocaml you have to pass through a constructor (record variant...) to break your recursion, this prevents writing empty types such as: type pb = pb * pb You can still write infinite recursive definitions : type a = Succ of a;; let rec infinity = Succ infinity;; AFAIK -rectypes doesn't break any of the programs working before but if you attend to use it you will probably run in problems with type inference (not polymorphic enough). I would recommend steering clear of it for anything else than toy programs. Till On 10/24/07, Brian Hurt <bhurt@janestcapital.com> wrote: > William W Smith wrote: > > > I wonder whether this error is an example of the language being > > defined more restrictively than required. What is the reason that I > > get these results? > > > > type a = int -> one -> int and one = Unused | One of a;; > > type b = int -> b -> int > > > > type a is accepted while type b is not. (b gives "The type > > abbreviation b is cyclic" However, in the uses that I intended, there > > won't be any actual difference between the two. > > > > I'd appreciate an explanation about why there is difference between a > > and b. > > > I *think* this has to do with being able to bottom out data structures. > I mean, consider the following two (similiar) types: > > type a = int * one * int and one = Unused | One of a;; > type b = int * b * int;; > > How do you specify a limited-length member of type b? You can with a > just by inserting Unused in the correct location. But there's no such > "stopping point" for b. > > This makes more sense when you make the linked-list aspect more plain: > > type a = int * next and next = EmptyList | Cons of a;; > type b = int * b;; > > Hopefully someone more knowledgeable than I will post an actual > type-theoretical reason this is so, but this is the pragmatic reason > I've found. > > Brian > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- http://till-varoquaux.blogspot.com/