Stdlib

Stdlib

[Jonathan Bryant]

Wow, guys.  Thanks for the responses.  That really cleared up my
question :).  I (unfortunately) have to learn some of the STL for
another project and the thought occurred to me.

On another note, I would love to do this other project in OCaml, but it
is OpenGL intensive (read: based) and LablGL drives me nuts.  The named
argument thing drives me up the wall because it's more information that
I don't want to have to learn and internalize.  If the author of that
package reads this list, then I apologize.  You've done a fantastic job
of mapping the API, but I really do not like the OCaml syntax for both
Labeled and Optional arguments in general.  Does anyone know of an
OpenGL package that is /complete/ and /not/ labeled?  There is, of
course, the option of writing a module/set of modules that use the
existing C stubs an are not labled, but that would be a last-ditch
effort.

Thanks!

--Jonathan Bryant
  jtbryant@valdosta.edu
  Student Intern
  Unix System Operations
  VSU Information Technology

"Das Leben ohne Music ist einfach ein Irrtum, eine Strapaze, ein" Exil."
("Life without music is simply an error, a pain, an exile.")
--Frederich Nietzsche

"The three cardinal values of a programmer are laziness, impatience, and
hubris."
--Perl Man Page

Re: [Caml-list] Stdlib

[Jacques Garrigue]

From: Jonathan Bryant <jtbryant@valdosta.edu>

> On another note, I would love to do this other project in OCaml, but it
> is OpenGL intensive (read: based) and LablGL drives me nuts.  The named
> argument thing drives me up the wall because it's more information that
> I don't want to have to learn and internalize.  If the author of that
> package reads this list, then I apologize.  You've done a fantastic job
> of mapping the API, but I really do not like the OCaml syntax for both
> Labeled and Optional arguments in general.  Does anyone know of an
> OpenGL package that is /complete/ and /not/ labeled? 

Well, you're entitled to your own opinion.
A few years ago we had a few discussions on this list that were worse
than that.
Yet, a result of these discussions is that labeled arguments are much
less intrusive than before.
The explanation is in the tutorial part of the manual. Namely:

   As an exception to the above parameter matching rules, if an
   application is total, labels may be omitted. In practice, most
   applications are total, so that labels can be omitted in
   applications.

That is, you don't have to write labels in your code.
At least not for non-optional arguments.
Optional arguments still require a label.

The examples going with lablGL are heavily labelled, but you are not
forced to write it that way. As another example, GlDraw.vertex takes
labeled and optional arguments, but you can also use
GlDraw.vertex[234] which take tuples.

So I'd suggest you try to use it without labels.
And maybe later you will realize that, when reading your code later
on, your prefer to have labels. Or maybe your opinion won't change
anyway...

On the other hand, I don't know whether lablGL qualifies as complete,
as it only implements openGL 1.2, without extensions.

Jacques Garrigue

Re: [Caml-list] Stdlib

[Jon Harrop]

On Tuesday 01 November 2005 00:07, Jonathan Bryant wrote:
> On another note, I would love to do this other project in OCaml, but it
> is OpenGL intensive (read: based) and LablGL drives me nuts.  The named
> argument thing drives me up the wall because it's more information that
> I don't want to have to learn and internalize.  If the author of that
> package reads this list, then I apologize.  You've done a fantastic job
> of mapping the API, but I really do not like the OCaml syntax for both
> Labeled and Optional arguments in general.  Does anyone know of an
> OpenGL package that is /complete/ and /not/ labeled?  There is, of
> course, the option of writing a module/set of modules that use the
> existing C stubs an are not labled, but that would be a last-ditch
> effort.

You can omit the labels in most cases. I've done my fair share of OpenGL 
programming, both from C/C++ and from OCaml, and I was quite surprised to 
hear that Jacques has had complaints about his API. The C interface is flat 
and unlabelled because C doesn't support hierarchical interfaces, polymorphic 
variants and labelled/optional arguments. There is still room for improvement 
with lablGL but the API alone is a significant step in the right direction, 
IMHO.

After all, if you have an aversion to labelled arguments you can always omit 
the labels. :-)

I would value safety above completeness but writing a safe (and still 
efficient) interface to OpenGL is difficult.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

