Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Bad for the next maintainer (Score 1) 394

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.

Comment I'm suprised not to see this mentioned (Score 2, Informative) 394

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.

Comment Re:Bad for the next maintainer (Score 1) 394

Well, the problem really is storing code as text. Smalltalk code is usually stored as a serialised parse tree. When you edit the code, you dump a method as text through a pretty-printer, edit it, and parse it again. None of these issues apply because the stored representation doesn't contain whitespace at all, and you can automatically insert whitespace wherever you want it.

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.

Slashdot Top Deals

No man is an island if he's on at least one mailing list.

Working...