all 7 comments

[–]Syrak 10 points11 points  (0 children)

This sounds like dataflow programming.

You might also like To Dissect a Mockingbird, a graphical notation for lambda calculus.

[–]HomotoWat 11 points12 points  (0 children)

What you're talking about are string diagrams. Any given monoidial category admits one along the lines of the diagrammatic matrix calculus you linked to. Here's a paper on them. Hask is treated, in practice, like a cartesian category, where the tensor product of linear algebra is replaced with the cartesian product. This fact is the basis for the concat library. There might be potential in interpreting concat programs diagrammatically.

One thing to note is that these diagrams denote point-free programs. They don't allow full representations of the lambda calculus. There are nice diagram calculi for the lambda calculus (my favorite are the bubble diagrams, but there are many alternatives). However, I've never seen one incorporate types in a nice way, and none have a clear connection to string diagrams.

This is something that's been investigated for a long time, but there aren't any clear answers. The most successful approach is probably Scratch and its diagrams, which does suggest a nice representation of types, but it doesn't fit well with everything else.

We have a mish-mash of partial solutions which don't fit well together. I wouldn't be discouraged by this, though. Due to the lack of hard answers, coming up with diagram calculi is more of an art than a science. You might very well be able to come up with an elegant, unified approach.

[–]outlacedev 2 points3 points  (2 children)

Along the same lines, is there a way to view a Haskell program as a computational graph? It's my understanding that a Haskell program is technically just one big composite function so it should be possible to create a visualization graph of the program like OP described

[–]tathougies 8 points9 points  (0 children)

The lambda calculus is directly embeddable in the system of interaction combinators, which is just a graph. So, depending on what you mean by a 'way to view a Haskell program as a computational graph', that sure fits the bill.

Other than that, the spineless tagless representation used by GHC ends up constructing a graph on the heap.

Finally the recent compiling to categories paper shows how to compile Haskell to an arbitrary category, and categories can be viewed as graphs.

[–]vasiliyl 2 points3 points  (0 children)

There is glance.

[–]IronGremlin 0 points1 point  (0 children)

From the hip -

Serializing/tokenizing a representation of a graph sounds like the hard part.

Transforming a graph to a series of functions sounds pretty easy to do in Haskell, but capturing the contents of a drawn area concretely sounds quite difficult.

Depending on how you feel about it, I might investigate some combination of ghcjs and electron, or, depending on your strengths, just electron, with Haskell as a psuedo backend over localhost or file IO.

Parsing JSON in Haskell is ridiculously simple (aeson is your friend), so if you already have the webdev chops to pull off a canvas UI to json interface, putting it all together would be pretty painless. This of course has the added benefit of transferring to a webapp with considerably less sweat and tears, if that's of interest.

But in my experience, Haskell GUI frameworks​ have a tendency to get extremely non-haskellian very, very quickly, which will likely get problematic and painful.

[–]kfound 0 points1 point  (0 children)

Related (but not Haskell): Jane Street's Incremental framework, and http://adapton.org/. Both are concerned with dynamic graph computation, where nodes have the ability to change the graph at runtime.