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

[John Lato]

On May 20, 2014 12:00 PM, "Albert Y. C. Lai" <trebla at vex.net> wrote:
>
> 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?

Having done a number of projects in Max/MSP and PD, I have to say this is a
horribly inefficient programming interface. It seems attractive in small
doses, but it doesn't scale well.  Additionally it's not at all clear how
to design an editor that allows for decent automation, which can slow down
many workflows.

If you're interested in this interface, I'd suggest that you try PD for a
while.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140520/6c40fae5/attachment.html>