RE: Specialized input parsing for code/REPL in DrScheme?

[Greg Pettyjohn <GregP@bsquare.com>]

> ps: How about this for an alternate editor idea: twist-up/down 
> triangles that show or hide whole s-exp tree branches?  Frontier and 
> the Mac OS (and just about every other file manager and outline 
> editor on the planet) use this idea.  This could make it easier to 
> navigate and edit large blocks of scheme code.

As long as people are talking about it...

Recently, I've been daydreaming about a "universal list editor".
The idea is that you would abandon language specific bracketing
conventions and go to a purely graphical representation.

A parenthesized expression would be replaced with the same
expression contained within a rectangle.

For example:

(this is some data)

Would translate into a rectangle on the screen containing
the words "this is some data"

(this is (some sub expression) data)

Would translate into a rectangle on the screen containing,
in order, the words "this is" followed by a rectangle, or
"subrectangle", containing the words "some sub expression"
followed by the word "data". I.e. rectangles would nest in the
natural way with left-to-right, top-to-bottom order.

The editor would use keyboard input to signal when rectangles are
created. E.g. you type '(' and the editor automatically creates a
new subrectangle. When you type ')' the subrectangle is "closed"
and data entry continues in the parent rectangle.

The motivation is that a graphical editor would gray the distinction
between alternative external data representation. For example, the
XML expression:

<foo> this is <bar> some sub expression </bar> data </foo>

Would look the same on the screen as the expression above. Well
almost the same, you would have to establish a convention for
how to identify the tags with a particular rectangle.

Further more, special forms could be represented with special rectangles,
The "lambda rectangle" would be shaped differently than a normal
"procedure application" rectangle, and the parameters part could be
integrated into the lambda rectangle in a special way so that they
wouldn't appear as simply a subrectangle containing symbols.

I think that this notion of unique graphical representation of special
forms would be especially useful in education. The different parts
of an expression would reveal themselves to the beginner in an obvious
manner.

Now the idea can be expanded further. Think of a list as an object with
two members: car and cdr. A rectangle would be an object with potentially
many methods: car, cdr, title, tag, color, shape 
Whater you want, provided that you have a graphical means of displaying
the members. E.g. a title member might be text in the "title bar" of
a rectangle --- which rectangle might begin to look like a window. 
A "tagged" rectangle would have the tag text as part of the border
in the upper left corner.

Rectangles could be minimized or expanded by the editor so that the
whole global structure of a program could be easily navigated.

What about units? Imagine a "compound unit" expression as a container
rectangle. Within it would be rectangles representing the sub-units.
These sub-units would have triangles and circles on their borders
corresponding to exports and imports. The exports of one unit could
then be connected via a "circuit path" to the import of another unit.
(The circuit layout software I saw when I worked at the plotter manufacturer
comes to mind.) This would make a concept which I found difficult to
learn more intuitive.

But so far, admittedly, it is just vaporware.

:-)