lablgl (was Re: [Caml-list] Stdlib)

[Daniel Bünzli]

Le 1 nov. 05 à 01:07, Jonathan Bryant a écrit :

> On another note, I would love to do this other project in OCaml,  
> but it
> is OpenGL intensive (read: based) and LablGL drives me nuts.  The  
> named
> argument thing drives me up the wall because it's more information  
> that
> I don't want to have to learn and internalize.

Besides the fact that labels can be omitted, I think this is an  
unfair criticism and that it is actually better to write the labels.  
Opengl C functions can have up to 11 argument (e.g. glTexSubImage3D,  
not bound in lablgl), if you use this function you will have, labels  
or not, to look up its documentation. You can see the advantage of  
labels once you are reading your code looking for a bug. If you don't  
write the labels you will have to read again the documentation to  
check that you passed everything at the right place, with labels you  
needn't.

These bindings are very carefully done (the "meta-programmation" of  
glue code is worth having a look if you once have to do bindings) and  
the interface is quite elegant. The only critique I have about the  
library is that it doesn't define everything in a single module Gl  
but scatters functions in different modules whose prefix doesn't  
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  
port C OpenGL code samples. I don't understand this design decision,  
especially because, in the end, the documentation you need to consult  
is the C api documentation and therefore there should be an obvious  
mapping between C and ocaml names. Defining a single module Gl so  
that a C function name glDipDap is trivially mapped to Gl.dip_dap  
would be much more productive for the programmer.

Daniel

Re: lablgl (was Re: [Caml-list] Stdlib)

[Jonathan Bryant]

On Tue, 2005-11-01 at 10:30, Daniel Bünzli wrote:
> Le 1 nov. 05 à 01:07, Jonathan Bryant a écrit :
> 
> > On another note, I would love to do this other project in OCaml,  
> > but it
> > is OpenGL intensive (read: based) and LablGL drives me nuts.  The  
> > named
> > argument thing drives me up the wall because it's more information  
> > that
> > I don't want to have to learn and internalize.

Ok, wow.  Didn't mean to make people mad.  It was more a rant that was
not meant for comment and was /definitely not a bash on LablGL/.  I was
just trying to say that I, in general and as a personal preference,
don't like labels.  It's not just an OCaml thing.  I don't use it in any
language that offers it.  I apologize if I was unclear.  I understand
the value but I just find them (incredibly) annoying.  Again, personal
preference.  I was /only/ using LablGL as an example of labled arguments
because it was a /relevenat/ libray that uses labels.  Sorry...

-- 
--Jonathan Bryant
  jtbryant@valdosta.edu
  Student Intern
  Unix System Operations
  VSU Information Technology

"Das Leben ohne Music ist einfach ein Irrtum, eine Strapaze, ein" Exil."
("Life without music is simply an error, a pain, an exile.")
--Frederich Nietzsche

"The three cardinal values of a programmer are laziness, impatience, and
hubris."
--Perl Man Page

Stdlib

[Jonathan Bryant]

Quick (and rather random question) about the standard library.  I
noticed that, like the STL, many of the modules are very similar and
implement many of the same functions (iter, map, etc.).  Unlike the STL
or the Java Standard API, these modules are each completely
independent.  Why hasn't there been a push to do something like
functorize these modules?  For example: List, Array, Hashtbl, Set, and
Map are all collections.  Couldn't you factor out something to make it
easier to extend the library, sort of like the Java API?  Parametric
Polymorphism handles the generics of the elements of the set, so
couldn't the algorithms be factored out leaving three distinct parts
(Elements, Collections of Elements, Operations on Collections), sort of
like in the STL?

I know Java and C++ are bad words here, but you have to admit that at
least that part of Sun's library is rather well designed as is, for the
most part, the STL.  Give the devil his due, I guess... :)

--Jonathan Bryant
  jtbryant@valdosta.edu
  Student Intern
  Unix System Operations
  VSU Information Technology

"Das Leben ohne Music ist einfach ein Irrtum, eine Strapaze, ein" Exil."
("Life without music is simply an error, a pain, an exile.")
--Frederich Nietzsche

"The three cardinal values of a programmer are laziness, impatience, and
hubris."
--Perl Man Page