[racket] Re-inventing dataflow languages
On Oct 12, 2012, at 11:22 AM, Tony Garnock-Jones wrote:
> On 10/11/2012 07:26 PM, John Clements wrote:
>> I can imagine doing something more complicated, but what I really want to ask is this: for those of you with experience in other dataflow languages, how do they solve this?
>
> The systems I've worked with have used a delay node in the graph rather than your previous-value idea. If the delay is nonzero (positive), it can be placed into a feedback cycle. You still have the problem of specifying what value to use for the delay until the first signals make it through to the other end, but it could be a less roundabout way of thinking about the problem?
>
> (define simple-ctr
> (network ()
> [out (delay (add1 out) 1 #:init 0)]))
>
> vs
>
> (define simple-ctr
> (network ()
> [out (add1 (delay out 1 #:init 0))]))
I like this, but I'm going to require the delay to be closer to the named node; in fact, I'm going to skootch it in all the way, where it basically turns into my existing "prev". So, another way of saying this is that the #:init is now attached to the "prev", rather than to the clause. In fact, I think I'm just going to require it. You're probably right that "delay" is a better term than "prev", though.
This means I'm stuck with a three-node solution:
(define simple-ctr
(network ()
[a (delay b 0)]
[b (+ 1 a)]
[out a]))
… but it saves me from doing extensive macro processing to isolate the clause references within an arbitrary definition, because (in my proposed world) the 'delay' must be wrapped immediately around that reference.
I think this will be okay, because most people will just be using these abstractions, rather than defining them….
Many thanks!
John Clements
>
> Regards,
> Tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4800 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20121016/612c9d76/attachment.p7s>