[<<][meta][>>][..]
Mon Apr 26 20:06:11 EDT 2010

Dataflow notation

For low-level code (asm, C), always erite operations as (OP ins outs)
instead of the normal nested function notation.  This makes fanout
easier, and also works in C for composite objects that can't be
returned by value.  Let's call this ``dataflow notation''.

Note that in Haskell it might be simpler to keep using function
notation to blend better with the rest of the language, and return
multiple output values as tuples.

How is this relevant?  I started writing the `printC' formatter to use
normal C function composition, but this already breaks down for
iteration of input/output blocks where explicit naming of the output
buffer is required.

Note that this makes function composition awkward in C.  Luckily it is
mostly useful at a level where one would inline anyway when the
functions are small, and when they are large or block-based processing
is used, passing around pointers isn't so inefficient.

Note that dataflow variables[1] are a high-level idea.  I'm talking
mostly about the notiation, where a sequence of data processing
releations can be interpreted as a sequential program, i.e. they are
already ordered according to some dependency chain.

[1] http://en.wikipedia.org/wiki/Oz_(programming_language)#Dataflow_variables_and_declarative_concurrency



[Reply][About]
[<<][meta][>>][..]