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" To: 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

"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

On Tue, 3 Apr 2001, Jerzy Karczmarczuk wrote:

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

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?

I am not working on Hawk or Lava, but Reekie's work has been a key inspiration for our research, which is the development of the ForSyDe (Formal System Design) methodology, developed for the design of systems on a chip. The architecture for such systems is a single chip integrating many different components, such as microprocessor and DSP cores, memories and custom hardware. We use Haskell as a modelling language in a similar way as Reekie described in chapters 5 and 6 of his Ph.D. thesis. Higher-order functions like scanlS and mapS, called skeletons in our methodology, are used as process constructors implementing a synchronous computational model. We extend Reekies approach targeting applications that control both control and data flow parts. In addition, we also cover the synthesis process, i.e. the transformation from an ideal system model written in Haskell, into C-code for the software parts and VHDL-code for the hardware parts. During the synthesis process we use the property, that each skeleton has a hardware and software interpretation, e.g. a process 'scanlS f m' has a finite state machine as its interpretation and is translated into the corresponding VHDL (for hardware) structure, where f describes the next state decoder and m determines the memory elements. Thus, we do not compile the Haskell code with a traditional compiler, but interpret the structures (skeletons) in the system model in order to get an effective hardware/software implementation of the system model. Back to your question, we believe that such an approach - raises the abstraction level compared to traditional methods starting from VHDL/C++ - allows for formal design transformation - leads to an efficient implementation using the interpretation of higher-order functions into hardware and software - allows the incorporation of formal methods because of Haskells formal semantics If you want to more about our approach please the following WWW-page containing a number of publications about the ForSyDe methodology: http://www.ele.kth.se/~ingo/ Ingo Sander