From: Tim Bradshaw
Subject: Re: What's a structure editor?
Date: 
Message-ID: <nkjvgmykevc.fsf@tfeb.org>
·······@hotmail.com writes:

>  
> I've seen this term in texts referring to lisp, but  I don't exactly wat it
> is... :?

The source of a lisp program has an explicit representation as a Lisp
data structure, as well as one as a string.  (This representation of
the source of a program as structured data is very powerful feature of
the language.)  So, as well as editing a program as a string in the
conventional way, you can devise an editor which edits the structure
directly.  This editor can do things like ensuring the structure is
consistent &c.  For various reasons though, structure editors have not
been really successful for Lisp.  The best example I know of was
SEdit, which ran (runs?) on Xerox Lisp Machines.

--tim

From: Kent M Pitman
Subject: Re: What's a structure editor?
Date: 
Message-ID: <sfwlmnupxlg.fsf@world.std.com>
Tim Bradshaw <···@tfeb.org> writes:

> ·······@hotmail.com writes:
> 
> >  
> > I've seen this term in texts referring to lisp, but  I don't exactly wat it
> > is... :?
> 
> The source of a lisp program has an explicit representation as a Lisp
> data structure, as well as one as a string.  (This representation of
> the source of a program as structured data is very powerful feature of
> the language.)  So, as well as editing a program as a string in the
> conventional way, you can devise an editor which edits the structure
> directly.  This editor can do things like ensuring the structure is
> consistent &c.  For various reasons though, structure editors have not
> been really successful for Lisp.  The best example I know of was
> SEdit, which ran (runs?) on Xerox Lisp Machines.

Maclisp had a structure editor, too.  I used to sometimes use it.  It was
fun and very teco-like but not practical for normal program editing. 
Its most useful feature was its ability to insert into two points in a 
list a set of pseudo-parens and then to do an operation that would reform
the list to match that. e.g., you'd edit up
 ((foo 3 4))

to contain

 ((foo |%)%| 3 |%(%| 4))

and then use the () command, and it would yield

 ((foo) 3 (4))

It was pretty much obviated by Emacs once implementations had an always-present
emacs.  We did have Emacs back then, but it wans't running in the Lisp, it
was running by something like LISPT (the equivalent of modern ILISP) that
zapped expressions silently back and forth.  If you didn't already have it 
running and you made a typo, it was hard to fix except with the structure
editor.

- - - 

Btw, I heard a fascinating analysis by someone about the issue of structure
editors and text editors, that is all the more fascinating as I think back
to the future history that has occurred since the time I heard this analysis.

The claim by the person was that structure editors were hated by the
Maclisp [approximately: east coast/MIT] community because they didn't allow
careful control of program layout.  Maclisp/MIT (and subsequently Common
Lisp) wanted to control code layout and comments.  HOWEVER, coupled with
this was the need for carefully contorlled window layouts.  That is, tiled
window systems like the lisp machine where you specified the precise window
size and where people mostly didn't resize windows.  Very little "messy desk
top" on the lispm, partly because it had one major design flaw of having 
output being able to happen only in one window a time.  This was a deep issue
in window locking that was due to it being among the earliest window systems.
Other systems since then were designed better.  Anyway, if you have fixed
code layout, you want to specify your editor size to match, mostly, or  else
there is scrolling frustration.

On the Interlisp side, you had windows that were not fixed size, and so
structure editing, as a matter of  sociology, was a better tool.  People
relinquished control of layout in code, but gained the ability to resize
windows painlessly.  Since Maclisp killed Interlisp going into Common Lisp,
and with it killed its various artifacts, there went structure editng.

I heard this story while Lisp Machines were still king and it made
sense for tiled editors to be the thing of the day and structure
editors to be dead.  Nowadays, Lispms have fallen by the wayside, and
people size windows variously so there is an argument to be made that
we've lost out for not going the interlisp way.  I grew up on
positioning my code just so and I get HUGE error-checking advantage by
laying it out in a way that I like to lay it out.  I couldn't imagine
changing over to a structure editor.  But I also imagine that to be an
artifact of me, not of the language.  The language probably would
endure a shift back to structure editors, and might thrive on it.  I
know the Interlisp people adored it, and among them were some
interesting folks.

Of course the other way to do things is to give up the messy desktop and ask
Windows to go more toward a tiling model...  I'd prefer that.  Though over
time I've gotten more used to taking advantage of the weird things in the
messy desktop, and I think both systems have their advantage.

Back to the relation of window system style and  editing style, though,
it wouldn't surprise me to find that case sensitivity is intimately locked
up in this sociology, too, since structure editors would not retain user
case, and the only hope of seeing symbols in your preferred case would be
case retention...

This is one of the very interesting cases of how thinking of a language as
a mere static set of semantic rules loses the big picture of how languages
influence sociology and vice versa.  
From: Paolo Amoroso
Subject: Re: What's a structure editor?
Date: 
Message-ID: <e3gFO+el1RIP0I4ywDl2uEkES01w@4ax.com>
On Fri, 18 May 2001 13:59:07 GMT, Kent M Pitman <······@world.std.com>
wrote:

> Btw, I heard a fascinating analysis by someone about the issue of structure
> editors and text editors, that is all the more fascinating as I think back
> to the future history that has occurred since the time I heard this analysis.

This book includes a number of papers discussing both structure and text
editors:

  "Interactive Programming Environments"
  D.R. Barstow, H.E. Shrobe, E. Sandewall
  McGraw-Hill, 1984
  ISBN 0-07-003885-6
  610 pages

