From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id AA4A8BC69 for ; Thu, 5 Jul 2007 15:23:17 +0200 (CEST) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [203.16.214.135]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l65DNFdY014604 for ; Thu, 5 Jul 2007 15:23:16 +0200 X-IronPort-AV: E=Sophos;i="4.16,503,1175437800"; d="scan'208";a="111978295" Received: from ppp121-44-3-31.lns4.syd7.internode.on.net (HELO [192.168.1.201]) ([121.44.3.31]) by ipmail03.adl2.internode.on.net with ESMTP; 05 Jul 2007 22:53:12 +0930 Subject: Re: [Caml-list] Incremental, undoable parsing in OCaml as the general parser inversion From: skaller To: oleg@pobox.com Cc: psnively@mac.com, caml-list@inria.fr In-Reply-To: <20070705081338.D090BAD43@Adric.metnet.fnmoc.navy.mil> References: <20070705081338.D090BAD43@Adric.metnet.fnmoc.navy.mil> Content-Type: text/plain Date: Thu, 05 Jul 2007 23:23:11 +1000 Message-Id: <1183641791.12890.57.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 468CF0C3.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 parser:01 oleg:01 delimited:01 combinator:01 parser:01 inverting:01 inverted:01 inverting:01 gtk:01 rewriting:01 gtk:01 monadic:01 model:01 implicitly:01 On Thu, 2007-07-05 at 01:13 -0700, oleg@pobox.com wrote: > The beauty of delimited continuations is that we take any function > that accepts some kind of `callback' and pass a specifically > constructed callback (which is essentially shift f f). Thus we have > accomplished inversion. The function in question can be a map-like > traversal combinator (the callback is the function to map), a parser > (the callback here is the stream, the function that provides data to > the parser), a GUI system with its own event loop, etc. Unfortunately what you need for a GUI is not control inverting the callback -- programmers in industry do that every day: it's an extremely common task. Of course the way they do it is naive and laborious. But it isn't the real problem.. it's the GUI event loop that needs to be inverted. Luckily that can be done for both X- and MS- Windows by the simple expedient of not writing an event loop in the first place!! In both systems, there is no event loop. The API provides a function to read the message queue -- writing an event loop is the users job .. so inverting it is easy .. just don't write it! Unfortunately .. doing that throws away all the GUI toolkits out there -- GTK is gone, for example. They were all written the wrong way .. Rewriting GTK in a monadic style is not going to be so easy .. it's rather a lot of code and much of the interface is *based* on the standard C model, where continuations are passed by pushing the return address implicitly onto the machine stack. Luckily .. most of the work done in a GUI tool kit can be done much better using Open GL anyhow .. and OpenGL is algorithmic not event driven. In particular SDL is also algorithmic, not even driven. So .. if you really want to invert GTK .. you are left with the system supported control inversion device, which is more or less universal and works with some C code at least .. Posix threads. After all the *primary* job of an operating system is precisely control inversion. -- John Skaller Felix, successor to C++: http://felix.sf.net