From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id C97FDBC69 for ; Tue, 15 Jan 2008 19:24:40 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KABCJjEfUnw6Dnmdsb2JhbACCNY1UAQEBAQcEBimbPQ X-IronPort-AV: E=Sophos;i="4.24,288,1196636400"; d="scan'208";a="6078332" Received: from pih-relay04.plus.net ([212.159.14.131]) by mail2-smtp-roc.national.inria.fr with ESMTP; 15 Jan 2008 19:24:40 +0100 Received: from [80.229.56.224] (helo=beast.local) by pih-relay04.plus.net with esmtp (Exim) id 1JEqSn-0003yA-3c for caml-list@yquem.inria.fr; Tue, 15 Jan 2008 18:24:41 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Hash clash in polymorphic variants Date: Tue, 15 Jan 2008 18:17:32 +0000 User-Agent: KMail/1.9.7 References: <200801140956.25449.ober.14@osu.edu> <200801150459.03896.jon@ffconsultancy.com> <20080115.180142.123979196.garrigue@math.nagoya-u.ac.jp> In-Reply-To: <20080115.180142.123979196.garrigue@math.nagoya-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801151817.33017.jon@ffconsultancy.com> X-Spam: no; 0.00; hash:01 variants:01 marshalling:01 variants:01 ocaml's:01 marshalling:01 hash:01 lablgl:01 run-time:01 lablgl:01 guis:01 ocaml:01 ocaml:01 vastly:01 guis:01 On Tuesday 15 January 2008 09:01:42 Jacques Garrigue wrote: > From: Jon Harrop > > On Tuesday 15 January 2008 03:36:21 Jacques Garrigue wrote: > > > Unfortunately, this would make marshalling between different programs > > > much more complicated... > > > > Do people marshal polymorphic variants between different programs? > > Do people marshal data between different programs (or different > versions of the same program)? I suspect OCaml's marshalling is used almost entirely between same versions of the same programs. In particular, I was advised against marshalling data between different versions of the same program because this is unsafe (not just type safety but the format used by Marshal is not ossified). > > So the advantage of a decision tree is probably insignificant on real > > code because it will lie between these two extremes. > > Since the goal was never to be faster than ordinary variants, but just > obtain comparable speed, this seems good :-) Yes. This would probably also work ok if you used a symbol table to store exact identifier names rather than just a hash. The symbol's index in the table would serve the same purpose as the hash. > > > Now concerning the risks of name conflicts. The main point of > > > polymorphic variants is that there is only a conflict if the two tags > > > appear in the same type. And logically the type should stay small. > > > If you want to put all GLenum's inside the same type, then you may > > > well end up with conflicts. But what LablGL shows is that in practice > > > only a small number of tags are used together. > > > > Can LablGL's design support OpenGL extensions? > > I'm not sure what this means. OpenGL has an extension mechanism that can be queried at run-time. If a given extension is available then you can do things that you could not do before, such as pass a GLenum to a function that might not have accepted it without the extension. > Since LablGL was coded by hand, adding extensions would mean modifying > it. Exactly, that is a limitation of LablGL's design and, therefore, I think it is was quite wrong of you to claim "LablGL shows is that in practice only a small number of tags are used together" when LablGL's use of small, closed sum types is actually a design limitation that would not be there if it supported all of OpenGL, i.e. the extension mechanism. Incidentally, Xavier made a statement based upon what appears to me to be a similar logical error in the CUFP notes from last year that I read recently: "On the other hand, certain features seem somewhat unsurprisingly to be unimportant to industrial users. GUI toolkits are not an issue, because GUIs tend to be built using more mainstream tools; it seems that different competencies are involved in Caml and GUI development and companies "don't want to squander their precious Caml expertise aligning pixels". Rich libraries don't seem to matter in general; presumably companies are happy to develop these in-house. And no-one wants yet another IDE; the applications of interest are usually built using a variety of languages and tools anyway, so consistency of development environment is a lost cause." - http://cufp.galois.com/CUFP-2007-Report.pdf (page 3) Xavier appears to have taken the biased sample of industrialists who already use OCaml despite its limitations and has drawn the conclusion that these limitations are not important to industrialists. I was really horrified to see this because, in my experience, companies are turning away from OCaml in droves because of exactly the limitations Xavier enumerated and I for one would dearly love to see them fixed. OCaml will continue to go from strength to strength regardless but its uptake would be vastly faster if these problems are addressed. To take them point by point: . GUIs are incredibly important (LablGTK is the world's favorite OCaml library!) and tens of thousands of OCaml programmers are crying out for proper LablGTK documentation as a first priority, many of whom are in industry. . Rich libraries are incredibly important and OCaml has the potential to become a hugely successful commercial platform where people can buy and sell cross-platform libraries but OCaml needs support for shared run-time DLLs (or something equivalent) this before this can happen. . An easy-to-use IDE would be an excellent way to kick-start people learning OCaml even if an industrial-strength IDE is intractable. > Also, one might want to make code generation automatic, particularly > for C wrappers, to allow adding cases to functions easily. This should > be doable, but there is no infrastructure for that currently > (using CPP macros was simpler to start with...) Yes. A better FFI could also be enormously beneficial. Improving upon OCaml's FFI is one of the most alluring aspects of a reimplementation on LLVM, IMHO. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e