Graphical Programming in Lisp?

Has anyone tried graphical programming in Lisp? I'd be interested to hear about your experiences, thoughts, etc.

I also have some other related questions, such as:

• Would/Could macros have a graphical analog?
• Do you think a graphical programming interface to Lisp or in Lisp is a good idea?
• If you were to make a graphical programming interface, how would you go about implementing it?

Cheers,
Jonathan

Can you elaborate on what mean by a macro analog?

What sort of interface do you want? There are plenty of graphical packages: cl-sdl, cl-cairo, cl-opengl, depending on your needs. If you're talking about a language which expresses graphical concepts at a higher level, I believe thats best left up to the user as I really don't see a general language that's suitable for a broad audience.

I believe he's actually talking about a programming language composed of graphical objects rather than text. My first move would probably be to have the programmer type snippets of code wherever they wished, then draw lines from them to where arguments are expected by functions in other code snippets. Hopefully this would make it easier to deal with situations where you want to reuse a computation. It's kind of a natural step up from trees of code to graphs of code. With this in place, it might also become easier to represent data flow for user interfaces or audio processing. Visual macros, whatever form those might take, would probably be used to transform graphs of signal filters or on-screen objects into Lisp code.

Paul Donnelly wrote:I believe he's actually talking about a programming language composed of graphical objects rather than text.

Spot on. I'll learn to communicate with practice .

djbuzzkill wrote:What sort of interface do you want? There are plenty of graphical packages: cl-sdl, cl-cairo, cl-opengl, depending on your needs.

I'd probably use one of those to implement a graphical programming interface to Lisp.

Paul Donnelly wrote:My first move would probably be to have the programmer type snippets of code wherever they wished, then draw lines from them to where arguments are expected by functions in other code snippets. Hopefully this would make it easier to deal with situations where you want to reuse a computation. It's kind of a natural step up from trees of code to graphs of code. With this in place, it might also become easier to represent data flow for user interfaces or audio processing.

That would be a nice starting point. I could imagine, get the REPL into a graphical interface, and then change the way things are displayed. I didn't want to taint others thoughts on this too much, but I was imagining that you could change the (display) colour (why not font, size, bold, etc?) of your function (making different things stand out). Probably even the shape of the function. Yeah, and then drag other expressions into argument positions.

Paul Donnelly wrote:Visual macros, whatever form those might take, would probably be used to transform graphs of signal filters or on-screen objects into Lisp code.

I was thinking of it like this:

• plain lisp macros do this: code code
• Graphical programming does this: graphics code
• Graphical macros do this: graphics graphics

P.S. Those arrows don't blend in very well, do they .

Kohath wrote: I was thinking of it like this:

• plain lisp macros do this: code code
• Graphical programming does this: graphics code
• Graphical macros do this: graphics graphics

P.S. Those arrows don't blend in very well, do they .

I'm not sure what the need for graphics macros would be.

Macros do map code to code, but there is an important difference between them, and the code generation you might see elsewhere(emacs snippets or templates) used to generate function stubs.

With macros you do not edit the code after generation. Once you have written and debugged your macro that's it, it is just a black box used in compilation, and you never touch its output.

Because of this, I don't see the point in having graphic macros and normal macros. They both fulfill the same role; you could of course use graphical programing to write a normal macro, or display a macro expanded program in a graphical form but beyond that I don't see a need for a new type of macro.

implausibleusername wrote:Because of this, I don't see the point in having graphic macros and normal macros. They both fulfill the same role; you could of course use graphical programing to write a normal macro, or display a macro expanded program in a graphical form but beyond that I don't see a need for a new type of macro.

I think you're right - the graphical part is presenting the macro definition. I just realised that the code is there whether it's textual or graphical...

I've been thinking a lot about a graphical program editor for Lisp, for which it would be especially well suited because of its strict tree structure.

I don't know if you've seen this http://en.wikipedia.org/wiki/Visual_pro ... g_language or more specifically this http://en.wikipedia.org/wiki/OpenMusic but it could well be a good starting point.

If you're thinking of creating a graphical editor do keep us posted.

I'm not sure what the need for graphics macros would be.
...
With macros you do not edit the code after generation. Once you have written and debugged your macro that's it, it is just a black box used in compilation, and you never touch its output.

Hmm, but the question becomes how do you represent it after it is written and debugged. It isn't a matter of defining a new "graphical macro", but rather how do you represent what a macro does in a graphical way. A Lisp macro changes the very meaning of the syntax. In our graphical analogy, it seems that a macro should change the graphical syntax of the language.

If this visual lisp is coded by drawing connections between boxes like other graphical programming languages I am familiar with (e.g LabView, OpenDX, etc.) then a macro wrapping a section of the program should in general delete and create new connections and boxes. And that is the most mundane description of what can happen. For absolute versatility, it seems that within the bounds of a macro the very method of input should be allowed to change. Macros give us options in how we represent the code we want to input. A macro in a graphical Lisp should do the same, but without the limitations of characters.

For instance, maybe I define a macro that displays a canvas for me to draw on. This allows me to sketch a plot of a function I want to approximate. The macro could then take my input and expand into a block of code that represents a polynomial fit to the curve on the canvas. This seems quite similar to the way something like CL-YACC allows me to write production rules directly into the REPL when I wrap it in a DEFINE-GRAMMAR.

This is a fun thing to thing about because it seems doable, though it is in no way clear how to do it well or how far you could take it.

Anyway, just my opinion,
Zach S

jsmcgd: Thanks for the links. I haven't looked at the visual programming language page for a while, but have read it. That would have been a better title for this topic I think .

smithzv: About graphical macros. There does seem to be something there to explore - i.e. how does the program respond to mouse clicks, drags, etc., but also making connections and structures of its own. What I would really like to know is: In 2D, is the text based representation (lisp syntax) of code still the easiest way to do macros, or is there an approach that uses 2D and makes macros even easier? Hey, it might even get to the point that there are different modes in different 'areas', just like Emacs' modes and buffers .

Also, I'd like to have a facility to easily (automatically?) analyse code, do macroexpansions, time functions, do tests, etc.....

There have been high-quality Lisp programs that do great graphics by calling out to the OpenGL library. InspireData does this and it looks very nice.

dlweinreb wrote:There have been high-quality Lisp programs that do great graphics by calling out to the OpenGL library. InspireData does this and it looks very nice.

Sorry dlweinreb, by "Graphical Programming" I actually meant "Visual Programming" (http://en.wikipedia.org/wiki/Visual_programming - thanks jsmcgd). Sorry for the confusion.