Visual Haskell

[Jason J. Libsch]

The reason that this paper so peaked my interest is that i have been
working on a system that is tremendously similar to the one described in
this paper- it's as if Dr. Reekie Van Eck phreaked my head or notebooks
(unfortunatly, my designs have not progressed past pen and paper.) from
the other side of the world.  My take on the project is that such a
language would be the ideal langauge for begining programmers.

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.

3) It seems to me that such an environment would strongly encourage
collaboration.  Having two mouse pointers dragging compenents around is
much less foreign of an asthetic than text just randomly poping up here
and there, or some such text based equivalent.  The analogy i have been
working with is: two mouse pointers on the same screen can work together
like two hands- one can hold a wrench on the bolt while the other turns
the screw, while two clarets in action is like listening to two people
talk at once.

4) A visual environment allows for the seemless integration of advanced
code development tools as CVS (isn't CVS just a fancy C^z, C^ [Shift] z
?) Help or Code Documentation, etc.

5) Ability to truly design from the top down- all the way from the Gui.
An integrated GUI construction tool would be right at home in a visual
language.

6) Much more elaborate and illuminating comment system.  Allowing for
dashed outlines and arrows pointing at code to be integrated into a
comment, to be shown only on the comment's mouse over event.  Can drag
components (fn block) into comment, which can be clicked on to bring up
that comment in hyper text fassion, etc.


Modeling the visual language after a function langauge makes tons of
sence.  Once you take this step, the visual systax follows nicely, and, i
think, looks and feels very clean.

My appologies for such the gushing tennor of this letter.  I know much of
the praise i sing for a Visual Haskell is generic visual programming
propoganda, and that visual langauges for software development haven't
taken off.  I think that the coupeling of a high level, robust,
funcitonal language with the visual paradime solves many visual
langauge problems, and, furthermore, presents new benfits all together.

I am eager to hear the opinions of this list.

my best,
 
 /jason libsch


On Mon, 2 Apr 2001, Toby Watson wrote:

> Hi, Good find!
> 
> NB: I just skimmed the paper so far, but it is a long-term area of interest
> for me...
> 
> 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.
> 
> I am encouraged by the FP notion of the creation of new glue, as if you
> could create new control structures and domain specific languages. Once this
> concept has been incorporated, i.e. the user-development of new visual
> syntax as first class then I think we will see some progress in VPLs.
> Unfortunately this is a big task, to my mind it involves revising our
> current method of building interactive software (the event loop) to make it
> more modular and reasonable to expect users to contribute new modules or
> systems thereof. The FP community have delivered a number of promising
> architectures (Haggis, Fudgets, Exene) in this area as has Rob Pike
> (newsqueak, 8 and a half, mux?).
> 
> My interest in the area was peaked by a presentation on VPL. VPL was
> exceptionally usable dataflow image-processing oriented system. It had
> functions as first class objects and apply.
> http://www.camazotz.com/vplpaper.html
> 
> 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 think you can see where I'm going with this - the user has a notion of
> 'things connected together', but without being too concerned about the
> underlying system. I imagine a 'live' type system flagging up mismatches. I
> think there is analagous situation when beginners try to plumb monads
> together with pure code. The idea would be to get visual syntax to help out.
> Consider the conversation, "Oh, you can connect red stripey objects together
> but when you want to join up a blue object you need a red/blue adaptor".
> 
> cheers,
> Toby
> 
> ----- Original Message -----
> From: "Jason J. Libsch" <jlibsch@mail.wesleyan.edu>
> To: <haskell-cafe@haskell.org>
> Sent: Monday, April 02, 2001 5:57 PM
> Subject: Visual Haskell
> 
> 
> > 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.
> >
> > http://ptolemy.eecs.berkeley.edu/~johnr/papers/visual.html
> >
> >
> >  /jason
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> 
>