5 ms·

Do you think of stream programming as a kind of dataflow programming? If not, what's the difference? I suppose "dataflow" is an overloaded term, and the fact t

by gruseom 13y ago

Do you think of stream programming as a kind of dataflow programming? If not, what's the difference? I suppose "dataflow" is an overloaded term, and the fact that its various meanings have quite a bit in common doesn't help.

scott_s 13y ago
Definitely, yes. In section 2 of this paper, I tried to explain how our language is related to what are typically called "synchronous dataflow" languages, or just SDF languages: http://www.scott-a-s.com/files/pact2012.pdf http://www.scott-a-s.com/files/pact2012.pdf Slide 11 of this talk makes the same point, but with less words: http://www.scott-a-s.com/files/debs2013_tutorial_slides.pdf http://www.scott-a-s.com/files/debs2013_tutorial_slides.pdf
seanmcdirmid 13y ago
Data flow when used as a converse of control flow is quite well defined. Are you thinking in terms of how data flows across the system or in terms of control? Stream programming usually uses data flow at the top level and control flow in the atomic components connected together (we can have compound components that involve more data flow). Once you add control lines to your system, however, you are basically re-encoding explicit control flow as data flow.
- gruseom 13y ago
  I might have been unclear; what I meant was that the different programming languages or models that people call "dataflow programming" (spreadsheets, Lucid, Oz, FBP, etc.) have a lot of differences between them; and on top of those there is dataflow analysis in compilers, dataflow hardware architectures, and so on.
  - seanmcdirmid 13y ago
    Data-flow is a broad term that doesn't mean one specific thing, but it is usually used correctly in what it means; e.g. data-flow analysis contrasts nicely with control-flow analysis. I don't find it confusing. I believe FBP primarily deals with data flow, not control flow, but the "flow" in FBP seems to be left intentionally ambiguous.

by gruseom 13y ago

scott_s 13y ago

Definitely, yes. In section 2 of this paper, I tried to explain how our language is related to what are typically called "synchronous dataflow" languages, or just SDF languages: http://www.scott-a-s.com/files/pact2012.pdf http://www.scott-a-s.com/files/pact2012.pdf Slide 11 of this talk makes the same point, but with less words: http://www.scott-a-s.com/files/debs2013_tutorial_slides.pdf http://www.scott-a-s.com/files/debs2013_tutorial_slides.pdf

seanmcdirmid 13y ago

Data flow when used as a converse of control flow is quite well defined. Are you thinking in terms of how data flows across the system or in terms of control? Stream programming usually uses data flow at the top level and control flow in the atomic components connected together (we can have compound components that involve more data flow). Once you add control lines to your system, however, you are basically re-encoding explicit control flow as data flow.

gruseom 13y ago
I might have been unclear; what I meant was that the different programming languages or models that people call "dataflow programming" (spreadsheets, Lucid, Oz, FBP, etc.) have a lot of differences between them; and on top of those there is dataflow analysis in compilers, dataflow hardware architectures, and so on.
- seanmcdirmid 13y ago
  Data-flow is a broad term that doesn't mean one specific thing, but it is usually used correctly in what it means; e.g. data-flow analysis contrasts nicely with control-flow analysis. I don't find it confusing. I believe FBP primarily deals with data flow, not control flow, but the "flow" in FBP seems to be left intentionally ambiguous.