And this is why it is standard practice to NEVER let the theoreticians anywhere near the experimental equipment.

That cartridge did indeed exist, but it was very rare.
https://www.atariage.com/softw...

As seen at http://www.samstoybox.com/toys...

Christmas present sometime around 1975 when I was 9 and had just been bitten by the computer bug. It really was beyond me at the time, but I didn't care.

It was quite probably copied from one of the Lisp systems. I used UTILISP many years ago and it had an sexpr structure editor available for code use. However, it still wrote out the code into files. The big stumbling block was comments, which are defined in most language syntaxes as a purely textual element that can go wherever you can put whitespace. And a simple rule for binding comments to parse nodes (such as bind-to-preceding) doesn't usually work because of varying commenting styles.

The blue book doesn't really describe how code is stored...that was more the domain of the orange book. I know from experience that the version of ST-80 I used in '85 used a .sources and .changes file. Given the hardware they had to run it on I think the reliance on old fashioned files is excusable. Contemporary systems, however, should be reconsidering how to approach this.

Is this ST version you use available for public use? What is its name (is it Zoku ST?) and where do you work? I'd love to try rewriting my syntax macros for it. I suspect it would make IDE integration much simpler than what I had facing me in VW.

A data point in this discussion is that it is traditional for Smallltalk implementations to use proportional fonts as the default for code editing. I've been programming in Smalltalk since 1985 and I think I've only encountered a couple of people who changed the default to anything but a proportional font. Some Smalltalks allow for rich text code, and then you'll see ASCII art done as a monospaced font section embedded in a larger proportional method or comment. But I've not seen it that often. Maybe I've led a sheltered life.

Another data point is the book "Human Factors and Typography for More Readable Programs" by Ronald Baecker and Aaron Marcus ( http://www.amazon.com/Human-Factors-Typography-Readable-Programs/dp/0201107457 ). In this outstanding volume they build a framework for understanding program legibility and an approach to formatting C programs that utilizes this framework. Recommended to anyone who wants to have a better understanding of the issues in this area.

Squeak Smalltalk stores it's code in the .sources and .changes files as either a String (for plain text and similar to how ST-80 did it) or as a serialized object of class Text (for rich text). VisualWorks was similar to Squeak in the storage format but now uses an XML format for the .sources and .changes that stores the method text as a chunk of plain unicode. Gnu ST is not image based and uses normal text files so it doesn't do what you describe. ISTR that VisualAge ST works pretty much the same way as VW. Gemstone/S is slightly different in that the plain text Strings that make up the source code are stored in the Gemstone object database (along with everything else) and not in a separate file. These are the ST versions I've used enough to know offhand how their code storage works. Which version of Smalltalk have you been using that stores serialized parse trees?

Are you referring to the code formatter in Squeak that auto-reformats a method on accept? That does use the parse tree to generate the source text, but the tree is thrown away after the operation. It does have the neat feature of supporting an alternate syntax.

I think doing what you describe could be an excellent idea as long as some details such as associating comments with parse nodes are dealt with. There was some work done in Squeak to do this in order to make the .changes and .sources less necessary (and save disk space) but it has not made it into the mainstream releases. I've also written a crude Common Lisp style syntax macro package for VW (it's in the public StORE)....and that would be a lot more efficient and useful if the parse trees were persistent.