From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id BAE2FD461 for ; Tue, 1 Nov 2005 16:30:47 +0100 (CET) Received: from mail18.bluewin.ch (mail18.bluewin.ch [195.186.19.64]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jA1FUlhi005121 for ; Tue, 1 Nov 2005 16:30:47 +0100 Received: from [10.0.1.2] (62.203.73.48) by mail18.bluewin.ch (Bluewin 7.2.068.1) id 435E01BB001E6F90 for caml-list@yquem.inria.fr; Tue, 1 Nov 2005 15:30:46 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <1130803637.488.28.camel@starlight> References: <1130803637.488.28.camel@starlight> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Subject: lablgl (was Re: [Caml-list] Stdlib) Date: Tue, 1 Nov 2005 16:30:51 +0100 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.746.2) X-Miltered: at nez-perce with ID 43678A27.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; epfl:01 lablgl:01 caml-list:01 stdlib:01 ocaml:01 lablgl:01 omitted:01 bug:01 bindings:01 bindings:01 glpix:01 non-obvious:01 api:01 api:01 ocaml:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Le 1 nov. 05 =E0 01:07, Jonathan Bryant a =E9crit : > On another note, I would love to do this other project in OCaml, =20 > but it > is OpenGL intensive (read: based) and LablGL drives me nuts. The =20 > named > argument thing drives me up the wall because it's more information =20 > that > I don't want to have to learn and internalize. Besides the fact that labels can be omitted, I think this is an =20 unfair criticism and that it is actually better to write the labels. =20 Opengl C functions can have up to 11 argument (e.g. glTexSubImage3D, =20 not bound in lablgl), if you use this function you will have, labels =20 or not, to look up its documentation. You can see the advantage of =20 labels once you are reading your code looking for a bug. If you don't =20= write the labels you will have to read again the documentation to =20 check that you passed everything at the right place, with labels you =20 needn't. These bindings are very carefully done (the "meta-programmation" of =20 glue code is worth having a look if you once have to do bindings) and =20= the interface is quite elegant. The only critique I have about the =20 library is that it doesn't define everything in a single module Gl =20 but scatters functions in different modules whose prefix doesn't =20 necessarily match the prefix of the C function name. For example : - glLoadMatrix is GlMat.load - glLogicOp is GlFunc.logic_op - glPixelStore is GlPix.store. etc. This non-obvious name mapping makes it harder to learn the api and to =20= port C OpenGL code samples. I don't understand this design decision, =20 especially because, in the end, the documentation you need to consult =20= is the C api documentation and therefore there should be an obvious =20 mapping between C and ocaml names. Defining a single module Gl so =20 that a C function name glDipDap is trivially mapped to Gl.dip_dap =20 would be much more productive for the programmer. Daniel