Re: [Caml-list] Re: Functional design for a basic simulation pipe.

[Hugo Ferreira <hmf@inescporto.pt>]

Hello,

Zheng Li wrote:
> Hi,
> 
> Hugo Ferreira <hmf@inescporto.pt> writes:
>> My question is: how can one design and implement such a "pull pipe" and
>> solve the problem I have of propagating state back to a previous
>> function. If this is not possible functionally what other options do I
>> have? Better yet, what is the better way to implement such a system?
> 
> It seems that you want to program in a dataflow paradigm in OCaml. You don't
> have to use concurrent programming if you find it heavyweight, instead you
> should use stream (or lazy, or other sth alike) which is already provided by
> OCaml.
> 

Original idea was to use lazy data/functions and composition of
functions to do this. Issue is how to pass back a value so as to provide
feedback and alter the stream's output.

> Usually, you'll define a set of combinators include: map, dup, pipe, filter,
> until, combine/split, merge/switch etc to facile your work. 

Hmmm... these combinators seem to be well understood. Know of any
description (article, blog, etc) of these in a functional programming
setting?

> The only difficulty
> I can foresee is that OCaml only supports recursive value in a quite restrictive
> form. E.g. 
> 
>   let rec s = [<'1; s>]   or   let rec s1 = [<'1; s2>] and s2 = map f s1
> 
> is not directly supported. 

I see that recursion as shown above could be useful: one of the
outputs would simply be an input to another stream generator.

> One can make use of recursive function as
> workaround, but the semantics may not always identical.  However, if you have
> control over your data structure, 

This is the case.

> you can usually define your specific version
> of stream type, then this won't be a problem any more. 
> 
> In some dataflow languages I know, such kind of recursion is often represented
> through a special form -- "delay" which is provided as system primitive. If
> written in plain OCaml, the "delay" primitive won't be combinatorial as you
> want, so you have to require programmers to handle it specially. Fortunately,
> in most cases, a higer-level combinatorial form is usually sufficient, so that
> you can use it to hide the "delay" with sth like "recur".
> 

I (think) I see what you mean. Things seem to be coming together. What
you are saying is that I could use this "delay" so that only when the
value is available would it be "passed back" to the "stream generator"
thereby providing the "feedback" I need. In fact this "delay" is more
general and could be used to define various types of flows. Nice!

Assuming a standard definition of list, do you have any example of how
one would go about implementing this "delay"? I need to gives this some
thought.

> IIRC, OCaml was uses as the basis of some dataflow languages developed in
> french universities. Maybe they can give you more suggestions.
> 
> HTH.

It has.

Thanks.