Re: [Caml-list] From a recursive circuit to a functional/recursive OCaml-code...

[Bill Wood <william.wood3@comcast.net>]

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