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
In article
<····································@1g2000hsl.googlegroups.com>,
············@gmail.com 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).
...
>
> Sincerely,
> Balazs Ruzsa
> Hungary
You can study what InterLisp's S-Edit did.
Documents are here: http://www.bitsavers.org/pdf/xerox/interlisp/
There is also an InterLisp emulator to use S-Edit, google
for it.
You might also find the following (old, from 1984) book to be useful:
'Interactive Programming Environments', by Barstow, Shrobe and Sandewall.
Highly recommended. Chapter 14 explains for example
DED, a structure editor. There is also a 'conversation' with
Richard Stallman about the topic.
(the following was typed by Paolo Amoroso)
"Interactive Programming Environments"
D.R. Barstow, H.E. Shrobe, E. Sandewall
McGraw-Hill, 1984
ISBN 0-07-003885-6
610 pages
------------------------------------------------------------------
1 Perspective on Interactive Programming Environments
1 Breaking the Complexity Barrier (Again)
T. Winograd
2 Power Tools for Programmers
B.A. Sheil
3 Programming in an Interactive Environment: The Lisp Experience
E. Sandewall
2 Modern Interactive Programming Environments
4 The Interlisp Programming Environment
W. Teitelman, L. Masinter
5 The Cornell Program Synthesizer: A Syntax-Directed Programming
Environment
T. Teitelbaum, T. Reps
6 An Interactive Programming System for Pascal
J. Wilander
7 Programming Environments Based on Structured Editors: The MENTOR
Experience
V. Donzeau-Gouge, G. Huet, G. Kahn
8 The Influence of an Object-Oriented Language on the Programming
Environment
A. Goldberg
9 The UNIX Programming Environment
B.W. Kernighan, J.R. Mashey
10 A System for Program Refinement
T. Cheatham, J. Townley, G. Holloway
3 Aspects of Interactive Programming Environments
11 User Engineering Principles for Interactive Systems
W.J. Hansen
12 Automated Programming: The Programmer's Assistant
W. Teitelman
13 A Display-Oriented Programmer's Assistant
W. Teitelman
14 A Display-Oriented Editor for Interlisp
D.R Barstow
15 EMACS: The Extensible, Customizable, Self-Documenting Display Editor
R.M. Stallman
16 The LISP Machine
R.D. Greenblatt, T.F. Knight Jr., J. Holloway, D.A. Moon, D.L. Weinreb
17 UNIX Time-sharing System: The Programmer's Workbench
T.A. Dolotta, R.C. Height, J.R. Mashey
18 Software Tools in the User Software Engineering Environment
A.I. Wasserman
19 A Layered Approach to Software Design
I.P. Goldstein, D.G. Bobrow
20 Why Programming Environments Need Dynamic Data Types
J.W. Goodwin
21 Software Architecture Based on Communicating Residential Environments
E. Sandewall, C. Stromberg, H. Sorensen
4 Artificial Intelligence in Interactive Programming Environments
22 Initial Report on a Lisp Programmer's Apprentice
C. Rich, H.E. Shrobe
23 The Programmer's Apprentice: Knowledge-Based Program Editing
R.C. Waters
24 The Refinement Paradigm: The Interaction of Coding and Efficiency
Knowledge in Program Synthesis
E. Kant
5 The Future of Interactive Programming Environments
25 Beyond Programming Languages
T. Winograd
26 Rationale for Stoneman
J.N. Buxton
27 The Spice Project
S.E. Fahlman, S.P. Harbison
28 From Interactive to Intelligent Programming Environments
D.R. Barstow, H.E. Shrobe
--
http://lispm.dyndns.org/
············@gmail.com writes:
> [...]
> 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
Have a look at:
http://darcs.informatimago.com/darcs/public/lisp/common-lisp/reader.lisp
http://darcs.informatimago.com/darcs/public/lisp/common-lisp/source-text.lisp
> 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.
It's not a bad idea, but the raw structure of lisp sources are BINARY
trees of cons cells. It would be painful to edit sources as:
(DEFUN . (FACT . ((X . ()) . ((IF . ((< . (X . (1 . ()))) . (1 .
((* . (X . ((FACT . ((1- . (X . ())) . ())) . ()))) . ())))) . ()))))
So you need to have an idea of the abstract syntax, knowing that defun
takes a name, an argument list, a sequence of declarations and
documentation strings, and a sequence of expressions. Then you could
indent it nicely. Of course, you need to know it for user defined
macros too, hence slime talking to the inferior lisp process to know
how to indent the source.
Of course, with a source-text parser like the above one, you could
rely on the formating of the original source, (you wouldn't use
CL:READ to read the inserted forms, you'd have to use
SOURCE-TEXT:READ), but then, you don't really have a structural editor,
since the user must format the text like in any other emacs.
Otherwise, you could just realize there's no spoon. Have a look at:
http://groups.google.com/group/comp.lang.lisp/msg/3050088218d355e5
--
__Pascal Bourguignon__ http://www.informatimago.com/
CAUTION: The mass of this product contains the energy equivalent of
85 million tons of TNT per net ounce of weight.
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:
$B!z(B 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
$B!z(B A Text Editor Feature: Syntax Tree Walking
http://xahlee.org/emacs/syntax_tree_walk.html
Xah
···@xahlee.org
$B-t(B http://xahlee.org/
On Jan 7, 8:56 am, ············@gmail.com 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
På Wed, 09 Jan 2008 00:18:25 +0100, skrev Xah Lee <···@xahlee.org>:
> 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
> ···@xahlee.org
> ∑ http://xahlee.org/
But emacs lisp mode already has these! <alt>-x lisp-mode
<ctrl>-h-m
Of course for Common Lisp editing one uses SLIME
--------------
John Thingstad
In article
<····································@f47g2000hsd.googlegroups.com>,
Xah Lee <···@xahlee.org> wrote:
> 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:
> $B!z(B A Simple Lisp Code Formatter
> http://xahlee.org/emacs/lisp_formatter.html
As I said somewhere here, that is called 'grinding'. Zmacs does
that (M-x Format Code). I haven't seen that for Emacs.
> (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
> $B!z(B A Text Editor Feature: Syntax Tree Walking
> http://xahlee.org/emacs/syntax_tree_walk.html
For more support to edit Lisp code in Emacs see:
http://www.emacswiki.org/cgi-bin/wiki/ParEdit
http://mumble.net/~campbell/emacs/paredit.html
and
http://www.foldr.org/~michaelw/emacs/redshank/
Both are quite useful.
>
> Xah
> ···@xahlee.org
> ? http://xahlee.org/
>
> On Jan 7, 8:56 am, ············@gmail.com 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
From: Evans Winner
Subject: Re: editor for direct editing of the syntax tree: possible?
Date:
Message-ID: <86ir23rh9k.fsf@timbral.net>
Xah Lee <···@xahlee.org> wrote:
(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)
Something like this in Emacs lisp?
(defun grind ()
(interactive)
(save-excursion
(beginning-of-defun)
(indent-pp-sexp)))
It probably needs tweeking, may require a late version of Emacs, may not
leave point where you expect. I haven't tested it. Just wondering if
it is the general idea you are looking for.