Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Functional design for a basic simulation pipe.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Hugo Ferreira <hmf@i...>
Subject: Re: [Caml-list] Re: Functional design for a basic simulation pipe.
Hi Zheng,

Apologies for not answering earlier (Took a fee days off).
I am going to look at your code and see how that works.

Thanks once again.
Hugo F.

Zheng Li wrote:
> Hi,
> Hugo Ferreira <> writes:
>> Hmmm... these combinators seem to be well understood. Know of any
>> description (article, blog, etc) of these in a functional programming
>> setting?
> These combinators pervasively exist in functional languages and other
> declarative style languages. There's no authoritative definition though,
> they vary from language to language, with some slight differences.
>> I see that recursion as shown above could be useful: one of the
>> outputs would simply be an input to another stream generator.
> Yes. This _could_ be directly simulated with OCaml's recursive values if not
> for the restriction I mentioned before. 
>> 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!
> The "delay" like facilities are usually provided as language primitives in
> dataflow languages, not in the library space. I can't figure out how to
> simulate it through plain OCaml and still keeping a combinatorial interface at
> the same time. I can image some workarounds to relax the restriction: recursive
> function, reference, variants, but all of them come with some syntactic burdens
> and can hardly used as combinators directly. On the other hand, there is still
> some possibility of making camlp4 extension to do that. I just haven't got
> chance to do any investigation on that.
> Btw, I just cleaned up some old code and will release it right now. I'm not
> sure whether it can help directly in your case, but I hope so.
> Regards