Re: [Caml-list] Re: Hash clash in polymorphic variants

[Jacques GARRIGUE <garrigue@math.nagoya-u.ac.jp>]

> > From: Jon Harrop <jon@ffconsultancy.com>
> > > 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.

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).

> 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).

Marshalling data between different versions of the same program is ok,
but you're on your own concerning compatibility. You must be careful
concerning changes in ocaml versions, but I don't remember any change
in representation, and if one were to happen it would be amply
documented.

> > > 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.

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. 

> 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.

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.

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.

> 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.

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!

> > 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.

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.

Jacques Garrigue