I include below the table of contents.


Paolo


------------------------------------------------------------------
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
------------------------------------------------------------------



-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Bob Bane
Subject: Re: What's a structure editor?
Date: 
Message-ID: <3B05757F.D723D1E0@removeme.gst.com>
·······@hotmail.com wrote:
> 
> On 18 May 2001 13:42:31 +0100, Tim Bradshaw <···@tfeb.org> wrote:
> 
> >consistent &c.  For various reasons though, structure editors have not
> >been really successful for Lisp.  The best example I know of was
> >SEdit, which ran (runs?) on Xerox Lisp Machines.
> 
> Is there anyone available in Linux or windows to take a look at?

http://www.parc.xerox.com/istl/groups/nltt/medley/

has downloadable Xerox/envos/Venue Common Lisp images containing The
Xerox LFG Grammar Writer's Workbench by Kaplan and Maxwell.  The FTP
site has Medley emulators for Alpha, SGI, SunOS, Solaris, DOS (!) and
Linux for Intel (the Linux was added in June 2000, according to the file
dates, and is down under medley35/linux/intel rather than at the top
level like the others).

I was not able to get the Linux stuff to run under SUSE 7.1, but after a
little fiddling with the lfgscript I brought up the Alpha version.  If
anyone else successfully runs the Linux version, please let me know how
you did it.

Be warned that the Interlisp/Medley window system is probably very
different from anything you've ever used.  It works best with a
three-button mouse, though you can chord a two-button mouse to get
middle button.

Once the system comes up, hold down right-button in the background,
select EXEC>Common Lisp, use left-button to sweep out a new listener,
then type into it:

ed (foo functions) <return>

A menu will pop up - select DEFUN from it, then use left-button to sweep
out a window to edit (defun foo ...).  Middle button in the title bar
brings up the SEdit menu, right-button there brings up the window
manipulation menu.  Try "Attach Menu" in the SEdit menu.

A few SEdit features:

* left-button selects a spot.  Repeated left-button expands the current
selection to the next-highest S-expression.  Right-button extends a
selection at the same level.

* shift-selection copies the selection to the current type-in point. 
Ctrl-selection deletes the selection.  Ctrl-shift-selection copies and
deletes (i.e. moves).

* Everything is pretty-printed dynamically as you type.  Pick a spot and
enter a comment - type one, two, three, four, five semi-colons and see
what it does.  Type in a string - see how you get two double-quotes when
you hit the first ", and how the type-in caret moves outside the string
when you type the second one.

-- 
Remove obvious stuff to e-mail me.
Bob Bane
From: Bulent Murtezaoglu
Subject: Re: What's a structure editor?
Date: 
Message-ID: <877kzdjp7i.fsf@nkapi.internal>
>>>>> "BB" == Bob Bane <····@removeme.gst.com> writes:

[on medley]
    BB> http://www.parc.xerox.com/istl/groups/nltt/medley/
[...]
    BB> I was not able to get the Linux stuff to run under SUSE 7.1,
    BB> but after a little fiddling with the lfgscript I brought up
    BB> the Alpha version.  If anyone else successfully runs the Linux
    BB> version, please let me know how you did it. [...]

I got it to run under Debian (mostly) Woody.  It needs libc5 and 
not much else other than X.  I got the "lfg.sysout" from 
ftp.parc.xerox.com:/pub/lfg/medley35 and the lfgscript from 
ftp.parc.xerox.com:/pub/lfg .  

Very cute.  I didn't think I'd ever see these screens live again!  Maybe 
someday we'll see Genera like this also.

cheers,

BM
From: Cyril N. Alberga
Subject: Re: What's a structure editor?
Date: 
Message-ID: <3B05CD37.3C8E17E9@bellatlantic.net>
Tim Bradshaw wrote:
> 
> ·······@hotmail.com writes:
> 
> >
> > I've seen this term in texts referring to lisp, but  I don't exactly wat it
> > is... :?
> 
> The source of a lisp program has an explicit representation as a Lisp
> data structure, as well as one as a string.  (This representation of
> the source of a program as structured data is very powerful feature of
> the language.)  So, as well as editing a program as a string in the
> conventional way, you can devise an editor which edits the structure
> directly.  This editor can do things like ensuring the structure is
> consistent &c.  For various reasons though, structure editors have not
> been really successful for Lisp.  The best example I know of was
> SEdit, which ran (runs?) on Xerox Lisp Machines.
> 
> --tim

LISP/VM, the IBM Research S/370 LISP, had a very powerful structure
editor, designed and written by Martin Mickelsons, now of Franz Lisp. 
It used very clever elision algorithms to show the immediate focus of
attention in detail while still giving a sketch of the over-all
structure of the data.  It's two main drawbacks were extrinsic.  First,
the dialect of LISP it supported and was written in pre-dated
CommonLisp, being somewhat Scheme-like, but rather eccentric.  (I
happened to like it very much, but then I wrote the compiler and
assembler for it, and had an emotional investment in it.)  Second, it
ran on VM/370, the successor of CP-CMS, and as such used the IBM 3270
display heads.  No mouse, no control keys, command-line controls and
line-at-a-time input and output.

I must say that I wish I could use LISP/VM again, and Martin's editor. 
I've always felt it gave me the best interface, with the highest
productivity, of any editor I've ever used for LISP.

Cyril N. Alberga