From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 690D9BCA5 for ; Tue, 30 Nov 2004 18:33:28 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iAUHXRLG020739 for ; Tue, 30 Nov 2004 18:33:28 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA16949 for ; Tue, 30 Nov 2004 18:33:27 +0100 (MET) Received: from smtp003.mail.ukl.yahoo.com (smtp003.mail.ukl.yahoo.com [217.12.11.34]) by concorde.inria.fr (8.13.0/8.13.0) with SMTP id iAUHXRwa020732 for ; Tue, 30 Nov 2004 18:33:27 +0100 Received: from unknown (HELO ?192.168.1.113?) (vincenzo?ml@82.49.163.184 with plain) by smtp003.mail.ukl.yahoo.com with SMTP; 30 Nov 2004 17:33:26 -0000 From: Vincenzo Ciancia To: caml-list@inria.fr Subject: Re: [Caml-list] Re: Functional Reactive Programming in OCaml? Date: Tue, 30 Nov 2004 18:33:30 +0100 User-Agent: KMail/1.7 References: <13110.1101783772@dsl-207-245-69-66.cust.oldcity.dca.net> In-Reply-To: <13110.1101783772@dsl-207-245-69-66.cust.oldcity.dca.net> Cc: bcpierce@cis.upenn.edu MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200411301833.31143.vincenzo_mlRE.MOVE@yahoo.it> X-Miltered: at concorde with ID 41ACAEE7.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41ACAEE7.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 wrote:01 abstraction:01 booleans:01 api:01 wrote:01 haskell:01 compiler:01 inlining:01 ocaml:01 haskell:01 event-based:01 bytecode:01 runtime:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Tuesday 30 November 2004 04:02, Benjamin Pierce wrote: > The common idea in these systems is to introduce an abstraction of > "signals" -- roughly, functions from time to "values", where the > values can be anything from real numbers (conventional > signal-processing-type signals) to two- or three-dimensional > pictures, to booleans (representing events). What's special is that > time is represented as a continuous, real-number quantity. =A0They do > all kinds of work behind the scenes to actually compute with > behaviors, but what shows through in the API is a very simple, > elegant, and powerful set of primitives that can be combined in > straightforward ways to achieve very complex effects. I am surely not an expert on the subject, but I tried this at home in a=20 student project at university. I wrote a library for composition of=20 monomorphic signal functions. It was just a simple attempt but I found=20 two things: 1. arrow composition in haskell can be very efficient - you usually=20 implement your actions in terms of IO actions, and IO actions=20 composition is _I suppose_ optimized somewhat by the compiler, e.g.=20 inlining functions as needed to form a bigger code block. However you=20 can compose as many arrows as you want without degrading performance. Parallel or sequential arrow composition in ocaml will certainly involve=20 =2D as in the haskell implementation - something "like" function=20 composition, and this will result in efficiency proportional to the=20 number of functions involved, which is unwanted. The performance gap=20 between an event-based loop and "fran-like" code is discouraging for=20 this reason. But you could generate bytecode at runtime and avoid this=20 problem (and even beat haskell to please your language envy :)). I=20 would seriously consider the second alternative if I had the time to=20 work on it. 2. you are sometimes constrained to reveal implementation of your arrows=20 when implementing composition, due to the value restriction - you=20 certainly know this better than me, and I couldn't explain this=20 anymore, the search function on the mailing list archives is not=20 working or else I'd find an example I posted years ago and forgot=20 about :) If you are interest I'll download the raw archives and find=20 it. Hope this helps - I would be interested in an implementation of FRAN for=20 ocaml even if I am not so sure that I might be of any help. Vincenzo