For some time, rather desultorily recently, I'll admit, I've been
working on Qi/tk. But when complete it will amount to a complete type
secure GUI builder with all the GUI power of TCL/tk and a user-
programmable interface and connection to the web. This is part of the
L21 project (http://www.lambdassociates.org/lC21.htm).

It's significant work and rather hard to develop, requiring detailed
knowledge of TCL/tk and command of Qi's sequent notation and how it
works. To give you an idea of just how complex just the type theory
is - it scales in at 12,000 lines of Lisp and rising. That is 2X the
size of Qi itself! Without Qi technology I really couldn't hope to
attempt this task.

My original intention had been to release it, like Qi, as a complete
system in its own right. But Qi took years and I don't want to repeat
a Sisyphean task. Hence Qi/tk has sat on my machine for a long time.

So what I've decided to do is to develop this system through a series
of phased releases in which a block at a time is released, tested
under the open source community at Qilang, corrected and improved
through your feedback.

Mark Tarver wrote:

I think you're approaching this from the wrong direction...

Mark Tarver wrote:

You may be interested in the LablTK bindings to Tk in the OCaml standard
library, which provide Tk interoperability with the assurances of static
typing. They weigh in at 41kLOC of OCaml, which is ~9%% of the OCaml
distribution.

There are also 74kLOC of bindings to GTK2 as a separate package: LablGTK2.

Right; seems sensisble.

< They weigh in at 41kLOC of OCaml, which is ~9%% of the OCaml

Yes; 41k LOC does not surprise me. The saving grace is that my 12k
LOC are machine-generated from Qi and are not hand written. The hand
written sources are only 1.5k LOC of largely sequent calculus.

Mark

Mark Tarver wrote:

That's very nice. If I were to write such libraries, I would use a similar
approach. However, if you want to provide a sane and native-friendly
representation of the underlying API there is going to be a lot of work
that (probably) cannot be automated.

I'm looking forward to using the autogenerated GLCaml bindings to OpenGL
2.1:

http://glcaml.sourceforge.net/

In the case of an evolving API such as OpenGL, I think it is essential to
automate as much of the low-level interface code generation as possible,
just as you have done.

I have long thought that bindings to good libraries are a real weak point of
all functional programming languages, so it is always good to see better
libraries being created and released. I wonder if there is any scope for
collaboration between the major FPL communities in trying to improve this
situation...

On Sun, Jul 22, 2007 at 08:44:41AM +0100, Jon Harrop wrote:

Are you thinking about an abstract definition of bindings in a
functional style, which could be the source for the automatically
generation of language specific bindings?

Regards,
Daniel

Jon Harrop wrote:

On 22 Jul, 15:20, Ken Tilton optonline.net> wrote:

Ken Tilton wrote:

Probably need to compare features to find out. What programs are written
using Cells-Gtk, how much of GTK (2?) does it support, is it safe etc.?

Daniel Trstenjak wrote:

I was thinking more along the lines of a higher-level intermediate API that
provided static typing and run-time types. That way dynamically typed
languages can ignore the static types and statically typed languages can
progagate them.

This is not too dissimilar to .NET and interoperating with C# from F# is
vastly nicer than interoperating with (say) C++ from OCaml.