[Haskell-cafe] Re: Graphical representation of Haskell code

[Mihai Maruseac]

Hmm, I may take hints from this conversation to improve the debugger.
My program will draw only the diagrams needed for debugging, it is not
about the programmer needing to draw boxes and wires but about him
understanding his own code :)

On Thu, Mar 25, 2010 at 4:37 AM, Maciej Piechotka <uzytkownik2 at gmail.com> wrote:
> On Wed, 2010-03-24 at 21:33 -0400, Ronald Guida wrote:
>> Those are some very interesting visual languages, Miguel!
>>
>> I remember drawing some diagrams when I was teaching myself Haskell,
>> but I never actually tried to create a formal visual language.  Since
>> my background is in hardware engineering, I would naturally gravitate
>> toward schematic diagrams.  I am also familiar with the graphical
>> programming language of LabView.
>>
>> After reading Miguel's exposition, I thought about how I might draw a
>> picture of map1.
>>
>> map1 :: (a -> b) -> [a] -> [b]
>> map1 f [] = []
>> map1 f (x:xs) = (f x) : map1 f xs
>>
>> map1.png
>> (Image created with Inkscape)
>>
>> Here is what I'm thinking:
>> * Green boxes represent inputs and outputs.
>> * Inputs are always on the left, outputs are always on the right.
>> * Inputs appear in top-to-bottom order.
>> * Data always flows left to right.
>> * Arrows represent data flow.
>> * A named white rectangle represents application of the named
>> function.
>> * A gray rectangle represents a function that arrives through data
>> flow.
>> * A filled-in arrowhead means the data "in" the arrow is to be
>> "unpacked" and used as a function.
>> * A named light-blue rectangle (such as on the left, with a colon in
>> it) represents a pattern match operation.
>>
>> In thinking about this, I can sense that there are MANY issues with
>> using a visual language to represent Haskell.  Some issues I can think
>> of:
>> * How to represent pattern matching?
>> * How to represent partial application?
>> * How to represent data types or class constraints in the diagram?
>> * How to represent a list comprehension or a do statement? (These
>> might require special visual syntax)
>> * Will the data flow always take the form of a directed acyclic graph,
>> so that data never has to flow right-to-left?  (Perhaps there's a way
>> to "tie the knot" and get a cycle in the data flow graph.)
>
> myfix f = let x = f x in x
>
>
>
> f -------\
>          |
>          v
>      /->X-X--+-------->
>      |       |
>      \---<---/
>
> Unless we rewrite it into:
>
> myfix' f = f (myfix' f)
>
>
> f ----+-------------------\
>      |                   |
>      |                   v
>      \->X myfix' X----->X-X---->
>
>> * Whether to create special symbols for certain commonly used
>> functions? (In digital circuit schematics, AND, OR, and NOT gates have
>> special symbols, but most compound circuits are represented with
>> labeled rectangles.)
>>
>> Also, if I want to automatically generate an image from a Haskell
>> function, then my image generator needs to automatically place and
>> route all those boxes.
>>
>> I'll have to give more thought to the other versions of map, and maybe
>> make some more diagrams.
>>
>> -- Ron
>
> Regards
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>