Re: [Caml-list] Teaching bottomline, part 3: what should improve.

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

From: Jon Harrop <jon@ffconsultancy.com>

> To solve GUI programming you need different constructs (events,
> message pumps etc.).
> 
> Look at some of the example F# programs on our site. This Sudoku
> solver uses a worker thread to keep the GUI responsive while it
> solves puzzles:
> 
>   http://www.ffconsultancy.com/dotnet/fsharp/sudoku/index.html
> 
> This ray tracer uses concurrency for incremental update of a responsive GUI:
> 
>   http://www.ffconsultancy.com/dotnet/fsharp/raytracer/index.html
> 
> This particle simulator runs the simulation thread in parallel with the GUI 
> thread, for real-time visualization of the particle system:
> 
>   http://www.ffconsultancy.com/products/fsharp_for_visualization/demo3.html
> 
> In the future, I hope OCaml will support concurrency not only to handle 
> parallel constructs but also to handle GUI programming elegantly. If
> there is one thing that I have been singularly impressed by from
> .NET, it is GUI programming.

But... this is exactly the kind of things for which you can already
use concurrency in ocaml. For instance, lablgtk2 provides a GtkThread
module, which lets you run the GUI in another thread, and post updates
asynchronously. This is also possible with labltk, albeit not
documented.
I do not say this is elegant in its current form, but we are limited
by the underlying library.

There are weaknesses, like the fact you cannot kill a worker thread,
but this looks like a limitation of posix threads, since you can do it
with bytecode threads.

Jacques Garrigue