Browse thread
From a recursive circuit to a functional/recursive OCaml-code...
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2006-02-05 (05:55) |
From: | Bill Wood <william.wood3@c...> |
Subject: | Re: [Caml-list] From a recursive circuit to a functional/recursive OCaml-code... |
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