"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