Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
RE: [Caml-list] strange behaviour with variants and "cannot be g eneralized"
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-09-10 (08:12)
From: Fernando Alegre <fernando@c...>
Subject: Re: [Caml-list] strange behaviour with variants and "cannot be g eneralized"
On Wed, Sep 10, 2003 at 09:10:06AM +0200, Beck01, Wolfgang wrote:

>     "In programs, polymorphic variants work like usual ones. You just
>     have to prefix their names with a backquote character `."
> and this is not true, at least in 3.06. After spending another evening
> with weird type errors, I replaced polymorphic variants with ordinary
> ones. My project looks uglier now since I had to split up some files,
> but at least it compiles and runs.

I think polymorphic variants are the trickiest part in OCaml, but once
you understand them, they do indeed work like the usual ones. I found
that when they do not work, it is because I was not defining the types
correctly. Only once I got a very weird behavior, where the compiler
accepted the types but the program failed to link due to unresolved
symbols in a polymorphic variant...

My own experience in one year programming exclusively in OCaml, but
being familiar to both C++ and Lisp before, is something like this:

- 0 months: use either Lisp style (passing functions as arguments
            like crazy, creating complex records of closures and
            do all loops with "let rec"...)
            or C++ style (huge classes with imperative methods,
            for/while loops and extensive use of ";")
            In any case: no inner modules, no functors, no variants
            and, of course, no mli's

- 3 months: realize that most "let rec" can be replaced by X.fold,
            and start adding some inner modules, mli's. Standardize
            data structures, so that all have fold, map, etc..

- 6 months: timidly start using functors, so that cut-and-paste code
            in similar modules is replaced by functor application
            Shorten classes to a few essential methods, and move
            most of the code to functions called from the methods.

- 9 months: Functorize everything! Abstraction, abstraction, abstraction..
            Reduce use of "Open" to the absolute minimum. Move types
            to their own files, and reduce the number of types to the
            few really necessary. Use classes only to simulate polymorphic
            lists, and to interact with lablGtk and lablGl.
            Still no polymorphic variants...

- 12 months: Polymorphic variants everywhere! They make passing data
             between modules so much cleaner...


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: