> One thing that I'm surprised hasn't been mentioned in this thread is > that the C/L/HOLA is designed to support "domain-" and "mood-specific" > programming. I think it makes sense to have uniform Smalltalk-like > messaging semantics as the default, but to make it easy to shift over > to "math precedence" for domains where it makes sense. > > This approach risks causing confusion when switching between parts of > the program which use different operator precedence. I think that the > UI can help with this by making it clear which precedence rules are in > effect. I've attached a mock-up of a Squeak workspace with an > embedded mathematical expression. It is clear from the font and > layout where the domain-specific mathematical notation is being used.
+1, and how did you make the screenshot? (just pasted from LaTeX?) It would be worthwhile to think about distinction of internal representation and user (external) representation. The internal should better be uniform, and nothing can beat S-expressions. The uniform internal representation helps to write a program that analyze it, generate it, and manipulate it. (Yeah, this is true only if "Tree is the Answer".) An external representation (or user syntax) can be different. (Lisp has the 1-to-1 mapping between them, and makes it virtually the same.) People want to have better visual cues for distinct language constructs like control structures, so probably it would be better to have a way to provide such cues. For arithmetic operators in Smalltalk, people would have turned away less often if Smalltalk has one or a few more operator precedence (just for four basic arithmetic operations would have been making difference), and it would not have killed other niceness of Smalltalk. The old way to write Smalltalk parser and compiler was deeply based on a craftmanship, but wasn't really easily extendable. But now it should be different. Personally, I don't mind having arithmetic precedence rules in a language so much, if I also have an easy way to manipulate the abstract syntax tree. One of the keys I think is to have an easy way to going back and forth between these representations. Ideally, just one syntax definition could provide bi-directional transformation of forms. So that making a new syntax extension and manipulating it can be simple. -- Yoshiki _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
