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

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