[Haskell-cafe] extending the notion of notation (was: extending Do notation)

[Albert Y. C. Lai]

On 14-05-20 08:58 AM, silvio wrote:
> Only because we can't just execute an IO action and fill in the result.
> And this list doesn't even include examples where the programmer had to
> resort to making a pointless temp variable just to avoid using too many
> complicated functions.

I agree that requiring extra variable names to express data propagation 
is a problem. I disagree that any notation that goes like

     third_effect {first_effect} {second_effect}

is a solution. I have written it to highlight the problem: the order of 
the effects is neither entirely left-to-right nor entirely 
right-to-left, but rather a haphazard "start somewhere in the middle, go 
right for a while, now suddenly jump back to the left". This is also my 
second biggest gripe with Lisp, Scheme, SML, Caml, every impure 
functional language.

One thing the do-notation gets right is that I/O effect order is the 
simple top-to-bottom.

The solution is to liberate programming from the plain text file.

Draw a dataflow-like diagram. Arrange effect boxes in one order to 
indicate effect order. Draw lines or curves between them to indicate 
data propagation and/or parameter passing.

Can programming be liberated from the plain text file?