Blog on camlcity.org

Blog on camlcity.org http://blog.camlcity.org en Articles by Gerd Stolpmann about O'Caml About LambdaRank http://blog.camlcity.org/blog/lambdarank.html http://blog.camlcity.org/blog/lambdarank.html <div> <b>The ranking algorithm behind GODI Search</b><br>  </div> <div> The question has always been: Are the results better if a search engine really understands the text it indexes? You can view my latest project, <a href="http://docs.camlcity.org">GODI Search</a>, as an attempt to answer this question for a very limited set of documents, namely the code and its documentation of <a href="http://godi.camlcity.org">GODI</a>, the source code O'Caml distribution. Actually, understanding text allows it to rank the results better, so that the more important occurrences of the query words are shown more at the beginning of the result list. Because ranking really bases on text interpretation, and the text is here a variant of lambda code, I call this method LambdaRank. </div> <div> <p>As every search engine, GODI Search consists roughly of two main components, namely the indexer and the searcher. The indexer iterates over the set of documents, and populates a database with the words it extracts. The searcher is the simpler part of the game, as it finds everything well-prepared in this database, and when a query comes in, it only has to pull the matching documents out of the database, sort it according to the ranking score, and show it to the user. So the tricky part is the indexing. </p><p>If you don't understand the text at all, you cannot do much about ranking but count the occurrences of a word in a document. The idea is that a text that speaks about a certain subject also mentions the subject more often than other texts, and thus the number of occurrences is a good measure for ranking. In a document set where the texts are connected with hyperlinks one can furthermore look at the relationships between the documents. Google's PageRank is based on this approach (but, as rumors say, is now heavily modified from its original design). </p><p>Fortunately, we know a lot about the document set GODI Search analyzes. Most documents are like this: </p><ul> <li><a href="http://docs.camlcity.org/docs/godipkg/3.10/godi-ocaml/lib/ocaml/std-lib/list.mli">O'Caml module interfaces</a> </li><li><a href="http://docs.camlcity.org/docs/godipkg/3.10/godi-ocaml/lib/ocaml/std-lib/list.ml">O'Caml module implementations</a> </li><li><a href="http://docs.camlcity.org/docs/godipkg/3.10/godi-omake/doc/godi-omake/html/omake-doc.html">Technical manuals</a> </li><li><a href="http://docs.camlcity.org/docs/godipkg/3.10/apps-coq/share/emacs/site-lisp/coq.el">Code in programming languages other than O'Caml</a> </li><li><a href="http://docs.camlcity.org/docs/godipkg/3.10/apps-coq/lib/coq/ide/utf8.v">Code in exoctic languages</a> </li></ul> O'Caml code files and closely corresponding manuals dominate the corpus. GODI Search tries to make the best of this by analyzing O'Caml code in detail. <p>After looking at many examples I had some ideas which occurrences must be ranked higher than others. </p><p><b>Idea 1. Definitions of identifiers are more important than uses.</b> This sounds natural, but actually not every definition is important. GODI Search also looks at the scope of the definition: A local definition is restricted to a surrounding function, and scores the least. Then follow definitions on module level, and in top-level modules. The highest score is given to exported identifiers that occur in top-level module interfaces. </p><p>Only let-bound identifiers are ranked this way. Function arguments, variables in pattern matchings, and fun-bound identifiers are ignored. This is a bit arbitrary, but my feeling is that these identifiers are usually not important in the coding styles I'm aware of. </p><p>For types, exceptions, and module names similar scoring techniques exist. </p><p><b>Idea 2. Values and types are rated separately.</b> The namespace of all identifiers can be roughly divided into two big zones: Values and types. Of course, there are more kinds of identifiers (modules, classes, labels, file names,...), but my impression is that the typical programmer has a mind set that is dominated by only these two classes of symbols. In this sense, a "value" names an executable thing, and a "type" names meta data. Both have little to do with each other, and thus a document that contains many words "list" as type has little importance in a search for "list" as value. </p><p><b>Idea 3. Keywords are stopwords.</b> Keywords occur in practically every code file in big number, and thus say nothing about it. GODI Search simply ignores keywords. </p><p><b>Idea 4. Qualified identifiers are hyperlinks.</b> If you search for "mem" then you will get a list of top-level definitions of this function. The question is which occurrence is shown first. GODI Search implements the PageRank idea of scoring hyperlinks pointing to a document by looking at qualified identifiers. So if there are more "Hashtbl.find" than "List.find" in code anywhere in the corpus, the module "Hashtbl" scores higher than "List". (Actually, it is the other way round if you also take other references into account.) </p><p><b>Idea 5. Code and non-code are rated separately.</b> Of course, the above applies only to text sections that are O'Caml code. Other languages and non-code cannot be rated this way. For this reason, GODI Search puts a lot of effort into separating both types of text. Currently, this is done on a per-paragraph basis, i.e. every paragraph is first analyzed in order to know whether it is O'Caml code or not. Also, comments and string literals in code files are considered as non-code. </p><p>So far about the ideas behind LambdaRank. The results of the implementation look promising: If the user types in "fold_left" he or she will be taken to really relevant occurrences. And user experience is what counts, finally. </p> </div> <div> Gerd Stolpmann works as O'Caml consultant </div> <div> <p><b>Links:</b> <ul> <li><a href="http://docs.camlcity.org">GODI Search</a>: Try out GODI Search here </li> <li><a href="http://godi.camlcity.org">GODI Homepage</a>: About GODI in general </li> </ul> </p> </div> Cross-Language Cluster Computing http://blog.camlcity.org/blog/hydrostory.html http://blog.camlcity.org/blog/hydrostory.html <div> <b>The Story Behind Hydro</b><br>  </div> <div> On the surface a search engine looks like a very simple web site, but actually most things happen in the backend, and are hidden from the user. A search engine consists of 10 to 20 different types of servers, and many of them are instantiated several times in a cluster configuration. No single programming language is well suited for the entire implementation. In addition, some language environments may have compelling libraries that are lacking in other languages. It is, however, still difficult to let servers written in different languages communicate with each other. At Wink, we decided to go with ICE, and to develop the missing O'Caml implementation ourselves. </div> <div> <p>For two years now I have done consulting work for <a href="http://wink.com">Wink Technologies</a> who started out as a user-powered search engine, but switched later to people search. Actually, people search began as an experiment, and was originally developed in O'Caml with some Java standard components. It turned out that O'Caml was very well suited for crawling and parsing, and that our solution was convincing enough so we could go on with O'Caml as implementation language. It was also a big plus that it was already possible to develop server clusters in O'Caml with Ocamlnet's SunRPC implementation - we only had to add a highly available directory and configuration service. However, the problem of SunRPC is that there is no good C++ implementation (interestingly, there is an acceptable one for Java, RemoteTea). Too bad, since SunRPC is simple and robust, and its type system matches the one of O'Caml quite well (there are records, arrays, variants, and option types). </p><h2>ICE: An RPC Middleware</h2> <p>Looking for an alternative, somebody came up with ICE ("Internet Communications Engine"). This is a commercial product by <a href="http://zeroc.com">ZeroC</a> which is dual-licensed under the GPL (like e.g. MySQL). There are implementations for a number of languages, including C++, Java, Python, and PHP, but unfortunately not for O'Caml. Well, this is no surprise, but at least the other company languages are covered. So we looked closer at ICE. Does it match our needs? </p><p>ICE follows the object-oriented paradigm. For an RPC middleware this means that a remote call is seen as sending a message to a remote object. Of course, it is possible to have several such objects of the same type, and creating instances is made possible by a class construct. Such a design is very acceptable, but unfortunately object orientation often meant in the past that the rest of the type system was crippled. To some degree, this also happened to ICE - especially, there are no variants and no option types. Well, not optimal, but there are at least clean "design patterns" how to emulate these missing features with classes, and for pure OO languages like Java the ICE approach simplifies the language mapping. </p><p>Unlike CORBA, there is a fixed protocol the components have to use to talk to each other. That means a client in language X can directly contact a server in language Y, and there is no need for an intermediate instance to translate the protocol. Basically, this means you can use ICE without any infrastructure - no central server you are dependent upon. For developing massively parallel cluster services this is an essential requirement, because such central servers don't scale well enough, and are single points of failure. </p><p>For using ICE in a cluster context, there is the IceGrid add-on. Basically, this is a highly available directory and configuration service, and serves for a similar purpose like the service we had developed for SunRPC before. Clients ask IceGrid where to find their servers in the network, and IceGrid replies with a suggestion of TCP ports. This can be used for load-balancing and for high availability. </p><h2>Hydro: Implementing ICE for O'Caml</h2> <p>After ICE was found to be good enough, we needed an implementation for O'Caml. Well, this was my field - I already developed the SunRPC support in Ocamlnet years ago, and this made me an expert for this type of work. It took only about 3 weeks until it was possible to generate client code, and about another week until server support was ready. However, it was still challenging work, because the ICE type system needed to be mapped to O'Caml's type system. Furthermore, the ICE reference manual was full of errors, and everything had to be checked against ZeroC's implementation. </p><p>The difficulty of the type mapping is that ICE demands that objects and exceptions can be downcasted. O'Caml, however, does not support this operation, because there is no efficient implementation of downcasting for a type system like O'Caml's that includes structural subtyping. Nevertheless, downcasting is a reasonable operation in the context of RPC, and it is hardly possible to get around it. </p><p>Maybe an example demonstrates this best. In Slice, the IDL for ICE, one can easily define a hierarchy of classes (the syntax resembles Java's): </p><blockquote lang="x-slice"> <code><pre> class SearchResult { string url; string title; } class PeopleSearchResult extends SearchResult { string name; } class BandSearchResult extends SearchResult { string bandName; stringSeq bandMembers; } </pre></code></blockquote> <p>When the search engine returns a <code>SearchResult</code> item, it can also be one of the descendants of this class. Of course, a client of the search engine that simply wants to display the result, needs to know all details, and thus downcasts <code>SearchResult</code> to the real subclass. </p><p>In a normal OO program one can get rid of this downcast by adding an operation for displaying the result: </p><blockquote lang="x-slice"> <code><pre> class SearchResult { string url; string title; string display(); } </pre></code></blockquote> In an RPC context such an addition might be difficult, however, or may break some other principle of the RPC design. Basically, RPC is about marshalling data, and that means getting data out of the context of one server and forcing them into the context of another server. The "unity of data and operations", one of the OO principles, is intentionally given up. <p>Note that ICE allows to define operations for classes, and operations are always executed in the context of the data. In this example, it would be in deed possible to define <code>display</code> in a reasonable way, and to avoid the downcast. However, <code>display</code> then becomes part of the protocol, although it is rather a detail of the client. Anyway, one quickly faces the situation where downcasting is unavoidable. </p><p>In the O'Caml mapping generated by Hydro, these three classes would appear like </p><blockquote lang="x-ocaml"> <code><pre> class type o_SearchResult = object inherit o_Ice_Object method url : string ref method title : string ref end class type o_PeopleSearchResult = object inherit o_SearchResult method name : string ref end class type o_BandSearchResult = object inherit o_SearchResult method bandName : string ref method bandMembers : string array ref end val as_SearchResult : #Hydro_lm.object_base -> o_SearchResult val as_PeopleSearchResult : #Hydro_lm.object_base -> o_PeopleSearchResult val as_BandSearchResult : #Hydro_lm.object_base -> o_BandSearchResult </pre></code></blockquote> This is a bit simplified, but shows the idea. The ICE classes are mapped to O'Caml classes with some hidden machinery. The data members appear as O'Caml methods returning references - the most direct translation of this concept. The class hierarchy corresponds to the hierarchy in ICE, so the O'Caml operator for upcasting, :>, can be directly used. The hidden machinery comes into play by inheriting from <code>o_Ice_Object</code>, the root of the ICE hierarchy, and by using <code>object_base</code>, an even smaller antecedent that defines the marshalling core. <p>The downcast operation is emulated by defining conversion functions for every class type: <code>as_PeopleSearchResult</code> checks whether the argument is a <code>PeopleSearchResult</code> in reality, and if so, casts it to this class type. If not, an exception is raised. </p><p>Of course, this emulation is a bit inconvenient, but this is mostly a problem of generating good code. From a user's perspecitve, there is not much difference between calling a generated conversion function, or using a built-in language operation. It makes, however, the whole generated code a lot more difficult to understand. </p><h2>The Story Continues</h2> Missing support for RPC middleware is one of biggest concerns when using a new language in enterprises. In a startup company like Wink it is possible to address these concerns, because such companies are open for unconventional solutions (and ICE is unconventional - the industry standards are CORBA and DCOM in the LAN, and HTTP-based protocols like SOAP in the Internet). Finally, by integrating several languages into the system it was possible to deliver some components quicker and with better quality because we could choose the best language for every component. <p>In the people searcher context we use now both SunRPC and ICE. The former is arguably better when only O'Caml components have to talk with each other, and the latter is for crossing the language boundaries. </p> </div> <div> Gerd Stolpmann works as O'Caml consultant </div> <div> <p><b>Links:</b> <ul> <li><a href="http://wink.com">Wink Technologies</a>: Company homepage </li> <li><a href="http://www.zeroc.com">ZeroC</a>: Company homepage, ICE documentation, ICE implementation for a number of languages </li> <li><a href="http://remotetea.sourceforge.net">RemoteTea</a>: SunRPC for Java </li> <li><a href="http://oss.wink.com/hydro">Hydro</a>: ICE for O'Caml </li> <li><a href="http://projects.camlcity.org/projects/ocamlnet.html">Ocamlnet</a>: Internet library for O'Caml with SunRPC support </li> </ul> </p> </div> Mixing Apples And Pears http://blog.camlcity.org/blog/polyvariants.html http://blog.camlcity.org/blog/polyvariants.html <div> <b>Using Polymorphic Variants</b><br>  </div> <div> It is one of the coolest language constructs, but its conception leads sometimes to confusion. O'Caml allows it to form ad-hoc unions of tagged values, the so-called polymorphic variants. They are the free-style counterpart of the "normal" variant types. We want to shed some light on this construction in this article, and encourage programmers to try it out. </div> <div> <p> The most baffling property of the polyvariants is that one can mix tags that come from different pieces of code. We'll give an example of that later in the text, but first let's explain some foundations. Syntactically, the tags are written with a leading reverse apostrophe, so for example <code>`Apple</code> is a (value-less) tag. Like the normal variants the tags can have attached values, so for instance <code>`Pear "it's sweet man"</code> is a tag with a string value. It is not required to declare polyvariant types, one can simply start creating such tagged values in the code. </p><h2>Data Analysis Step-By-Step</h2> <p>Imagine we want to analyze a string. In a first step, we would like to classify every character of the string, and determine whether it is a letter, a digit, or something else. Using polyvariants, this function does the job: </p><blockquote lang="x-ocaml"> <code><pre> let classify_chars s = let rec classify_chars_at p = if p < String.length s then let c = s.[p] in let cls = match c with | '0'..'9' -> `Digit c | 'A'..'Z' | 'a'..'z' -> `Letter c | _ -> `Other c in cls :: classify_chars_at (p+1) else [] in classify_chars_at 0 </pre></code> </blockquote> <p>So this function would return this list for the input string "a56*": </p><blockquote lang="x-ocaml"> <code><pre>[ `Letter 'a'; `Digit '5'; `Digit '6'; `Other '*' ] </pre></code> </blockquote> <p>Note that there is no type declaration! If you enter this function into the O'Caml toploop, you see that its type is inferred like this: </p><blockquote lang="x-ocaml"> <code><pre> val classify_chars : string -> [> `Digit of char | `Letter of char | `Other of char ] list = <fun> </pre></code> </blockquote> <p>Read this as: The function returns tagged values with tags <code>`Digit</code>, <code>`Letter</code>, or <code>`Other</code>, and every tag has an attached character. Note the "greater than" sign at the beginning of the tag list. It means that this tag list is compatible with being mixed with completely unrelated tags. There are also polyvariant types where this sign is reversed (like in <code>[<...]</code>), or completely missing. We'll come back to that later. </p><p>Back to our string analysis example. We are now interested in recognizing integer numbers in the list of classified characters. We assume our input is a list that contains <code>`Digit</code> tags, but also other tags. In the output list, sequences of <code>`Digit</code> are replaced by <code>`Number</code>: </p><blockquote lang="x-ocaml"> <code><pre> let recognize_numbers l = let rec recognize_at m acc = match m with | `Digit d :: m' -> let d_v = Char.code d - Char.code '0' in let acc' = match acc with | Some v -> Some(10*v + d_v) | None -> Some d_v in recognize_at m' acc' | x :: m' -> ( match acc with | None -> x :: recognize_at m' None | Some v -> (`Number v) :: x :: recognize_at m' None ) | [] -> ( match acc with | None -> [] | Some v -> (`Number v) :: [] ) in recognize_at l None </pre></code> </blockquote> <p>The inferred type of this function is now really strange: </p><blockquote lang="x-ocaml"> <code><pre> val recognize_numbers : ([> `Digit of char | `Number of int ] as 'a) list -> 'a list = <fun> </fun></pre></code> </blockquote> <p>Basically, it says that there is a tagged list as input, and that the output list has the same tags. Furthermore, the ">" sign again signals extensibility, so we can not only use the tags mentioned in the function, but any other tag as well. Especially, we are free to pass <code>`Letter</code> and <code>`Other</code> tags in: </p><blockquote lang="x-ocaml"> <code><pre> recognize_numbers [ `Digit '1' ; `Digit '3'; `Letter 'a'; `Digit '2'; `Other '*' ] </pre></code> yields <code><pre> [ `Number 13; `Letter 'a'; `Number 2; `Other '*'] </pre></code> </blockquote> <p>Note that the type of the <code>recognize_numbers</code> function does not reflect all what we could know about the function. We can be sure that the function will never return a <code>`Digit</code> tag, but this is not expressed in the function type. We have run into one of the cases where the O'Caml type system is not powerful enough to find this out, or even to write this knowledge down. In practice, this is no real limitation - the types are usually a bit weaker than necessary, but it is unlikely that weaker types cause problems. </p><p>The really great thing about the polymorphic variants is that it is possible to mix tags that come from different contexts. So in our example we can combine the two functions, and apply one after the other: </p><blockquote lang="x-ocaml"> <code><pre> let analyze s = recognize_numbers (classify_chars s) </pre></code> </blockquote> <p>It is no problem that <code>classify_chars</code> emits tags that are completely unknown to <code>recognize_numbers</code>. And both functions can use the same tag, <code>`Digit</code>, without having to declare in some way that they are meaning the same. It is sufficient that the tag is the same, and that the attached value has the same type. </p><p>This may have big advantages for structuring programs. Of course, our example of string analysis already benefits from the loose type correspondence the polyvariants make possible. The problem can now be divided into several steps, and every step needs only to know the tags it operates on. There is no global type all steps have to agree upon, rather every step sees only the fraction of type information that is needed for the task. </p><h2>Limiting Tags</h2> <p>Compare these two functions: </p><blockquote lang="x-ocaml"> <code><pre> let number_value1 t = match t with | `Number n -> n | `Digit d -> Char.code d - Char.code '0' let number_value2 t = match t with | `Number n -> n | `Digit d -> Char.code d - Char.code '0' | _ -> failwith "This is not a number" </pre></code> </blockquote> <p>The difference is that the second version explicitly catches the case of "any other tag" whereas the first version leaves this unspecified. This leads to different typings: </p><blockquote lang="x-ocaml"> <code><pre> val number_value1 : [< `Digit of char | `Number of int ] -> int val number_value2 : [> `Digit of char | `Number of int ] -> int </pre></code> </blockquote> <p>So in the first version we have a "<" sign! This sign usually only appears for input arguments, and means that the function can only process these tags (or less tags), but no other tags. The type checker prevents that any other tag can be passed in: </p><blockquote lang="x-ocaml"> <code><pre> # number_value1 (`Letter 'a');; This expression has type [> `Letter of char ] but is here used with type [< `Digit of char | `Number of int ] </pre></code> </blockquote> <p>In the second version of the function, this case is handled at runtime. From a typing perspective, the ">" sign signals that the function can also accept other tags than the mentioned ones. However, this function actually raises an exception. </p><blockquote lang="x-ocaml"> <code><pre> # number_value2 (`Letter 'a');; Exception: Failure "This is not a number". </pre></code> </blockquote> <p>So the "<" sign is a way to limit the number of tags a function can process. The programmer gets it by not adding a "catch all" case to pattern matchings. This kind of polyvariant is useful to enforce some strictness in programming, and the type checker catches the cases that would otherwise only be handed at runtime. </p><h2>Giving Polyvariants Names</h2> <p> Although the mantra of this article is that we don't need declarations, it is of course possible to define named polymorphic variants. For example, we could introduce these named types: </p><blockquote lang="x-ocaml"> <code><pre> type classified_char = [ `Digit of char | `Letter of char | `Other of char ] type number_token = [ `Digit of char | `Number of int ] </pre></code> </blockquote> <p>Note that there is no ">" or "<" sign in such definitions - it would not make sense to say something about whether more or less tags are possible than given, because the context is missing. </p><p>Using these names, one could simplify the typings of our functions: </p><blockquote lang="x-ocaml"> <code><pre> val classify_chars : string -> [> classified_char ] val recognize_numbers : ( [> number_token ] as 'a) list -> 'a list val number_value1 : [< number_token ] -> int val number_value2 : [> number_token ] -> int </pre></code> </blockquote> <p>As you see, the ">" or "<" sign can still appear in function types using these names. Actually, there is a special syntax behind this notation. If you just say <code>number_token</code> in a type expression, exactly the definition applies (without sign). But you can also construct new polyvariants from existing ones. For example, </p><blockquote lang="x-ocaml"> <code><pre>[ classified_char | number_token ] </pre></code> </blockquote> <p>would mean a type that combines the tags of both types, i.e. this is the same as if all four tags were enumerated. The syntax <code>[<number_token ]</code> is only a special case of this type constructor, where the new type also gets a sign. </p><h2>Matching Variants</h2> <p>Try to compile this piece of code that ought to sum up all <code>`Digit</code> and <code>`Number</code> tags of a list of any tags: </p><blockquote lang="x-ocaml"> <code><pre> let rec sum l = match l with | x :: l' -> ( match x with | `Digit _ | `Number _ -> number_value1 x + sum l' | _ -> sum l' ) | [] -> 0 </pre></code> </blockquote> <p>It compiles, but there is a little surprise. The compiler emits a warning that the <code>_ -> sum l'</code> case of the matching is unused, and the inferred type is just </p><blockquote lang="x-ocaml"> <code><pre> val sum : [ `Digit of char | `Number of int ] list -> int </pre></code> </blockquote> i.e. the ">" sign is missing that would allow us to pass any tags in. What's wrong? <p>This is a pitfall one quickly runs into when using polyvariants. The type checker assumes that the <code>x</code> in <code>number_value1 x</code> has the same type as the <code>x</code> that is matched again. It is not sufficient to use a matched variable in the expression of the matched case to restrict its type. Fortunately, there is a special syntax for that (look at the bold "as" clause): </p><blockquote lang="x-ocaml"> <code><pre> let rec sum l = match l with | x :: l' -> ( match x with | (`Digit _ | `Number _) <b>as y</b> -> number_value1 <b>y</b> + sum l' | _ -> sum l' ) | [] -> 0 </pre></code> </blockquote> <p>Here, <code>y</code> is the value <code>x</code> for the case that the match applies, so <code>y</code> can have a stricter type than <code>x</code>. </p><p>Alternatively, the match condition could also have been written as: </p><blockquote lang="x-ocaml"> <code><pre> match x with | #number_token as y -> ... </pre></code> </blockquote> i.e. one can use named polyvariants in matchings. This is just a convenience notation for the former. <h2>Behind The Scene</h2> <p>The polyvariants might be cool, but many programmers suspect that the performance of their programs suffer when they use them. Well, although there are some runtime cost, these are very small, and not noticeable for many programs. </p><p>Internally, the tags are represented by hash values of the names of the tags. So the tags are simply reduced to integers at runtime. Compared with the normal variant types, there is some additional overhead for tags with values. In particular, for storing <code>`X value</code> one extra word is needed in comparison with the normal variant <code>X value</code>. </p><p>It is possible that the hash values of variants collide, e.g. </p><blockquote lang="x-ocaml"> <code><pre> # type x = [ `jagJhn | `oZshTt ];; Variant tags `jagJhn and `oZshTt have same hash value. Change one of them. </pre></code> </blockquote> As you see, the compiler checks for this rare case. I've never seen it in practice. <p>Despite rumours, there is nothing special done at link time. The tags are already cut down to integers at this point of compiling. </p><h2>Conclusion</h2> <p>I hope I've shown how elegant code looks that uses polyvariants to represent data cases. But there is some more to say, especially if you look at other programming languages. </p><p>The author of this article thinks that polymorphic variants are one of the features that makes O'Caml so different in comparison with mainstream languages like Java. In particular, there are competing approaches for representing data cases, and one of the radical ideas of object orientation has always been that combining data and program cases into a single class construct is the best way to deal with the problem. However, I think something has been overlooked - data and algorithms do not always walk hand in hand, and classes are inflexible if only a loose correlation between both is needed. In contrast, polyvariants give the programmer the maximum of freedom in this respect. Thus it is believed that polyvariants are a serious alternative for representing data cases. </p> </div> <div> Gerd Stolpmann works as O'Caml consultant </div> <div> <p><b>Links:</b> <ul> <li><a href="http://caml.inria.fr/pub/docs/manual-ocaml/manual006.html#htoc41">Polymorphic variants</a>: Chapter in the O'Caml manual </li> </ul> </p> </div>