Article View: comp.lang.misc
Article #2797Re: syntactic extensions
From: Doug Moen
Date: Mon, 18 Feb 1991 04:09
Date: Mon, 18 Feb 1991 04:09
44 lines
2831 bytes
2831 bytes
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?]
Technical Details
Message-ID:
<jrukre6em@snitor.uucp>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!tmsoft!torsqnt!snitor!dougReferences:
<524@coatimundi.cs.arizona.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!tmsoft!torsqnt!snitor!doug From: doug@snitor.uucp (Doug Moen) Newsgroups: comp.lang.misc Subject: Re: syntactic extensions Message-ID: <jrukre6em@snitor.uucp> Date: 18 Feb 91 04:09:18 GMT References: <524@coatimundi.cs.arizona.edu> Organization: Siemens Nixdorf Lines: 44