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 605E0BC69 for ; Wed, 16 Jan 2008 05:47:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KAE4bjUfUnw6Elmdsb2JhbACCNo1UAQEBAQcEBiIHnFg X-IronPort-AV: E=Sophos;i="4.24,291,1196636400"; d="scan'208";a="6097828" Received: from pih-relay05.plus.net ([212.159.14.132]) by mail2-smtp-roc.national.inria.fr with ESMTP; 16 Jan 2008 05:47:15 +0100 Received: from [80.229.56.224] (helo=beast.local) by pih-relay05.plus.net with esmtp (Exim) id 1JF0BF-0005AC-Qm for caml-list@yquem.inria.fr; Wed, 16 Jan 2008 04:47:14 +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: Wed, 16 Jan 2008 04:40:09 +0000 User-Agent: KMail/1.9.7 References: <200801150459.03896.jon@ffconsultancy.com> <200801151817.33017.jon@ffconsultancy.com> <20080116.122627.-10635426.garrigue@math.nagoya-u.ac.jp> In-Reply-To: <20080116.122627.-10635426.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: <200801160440.09295.jon@ffconsultancy.com> X-Spam: no; 0.00; hash:01 variants:01 ocaml's:01 marshalling:01 ocaml:01 compiler:01 semantics:01 hash:01 runtime:01 hashing:01 lablgl:01 clashing:01 lablgl:01 stubs:01 stubs:01 On Wednesday 16 January 2008 03:26:27 Jacques GARRIGUE wrote: > > I suspect OCaml's marshalling is used almost entirely between same > > versions of the same programs. > > I'm not so sure. Actually, I do it all the time when recompiling > ocaml. Otherwise I would have to bootstrap after any modification in > the compiler. Fortunately, this is not the case, and one only needs to > bootstrap when the data structures are modified (or semantics changed). Interesting. > > 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. > > No, because in order to produce efficient code you have to know the > hash at compile time, and in your scheme you only know it at link time > or runtime. You could still use the same hashing scheme but you could fall back to linear search of symbols by name in the event of a clash. > > 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. > > I don't see your point. Even with the extension mechanism, extra > GLenum's are still only allowed for some specific functions. So you > can still define some subsets of GLenum that should be conflict free, > you don't need to prohibit all conflicts in GLenum. This is what I > mean by lablGL's design. Provided you can enumerate which tags can be used with which functions including the presence of extensions, yes. I suppose that would be possible and you could end up with many small sets of tags and much less chance of clashing. > The problem with lablGL and extensions is the implementation, not the > API design. What we would need was some kind of AOP approach to the > stubs, where you could describe what functions are extended by which > extensions. I think it would be better to remove all complexity from the C stubs, have them all autogenerated and then write a higher-level API on top entirely in OCaml. GLCaml is the start of a good foundation for OpenGL, IMHO. I think it would be very productive to merge the projects at some point. > ... > I don't agree with all these points (otherwise I wouldn't be > maintaining a GUI toolkit), but there is some truth in it. I actually > got similar reactions from industry in Japan, if for different > reasons: they don't need the GUI, because they prefer to do it > themselves, to differentiate from others. People doing in-house > programming have a different point of view. I remember somebody from a > bank who told me he wrote a program to be used in all their branches > using labltk. In this case you don't need anything flashy, it just has > to be functional (err, to work). > > Concerning IDEs, since eclipse is more and more used, good support > for it seems a must. But you won't have me use anything other than > emacs and ocamlbrowser! Visual Studio's Intellisense makes GUI programming much easier in F# than ocamlbrowser+ocaml. I think the single most productive thing that could be added to ocamlbrowser is hyperlinks from the quoted definitions to all related definitions. Now that I come to think of it, you can just run ocamldoc on the LablGTK sources and use a browser to do that. Is the ocamldoc HTML output for the latest LablGTK2 on the web anywhere? > > 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. > > The current FFI works well, but it's true that the way it cuts the > work in small pieces (stubs in C on one side, externals on the other) > makes it difficult to automate its use. In my experience it is very > flexible, but badly lacks abstraction. What sorts of abstractions would you like? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e