From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 638E5BC6B for ; Thu, 11 Oct 2007 15:52:53 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANbHDUfAXQInh2dsb2JhbACOSgEBAQgKKQ X-IronPort-AV: E=Sophos;i="4.21,260,1188770400"; d="scan'208";a="2872005" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 11 Oct 2007 15:52:53 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l9BDqirO007450 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 11 Oct 2007 15:52:52 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACLHDUfAI/YBnWdsb2JhbACOSgEBAQELDw X-IronPort-AV: E=Sophos;i="4.21,260,1188770400"; d="scan'208";a="4361062" Received: from unknown (HELO animal.inescn.pt) ([192.35.246.1]) by mail3-smtp-sop.national.inria.fr with ESMTP; 11 Oct 2007 15:51:30 +0200 Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.8/8.13.6/9) with ESMTP id l9BDpPKC010486; Thu, 11 Oct 2007 14:51:25 +0100 (WEST) X-Virus-Scanned: amavisd-new at inescporto.pt Received: from animal.inescn.pt ([127.0.0.1]) by localhost (animal.inescn.pt [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rNJ2svK3v8DT; Thu, 11 Oct 2007 14:51:02 +0100 (WEST) Received: from [194.117.30.94] (morfina.inescn.pt [194.117.30.94]) by animal.inescn.pt (8.13.8/8.13.8/26) with ESMTP id l9BDmgYW010029; Thu, 11 Oct 2007 14:48:43 +0100 (WEST) Message-ID: <470E29B6.4060502@inescporto.pt> Date: Thu, 11 Oct 2007 14:48:38 +0100 From: Hugo Ferreira User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: Zheng Li Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: Functional design for a basic simulation pipe. References: <470C8199.4080708@inescporto.pt> <87fy0hvr15.fsf@pps.jussieu.fr> In-Reply-To: <87fy0hvr15.fsf@pps.jussieu.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 470E2AAC.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 combinators:01 dup:01 hmmm:01 combinators:01 recursive:01 restrictive:01 recursion:01 recursive:01 semantics:01 recursion:01 iirc:01 blog:98 foresee:98 Hello, Zheng Li wrote: > Hi, > > Hugo Ferreira 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.