Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!arizona!gudeman From: gudeman@cs.arizona.edu (David Gudeman) Newsgroups: comp.lang.misc Subject: Re: syntactic extensions Message-ID: <531@coatimundi.cs.arizona.edu> Date: 19 Feb 91 22:32:05 GMT Sender: news@cs.arizona.edu Lines: 49 In article 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