gudeman@cs.arizona.edu (David Gudeman) (02/17/91)
In article <1991Feb16.235050.8231@rice.edu> Preston Briggs writes: ]hrubin@pop.stat.purdue.edu (Herman Rubin) writes: ] ]>What is needed in addition is a language which allows ]>the introduction of operator syntax according to the ]>user's desires. ] ]This is a hard thing. People have been fooling with it for years ]and haven't gotten very useful results. The Lisp community ](especially the Schemers) are probably the most advanced, ]but many people seem unwilling to accept the parentheses and other overhead. I have to disagree. I think the problem has been essentially solved for Scheme and Lisp (with minor improvements still possible), given that you are willing to put up with the syntax. And for general syntax the problem has been mostly solved by Prolog implementors, with some minor caveats associated with finite look-ahead grammars. 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. -- David Gudeman gudeman@cs.arizona.edu noao!arizona!gudeman
doug@snitor.uucp (Doug Moen) (02/18/91)
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?]
new@ee.udel.edu (Darren New) (02/20/91)
In article <jrukre6em@snitor.uucp> doug@snitor.uucp (Doug Moen) writes: >[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?] I remember something like this discussed in "Smalltalk: Bit of History, Words of Advice", which is the `green' book. Sorry -- no better reference, as my copy is 46 miles away. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
gudeman@cs.arizona.edu (David Gudeman) (02/20/91)
In article <jrukre6em@snitor.uucp> Doug Moen writes: ]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... ]The one thing you can't do with a fixed grammar is support user defined ]operator precedence... Then you don't really have user-definable operator syntax. In Prolog you can define precedences, allowing the user to create a large number of familiar and novel notations. If you can't define precedence, then you can't do this in general. C++ just has operator overloading, not definition of new operators. Smalltalk just has a strange function calling notation: "x1 f x2 f3 ... fn xn" (where the fi are lexical tokens associated with f) instead of f(x1,x2,...,xn). Far from letting the user define operators, Smalltalk restricts you to their own peculiar syntax. When Smalltalk lets you choose the lexical tokens for seperating arguments, that's no different from another language letting you choose function names. I have similar complaints with APL and Lisp. All of these so-called solutions to the problem of letting users define their own syntax begin by eliminating most of the syntaxes that users want. Then they talk about how this isn't a problem "in practice" once you become comfortable with their notation. I don't want to become comfortable with their notation. I want to define notations that I am already comfortable with. ]... 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 (like many other arguments given by proponents of paternalistic languages) sounds like sour grapes. The problem was hard to solve, so someone decided that we didn't want to solve it anyway. Sadly, once those arguments make it into the popular wisdom, then even when a solution comes along, it is not used because people already decided that they didn't want it. -- David Gudeman gudeman@cs.arizona.edu noao!arizona!gudeman