Path: utzoo!mnetor!tmsoft!torsqnt!snitor!doug From: doug@snitor.uucp (Doug Moen) Newsgroups: comp.lang.misc Subject: Re: syntactic extensions Message-ID: Date: 18 Feb 91 04:09:18 GMT References: <524@coatimundi.cs.arizona.edu> Organization: Siemens Nixdorf Lines: 44 On the topic of user definable operator syntax, gudeman@cs.arizona.edu (David Gudeman) writes: >You can't do it with (entirely) pre-compiled grammars like those >produced by yacc, but modern computer speeds make those superfluous. >Table-driven parsers with run-time modifiable tables are plenty fast >enough these days. There are many languages out there that *do* support user defined operator syntax, with unary, binary, and mixfix operators, within the confines of a fixed, yaccable grammar. Smalltalk-80 is a well known example. Smalltalk-80 supports 3 classes of operators: unary, binary, and keyword. There are 3 precedence levels, one for each class. Users can coin new operator names. Note that since all binary operators have the same precedence, the usual convention that * binds more tightly than + is not followed in Smalltalk-80. This does not seem to be a problem in practice. C++ and Ada also support user defined operators, in a slightly different way: you can't coin new operator names, but the usual convention of *, +, >, etc, having different precedences is supported. The one thing you can't do with a fixed grammar is support user defined operator precedence. The fixed grammar approach imposes two limitations: 1. All operators with the same name must have the same precedence. (eg, it's impossible for ? to have a higher precedence than * in one part of a program, and a different, unrelated binding of ? to have a lower precedence than * in another part of the same program) 2. The mapping from name to operator precedence is hard-wired into the language definition. These are desirable restrictions, and the reasons have nothing to do with speed of parsing. If a language has the above properties, then a human, knowing the language rules, can pick up an unfamiliar piece of code and immediately know how to parse it, without needing to first track down all of the operator definitions. This is a big win, both for when you are maintaining someone elses code, and for when you are trying to debug your own code. It is worth noting that Smalltalk-72 originally had a dynamic grammar. After gaining considerable experience with using, teaching, and debugging Smalltalk, the designers realized that the dynamic grammar was a mistake, and fixed the problem in Smalltalk-76. [There is an early paper on Smalltalk which discusses the dynamic grammar problem, but I can no longer find the reference. Can anyone help me out on this?]