A 3D Text Editor?

[Jeremy Dunn]

I was thinking about the nature of LISP syntax and its nesting parentheses that programmers from other languages seem to go into fits over. What if we could get rid of the parentheses? I gave some considerable thought to this problem and I realized that LISP lends itself to a novel solution. What if our code writing text editor had a third axis that we could move the cursor up and down in? Imagine your normal text editor but with the main XY plane displayed in an isometric view so that it was like you were looking down on it at an angle. Imagine further that you could hit SHIFT-DOWN ARROW or SHIFT-UP ARROW to move the cursor up or down a level from the main text plane. Now imagine that every time that you type the name of a function you then move the cursor DOWN into the plane and type the rest of the arguments going up or down as needed to indicate the nesting. Comments could be written on the +1 level (above the home plane). This way we could eliminate the display of the parentheses entirely by using visual depth as a substitute. I am currently starting to write such an interface but I am doing so in AutoCAD to write AutoLISP code in a DWG file. The DWG file is read by a translator and the drawing entities in it are converted to AutoLISP code. The 3D display environment already exists so I don't have to write it. I intend to display spaces as light grey filled rectangles to add visual clues to help define the current plane that the text is on. I also intend to use this interface to write NEWLISP code as well but it would only benefit NEWLISP users that have copy of AutoCAD on their computer. A good project for you adept GUI writers out there?



What do the rest of you think of this concept? Profound? Nutty?



Short of that what can we do in boring old 2D land? One idea I had was to make LISP case sensitive so that the function names can be written in a format that makes them unique. For instance, a function name would be upper-case with at least one letter at the beginning. This way the interpreter could identify a function name and automatically assume a left parenthesis in front of it. You would still have to type the right parentheses but it would get rid of 50% of them.



My final idea was to allow the use of square brackets [] as well as parentheses. A square bracket would be equivalent to two parentheses. So an expression like (f1 (f2 (f3 (f4 x)))) could be written as

(f1 (f2 (f3 (f4 x]] . At least we could shorten some of those more massive collections of parentheses that sometimes occur at the end of a long complicated expression.



Any other ideas out there? All comments welcome.

[HPW]

Hello Jeremy,



Since I am also a autolisp and newLISP programmer, I can not see the benefit to use autocad as an programming editor. Such beast is used for that things it is designed for. I do my programming in autolisp and newLISP in an powerfull external editor (UltraEdit) where I have no problems with paranthesis and structure. This reminds me also about our discussion about coding style:



http://www.alh.net/newlisp/phpbb/viewtopic.php?t=1860&highlight=style">http://www.alh.net/newlisp/phpbb/viewto ... ight=style">http://www.alh.net/newlisp/phpbb/viewtopic.php?t=1860&highlight=style

At least we could shorten some of those more massive collections of parentheses that sometimes occur at the end of a long complicated expression.

Since my used style does not collect them in one place at the end, I have no problem with them. My closing paranthesis is on the same idention-level as the opening on and also on it own line. So the paranthesis matching function shows me always the structure. (Ultraedit has also an automatching-function which shortly highlights the end paranthesis when you only move the carret over the opening one. On keypress the whole block is highlighted)



So for my taste I would not change anything regards the lisp-paranthesis.

It is a straightforward concept and easy to parse. The paranthesis are keeping the structure visible and intact. I personaly use also pairs of {} and [] to implement additional structure. I place them in comment lines where I need structure beyound the lisp-paranthesis and the matching function also works with pairs of them. So I can kepp bigger blocks together and jump at the end with one key-stroke.



Together with a function scanner my editor keeps the overview this way, even in production code with thousands of lines.

Such huge code is also packed on final released to optimized net-load/traffic, where all code is a megabyte one-liner. But still the paranthesesis are in there to keep the structure of the lisp-stream.



New user may need some time to see the beauty in paranthesis!



Just my 2 cents (euro)

;-)

[cormullion]

More Euros for you...



I love ideas like this - they're so crazy, you think they'll either be terrible or brilliant, and you wouldn't know till you tried it...



How about colour (color)? Chuck Mr Forth Moore uses it: http://www.colorforth.com/cf.html">//http://www.colorforth.com/cf.html.



Like you I once had the idea of using upper-case letters to 'start sentences', and full-stops to end them. It looks like this:

Code Select Expand

Define List-most-fetched-posts.
  Let Results '()..
    Set 'results Sql3:sql {select post_id, post_title, post_fetch_count from posts order by post_fetch_count desc limit 10}..
    Unless List? results. Miserable-failure..
    Println {<h3>Most viewed posts</h3>}.
    Dolist Row results.
      Println {<p>} {<a>} Row 1) {</a> } Row 2) {)</p>}....


That ellipsis at the end is the three closing parentheses.



However, the big problem now is that I'd need an editor that matched capital letters with full-stops. And I'd get as confused with upper-case characters in literal strings as I used to do with parentheses in strings.  Case-changes are already useful so it's a shame to lose them.



Proper code-folding would be another great idea. Where is the editor that has a slider that progressively shows and hides nested details? And where is the editor that formats newLISP automatically to your taste so that you're free to work on the ideas and the problem domain, not the syntax and tabs and spaces...?



Anyway, I think it's great to try new ideas.



I'm still hoping that someone will write a formatting script for newLISP... :-)

[Jeff]

Parenthesis are one of lisps most elegant points.  Using prefix notation with a strict list structure, you actually construct the program's stack.  Rather than parsing 1 + 1 and requiring the parser to turn into something like PLUS, 1, 1 for the evaluating code, lisp has you explain your code in terms the language's internals can already understand.



Many, many languages have attempted to make code more readable and expressive by applying linguistic theory.  I think that Perl is a prime example of how human languages are not adept at expressing logic.



Parenthesis, however, are.  While it might be an entertaining exercise to create a 3D model of a lisp program, I don't think it would help in authoring one.



Although, for years, Smalltalk has used graphic representations to create software (albeit 2D), and it seems to work well for it.  I never got the hang of that, though.

[Ryon]

I think a 3-D viewer would be a great idea! And it needen't replace those Lots of Irritating and Silly Parentheses that the abstract thinkers seem to appreciate; it would just be an alternate, pictorial vision of the same thing. Think chemical formula vs. molecular model.



One of the biggest hurdles to my understanding of the language is in grokking the different parts of speech--there just aren't any, not visually. In lisp, nouns, verbs, definitions, entire programs appear as one word, and with lambda we don't even have that! Just a position, somewhere in the listing.



Yes. Far more than any other computer language, lisp would benefit from a viewer.

[jrh]

Rather than parsing 1 + 1 and requiring the parser to turn into something like PLUS, 1, 1 for the evaluating code

Shouldn't that be 1 1 PLUS ?

[Jeff]

A parser will identify the different tokens in a program.  The end result is typically a lexical tree representing the code.  Something like

Code Select Expand

$x = 1 + 1;

in PHP would be broken down into something like, SYMBOL, LASSIGN, INT, PLUS, INT, with symbol having a value of x, lassign having no value but causing the interpreter to assign the rhs value to the symbol, INT with value 1, PLUS with no value (but again meaning something to the interpreter), and INT 1 again.



These values might be represented in a list-like structure:



(LASSIGN (SYMBOL X) (PLUS (INT 1) (INT 1)))



Which looks very similar to:



(setf x (+ 1 1))



In lisp, you are representing your program in much the same way as the parser does for the code that evaluates the program.

[jrh]

Meh...  must be why I don't like compilers.  Better to push 1 on the stack then another, etc...

[m i c h a e l]

Hi Jeremy!



It's common to imagine the possibilities of—and attendant changes to—a language one is using. Especially among those familiar with other languages. I'm not immune, either, as I'm hoping to make newLISP more OOey through an add-on. The question we should be asking ourselves is: Why do we want to change the language in the first place?



Parentheses are at the heart of any Lisp (newLISP included). I think our reaction to them greatly depends on whether we have already been exposed to one of ALGOL's descendants. My first impression, after many years of avoiding Lisp, was of a very primitive, almost prehistoric language. The funny thing is: it is a prehistoric language, but it is anything but primitive.



After some time, you don't even notice the parens. Or you may even grow to love them, like Lutz does :-)



As Hans-Peter said above, I'm afraid your idea of using a CAD program to do programming with—while admittedly a fun exercise—would probably not be an improvement over a text editor.



I hope this has not discouraged you from trying anyway. Who knows, maybe you are onto something here.



m i c h a e l

[Jeremy Dunn]

Thanks all for the comments. Perhaps I should make certain things clearer about my approach. I love LISP and don't have a particular hatred of parentheses, its just that I am a minimalist at heart and am interested in the notion of how simple can code actually be. I can't believe that there is any disadvantage in reducing visual clutter wherever possible. I am a visual oriented person and to me the addition of context coloring into code editors was a godsend. Our visual systems cry out for color and 3D just to relieve boredom if nothing else. I felt that LISP of all languages was the ideal one to try this 3D approach on. Perhaps I will discover that some patches of code will block the view of other parts when written in 3D or that it is more trouble than it is worth but I have a gut feeling that seeing actual depth will provide more immediate visual feedback into overall structure than careful indenting would. HPW, there is one respect in which this approach is better for AutoCAD programmers in that you can draw instructive pictures off to the side to go along with your code. Trying to decipher a CAD program that is doing geometric operations merely from looking at the code can often be very difficult, but if you can draw a diagram in your program to show what all your variables are refering to can be an enormous help. My particular implementation is probably not the best that can be done but will be good enough for me to test the concept out and see if it has potential. Like the rest of you I have a day job and get most of my time on the weekends to devote to this. When I have something working I will give you all an update.

[TedWalther]

Jeremy, maybe you could do poor man's 3d by not only making the text lighter (fading it out) but also making the font smaller at each nesting level.



The biggest, brightest nesting level would be the one the cursor is in; super and sub levels would "fade out" on the same curve.



I really love your idea and would love to see it in action.  Think you can whip this up using tcl/tk, modifying the newlisp-tk editor?



Ted