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

[Jon Harrop <jon@ffconsultancy.com>]

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