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

[John Clonts <jclonts@mastnet.net>]

Greg Pettyjohn wrote:
> 
> > 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.
> 
> :-)

That sounds great... during the extended threads on comp.lang.lisp
someone made reference to these sorts of things having been done
before.  I like the idea of the VR extension, where I am inside my
workspace with my left-hand being 'car' and my right-hand being 'cdr' :)

Cheers,
John

-- 
[:o|]