From: Hugo Ferreira <hmf@inescporto.pt>
To: Zheng Li <li@pps.jussieu.fr>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Re: Functional design for a basic simulation pipe.
Date: Mon, 22 Oct 2007 08:48:03 +0100 [thread overview]
Message-ID: <471C55B3.2080603@inescporto.pt> (raw)
In-Reply-To: <87abqkugi5.fsf@pps.jussieu.fr>
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 <hmf@inescporto.pt> 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
prev parent reply other threads:[~2007-10-22 7:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-10 7:39 Hugo Ferreira
2007-10-10 8:34 ` [Caml-list] " skaller
2007-10-10 10:08 ` Hugo Ferreira
2007-10-10 10:31 ` Vincent Aravantinos
2007-10-10 10:56 ` Hugo Ferreira
2007-10-11 12:01 ` Pietro Abate
2007-10-11 13:52 ` Hugo Ferreira
2007-10-11 14:20 ` Pietro Abate
2007-10-10 15:00 ` skaller
2007-10-10 15:56 ` skaller
2007-10-11 6:57 ` Hugo Ferreira
2007-10-11 8:09 ` skaller
2007-10-11 9:54 ` Hugo Ferreira
2007-10-11 13:47 ` skaller
2007-10-11 11:17 ` Zheng Li
2007-10-11 13:48 ` [Caml-list] " Hugo Ferreira
2007-10-15 23:04 ` Zheng Li
2007-10-22 7:48 ` Hugo Ferreira [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=471C55B3.2080603@inescporto.pt \
--to=hmf@inescporto.pt \
--cc=caml-list@inria.fr \
--cc=li@pps.jussieu.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox