Re: editor for direct editing of the syntax tree: possible?

Hi,

here's 2 things i would like to have when editing lisp code:

(1) have a function, such that when invoked, the current block of lisp
code the cursor is on, will be all reformatted by a mechanical rule.
(somewhat analogous to fill-paragraph)

For detail, see:
★ A Simple Lisp Code Formatter
http://xahlee.org/emacs/lisp_formatter.html

(2) have the ability to move cursor by syntax tree like emacs's
backward-sexp, down-list, mark-sexp etc., but on more complex tree
syntax the XML.

For detail, see
★ A Text Editor Feature: Syntax Tree Walking
http://xahlee.org/emacs/syntax_tree_walk.html

Xah
xah@xxxxxxxxxx
? http://xahlee.org/

On Jan 7, 8:56 am, ruzsa.bal...@xxxxxxxxx wrote:
Hello there.

In the past weeks I've been thinking about a source code editor which
would make it possible to directly edit the symbolic representation of
Lisp forms - as they are returned by the "read" function - instead of
manipulating the source as plain text (array of characters). In such
an editor, I could move around the atoms and lists (widen/narrow
focus, step forward/backward between elements on the current level)
with the arrow keys, I could use "c" to change an element, "a" to
append a new one after the current, "i" to insert one in front of the
current, "o" to enter a new list above the current one, etc.

To realize this, the Lisp system should somehow save the forms
resulting from "read" calls and associate them with the defined
package symbols (I don't know yet what to do with those forms which
"read" cannot identify as definers), so that they can be later
retrieved when the source for a given object is to be shown. The
editor would show a list of packages currently defined in the Lisp
system, and a list of symbols (grouped by type) defined in those
packages. If I choose a symbol, I see the source code for it, can edit
it and feed the updated version back to the system for evaluation
(like in Slime).

My first problem is that I'd like to preserve the original read
syntax. For instance, when read sees something like this: #x0bc2, it
should save the element in such a way, that it retains its format
(hexadecimal), so I can show it in the correct way later on. I thought
about a source-code representation system, using objects of class
"source-element" and its subclasses, which would make it possible to
save attributes of an element together with the element value
(representation). The read function would analyze each element, decide
its source-element-type, make up the corresponding source-element
object and store it in the source tree at the element's location. When
I want to show (deserialize) the source, each source-element could
have a print method which would give back the original element (or
there would be three variants for print-source: one which creates the
text representation for editing, another which creates a tree which
could be fed to eval, and yet another which could create a serialized
version which would contain the necessary object constructors to
recreate the internal tree when it is fed back to read - this way the
source could be exported to the file system for backup, version
control or transfer to another Lisp system).

I'm sure I'm not the first who thought about this - after all, the
idea directly follows from the fact that code is data in Lisp -, but
as there is no proliferation of such editors nowadays, I suspect that
my ideas are a bit naive. If you happen to have any insight into why
this is not such a good idea, or you know of an existing system -
possibly with downloadable source code - which implements a scheme
like this, or the obstacles the developers had to face during
implementation, I'd be happy to hear about it.

Sincerely,
Balazs Ruzsa
Hungary

.

Relevant Pages

  • Re: Newbie seeking feedback
    ... > primitive, especially the source editor - limited undo, no syntax ... I have used VC++ just enough to work with C libraries from Lisp. ... an array to keep the master copy of the table, rather a list of lists ... > (defun set-hard(grid) ...
    (comp.lang.lisp)
  • Re: Very poor Lisp performance
    ... >>> Is Lisp code not made less maintainable because of all those brackets? ... foo now contains a huge tree. ... printer uses for lists (there may also be an option for printing ... The easiest way to find out is to delete all the closing parens at the ...
    (comp.lang.lisp)
  • Re: how to speed up some lisp code?
    ... >> A lot of these questions are generic algorithm questions, ... >> necessarily at this stage Lisp specific. ... inserting elements into a tree are potentially the most expensive operations ... I may want to know the gritty details, ...
    (comp.lang.lisp)
  • Re: Hoy to copy a struct that represents a tree.
    ... I'm trying to do one exercise from Paul Graham's "Ansi Common Lisp": ... Sorry for the big amount of code, most of it is the tree definition ... If you use lists to represent n-ary trees, like they were meant to, ...
    (comp.lang.lisp)
  • Re: When is Xah going to ease up on Emacs...
    ... One part of the cons problem in lisp is that it forces programer to ... extracts the leafs of a tree. ... has abstracted low-level access to lists with functions, e.g. get-children, ...
    (comp.lang.lisp)