Re: [Caml-list] exene and ocaml ?

[skaller <skaller@users.sourceforge.net>]

On Thu, 2004-04-01 at 17:25, Ville-Pertti Keinonen wrote:
> On Apr 1, 2004, at 7:08 AM, briand@aracnet.com wrote:
> 
> > Has anyone in the ocaml community ever even considered porting this to
> > ocaml ?  

> > Thread based gui implementations are the way to go (aren't they ?)

You may be interested in Felix. Control inversion is a central
concept, that is, translating a program that reads events
into an event driven one, automatically. Felix threads
are cooperatively multi-tasked, the system supports
millions of threads and fast O(1) switching is possible.

At present, Felix generates C++, however the control inversion
mechanism isn't language specific, all it requires is classes with
methods, and some kind of switch statement. Ocaml has both,
so retargetting to Ocaml may be possible. The back end isn't
fully decoupled from the front end yet though, and the lack
of a goto in Ocaml may impact performance. On the other hand
the Ocaml GC is bound to be superior to the naive implementation
I provide.

> It's one way to do things, but by no means the only way.  A 
> single-threaded event model works reasonably well for GUIs, especially 
> in most current languages where threads are needlessly expensive.

Event driven programming model requires manual
state management. In losing the stack, the most powerful
structuring tool available to the progammer is lost,
and the damage is severe. Simple GUI are easy to get going
but more complex ones are almost impossible to write.

Felix is designed to use a threading programming model,
but an event driven implementation: the best of both worlds.
It's specifically designed to cope with telecommunications and games,
both of which require extremely high performance, and both
of which are almost impossible to program with conventional
programming models. 

> How is this approach dependent on threads? 

In a GUI, there is a notion of a thread for each
window. The locus of control is an important
part of the state. This makes each window an active
process which consumes events.

In an event driven model, control is dispatched
in a displeasing way that requires the locus
of control for each window to be lost.

[Replace 'window' with 'widget' or 'sprite'
or 'active agent' or 'anything you like to think
of as *in control* rather than *being controlled*']

> You can escape your modal loop without modifying "globals" 
> (I don't see why state variables would need to be global) 

Simple: there is no stack. Event handlers have to return,
and when they do the stack is lost.

Of course, you can partition your global state space
into objects, but that in no way changes the fact
the state space is still global.

If you make linked lists of objects, then of course
you can emulate a stack. The question is: why should you
do all the housekeeping to manage stacks when the
functional and structured programming models do it for you.

There is a good reason why you write:

	f = open("filename");
	d = f.read();
	..
	f.close()

The operating system implements control inversion because
an event driven program that reads a file:

	method receive_data d = ...

would be make it rather hard to encode algorithms.

Control inversion of file handling is so important
it is central to the operating system concept: one could say
that a DOS (Disk Operating System) system has one primary
function: control inversion of file handling.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners