Related articles |
---|
Introducing new operators (was: Re: Scientists as Programmers) fjh@munta.cs.mu.OZ.AU (1992-09-08) |
Re: Introducing new operators (was: Re: Scientists as Programmers) drw@euclid.mit.edu (1992-09-11) |
Re: Introducing new operators (was: Re: Scientists as Programmers) kers@otter.hpl.hp.com (1992-09-11) |
Newsgroups: | comp.compilers |
From: | drw@euclid.mit.edu (Dale R. Worley) |
Organization: | MIT Dept. of Tetrapilotomy, Cambridge, MA, USA |
Date: | Fri, 11 Sep 1992 18:11:33 GMT |
Followup-To: | comp.compilers |
References: | <1992Sep3.112944.20996@dbsun.uucp> 92-09-053 |
Keywords: | parse, design, algol68 |
fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>If your compiler uses ANY kind of table-driven parsing scheme, it is
>next to impossible to allow programmer-defined operators. ...
I think that "next to impossible" is perhaps overstating the case a
little. If you have a small number of precedence levels (eg. Haskell has
only 10 or 16 I think), then it is quite possible to code up each of these
precedences as a production in the grammar.
Yes. I once wrote an Algol 68 front-end, and the scanner simply
translated all operators into one of 11 tokens (ten tokens for the ten
precedence levels of binary operators and one token for unary operators).
The tricky part was that Algol 68 allows one to use a user-defined
operator before declaring it, so you have to pre-scan the text to build
the part of the symbol table that defines the operator precedences, and
then on a second pass actually parse the expressions.
Dale Worley Dept. of Math., MIT drw@math.mit.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.