From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA15021; Thu, 1 Apr 2004 10:20:14 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA18389 for ; Thu, 1 Apr 2004 10:20:13 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i318Ktjq024730 for ; Thu, 1 Apr 2004 10:20:57 +0200 Received: from [192.168.1.200] (ppp113-158.lns1.syd3.internode.on.net [150.101.113.158]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i318Jpwn099541; Thu, 1 Apr 2004 17:49:52 +0930 (CST) Subject: Re: [Caml-list] exene and ocaml ? From: skaller Reply-To: skaller@users.sourceforge.net To: Ville-Pertti Keinonen Cc: briand@aracnet.com, caml-list@pauillac.inria.fr In-Reply-To: References: <16491.38344.186267.44292@soggy.deldotd.com> Content-Type: text/plain Message-Id: <1080807590.13854.260.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 01 Apr 2004 18:19:51 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 gui:01 threads:01 threads:01 model:01 guis:01 model:01 gui:01 threading:01 dispatched:01 modal:01 partition:01 9660:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 8 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