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

[Jon Harrop <jon@ffconsultancy.com>]

On Tuesday 15 January 2008 09:01:42 Jacques Garrigue wrote:
> 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.

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