Visual Haskell /long comment/

Tue, 03 Apr 2001 13:31:46 +0100

"Jason J. Libsch" wrote:
> 
> I recently ran across a paper, Visual Haskell- a First Attempt, and was
> tremendously impressed.  Has anybody here played with this language or
> read the paper?  I would be interested to hear other's opinion on such a
> language.

I didn't play, I don't know what is the real status of the
implementation,
but I read the paper of Hideki John Reekie quite a time ago.
And his thesis.

http://ptolemy.eecs.berkeley.edu/~johnr/papers/thesis.html

All this is extremely interesting. Is it promising?

It depends on whether the visual, dataflow approach to the interfacing
of practically usable languages is considered promising. The area seems
alive.

http://cui.unige.ch/eao/www/Visual/
http://cuisung.unige.ch/Visual/Freeman/VL.html

Dataflow-oriented packages are not so rare either. Simulink, Scicos, IBM
OPen DX, Khoros, SciRUN, WiT. The connexion tool within MCAD.
Visio and all this business well known by some people reading this list.

Of course:  LabView!
(And there was even a music generator ("tracker") called Buzz which
had such an interface, quite well adapted to all kind of DSP algorithms,
but I cannot find it any more.)

//Not too many attachments to the functional world. E.g. Cantata, the
dataflow interface to Khoros library is an integrator of imperative
modules.//

Using lazy streams as the basic protocol for implementing "heavy run"
machines is nice, but - probably - not so easy to implement efficiently,
and the dataflow approach is particularly interesting in the domain of
scientific data processing, where brutal power cannot be disregarded.

What is the opinion of people working on Hawk? Lava?

There was - some time ago - a short discussion on those issues (if 
I don't confuse names the first posting was by Yoann Padioleau).

There are several problems with functional visual programming. It is
not so easy to design a recursive function, to "plug-in" higher-order
functions, to exploit currying, polymorphism, etc. Simple graphs are
simple and nice.

Simple textual definitions are simple as well...

Complicated graphs are simply horrible!

I suspect that HJR did not progress too much in his approach, and 
I won't blame him (I would love being able to work along this 
direction, but I feel frightened). There are also other directions,
perhaps distantly related, but worth analysing.
Visual Prolog.

The Object Flow paradigm.

etc...

Toby Watson wrote:

> I find most of these visual systems awkward to use in practice. 
> Quite often this is because they have very poor interface designs 
> (they are like old modal CAD systems). This is troublesome, leading 
> many - I believe - to suggest that the idea is not plausible.
> 
> I think that a usable visual programming language is possible but 
> it would have to be a good graphical tool rather than just a 
> translation of a textual language.

NOT just a graphical tool. The problem - as I see it, having played
quite a lot with Khoros, Simulink, Labview... is deeper, is conceptual.
In Labview you define a for-loop, an iterative block, by embedding
the relevant instructions into a "cage" which defines local iteration
variables. Toby might say that, exactly, this is an awkward textual
code transposition - only that there is no textual code. The iteration
*concept* has been squeezed into an interface which is not adapted.

In Simulink this is better.
You can produce a loop which is a stream iterator, and even - which
you can't do trivially at all - you can produce a "tight loop", where
there is an immediate (*not delayed*) feedback between the input
and the output.
This requires a *constraint-solving* procedure!

> On related note the types of a function adding two integers 
> together, two lists of integers together and dataflow or pipe adding 
> two streams of integers together would seem to be similar. Does 
> anyone know of some formal work on this, what are the terms I would 
> use to investigate?

I am not acquainted with formal works, especially in a typed framework,
but related stuff is described already in Abelson & Sussman^2. 

Types are wonderful. But Jason exaggerates:

> 1) As Toby stated, the Strong Typeing of Haskell allows for a 
> 'syntaxless' development environment.  Only inputs and outputs that 
> type correctly can connect.  This means that all code that can be
> written will compile!
> 
> 2) Easy to navigate through code.  If a fn is foreign to the user, she
> need only click on it to bring up its the underlying code.

1. The refusal to connect inappropriate nodes means simply that the
   visual editor has incorporated the type checker. Mind you: you are
   not "just writing". While connecting you perform a lot of semantic
   analysis.
   This can be done textually as well for primitive languages.
   But for polymorphic nodes, for higher-order functions, for
   "curried nodes" the life might be much harder.

2. Many-level textual editors, or visual interfaces to Basic exist.
   You click, and the block opens.
   This is the way the interfaces to Khoros, Dx, Simulink, Labview etc.
   operate.
   I fell in love with that.
   I am sane again now, after crying in despair seeing 18 simultaneously
   open windows, and not knowing really how to reuse the code, how
   to reassemble identical parts in order to share them.
   Theoretically it is not complicated. Practically it requires a LOT
   of experience and patience.

   I agree with Jan Skibinski that it is *much* better to
   adapt this kind of interfacing to concrete, applicative domains
   rather than making a universal paradigmatic world from it.

End users may love it. Students are fascinated by it. (But Matthias
Felleisen - from our conversation - seems to be a bit reluctant:
from the pedagogical perspective it is too easy to play with graphics
and to forget about the structure of the program, about the sense
of it. Nice for simple, and only for simple tasks. [We talked about
Scheme, of course]).

Personally I don't know. But I am still fascinated. Lazy streams are
not the only underlying model, one may - obviously - exploit the
continuations. Or use the event/token propagation along the links. But
this drives as far from Haskell.

More links, just to prove you that I've been thinking about visual
side of FP for some time:

http://www.cs.ucl.ac.uk/staff/L.Braine/researchdocs.html
http://www.cs.orst.edu/~burnett/vpl.html

And, of course, something about Lucid
(not to confound with Lucent)
http://lucy.uvic.ca/pm/contents.html

Jerzy Karczmarczuk
Caen, France