From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 2B05DBBA7 for ; Sun, 5 Feb 2006 06:55:56 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k155ttRE010009 for ; Sun, 5 Feb 2006 06:55:55 +0100 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 GAA07101 for ; Sun, 5 Feb 2006 06:55:55 +0100 (MET) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k155trTA010006 for ; Sun, 5 Feb 2006 06:55:54 +0100 Received: from 192.168.1.100 (c-24-118-210-113.hsd1.mn.comcast.net[24.118.210.113]) by comcast.net (rwcrmhc11) with SMTP id <20060205055552m11005s5tve>; Sun, 5 Feb 2006 05:55:52 +0000 Subject: Re: [Caml-list] From a recursive circuit to a functional/recursive OCaml-code... From: Bill Wood To: Oliver Bandel Cc: caml-list@inria.fr In-Reply-To: <20060205041600.GA5936@first.in-berlin.de> References: <20060204211943.GA590@first.in-berlin.de> <1139106546.8453.87.camel@rosella> <20060205041600.GA5936@first.in-berlin.de> Content-Type: text/plain Date: Sat, 04 Feb 2006 23:55:51 -0600 Message-Id: <1139118951.18593.20.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1-1mdk Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 43E5936B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 43E59369.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 recursive:01 recursive:01 ocaml-code:01 oliver:01 bandel:01 model:01 synchronous:01 ocaml:01 tokens:01 inputs:01 inputs:01 manifests:01 model:01 recursion:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 On Sun, 2006-02-05 at 05:16 +0100, Oliver Bandel wrote: . . . > Is it necessary to have state-variables in a record? > Is it then (with records) functional implementation?! If I understand your problem correctly, you're looking for a way to model a synchronous dataflow network in OCaml. To do this, I think you need a global state to capture the simultaneous presence of data tokens on each input of each function in your network. The record mentioned above could contain a field for each input line; at the next tick of the clock the functions are applied to their inputs, and their outputs then fill in fields of the record corresponding to the next set of inputs. The dataflow aspect then manifests as the necessity to get new values from the "x" input line, for there's no other way to set that field in the next record. This approach brings into sharp focus the initialization problem -- initially, there are no inputs on the "e" inputs to either block "A" or "B". Thus you have to specify how a block fires with one or more undefined inputs. You might model this by defining the type of data running around the system to be something like "mydata option", and then define how the various functions act when one or more inputs are "None". Finally, the initial state record would have "None" in each field corresponding to "no input available". . . . > But I'm not clear about how to write this function "f", > because it needs mutual recursion... > In a purely impeative way I think i woulf find a solution, > but thinking about it in Ocaml => blackout. ;-( By using the state record you avoid having to write the block functions as direct mutual recursions; instead, all the functions take the state record as input and together (along with the input stream) define the next state record. . . . > and inside "f" there also is a feedback. This approach takes care of the feedback at the expense of having to model each block as operating with one or more inputs latched low, say, until upstream functions finally supply data. -- Bill Wood