|Introducing new operators (was: Re: Scientists as Programmers) firstname.lastname@example.org.OZ.AU (1992-09-08)|
|Re: Introducing new operators (was: Re: Scientists as Programmers) email@example.com (1992-09-11)|
|Re: Introducing new operators (was: Re: Scientists as Programmers) firstname.lastname@example.org (1992-09-11)|
|From:||email@example.com.OZ.AU (Fergus James HENDERSON)|
|Organization:||Computer Science, University of Melbourne, Australia|
|Date:||Tue, 8 Sep 1992 17:49:50 GMT|
firstname.lastname@example.org (Gary Blair) writes:
>email@example.com (Chris Dollin) writes:
>>In article ... firstname.lastname@example.org.OZ.AU (Fergus James HENDERSON) writes:
>> C++ allows you to overload existing operators, although to make compiler
>> writer's jobs easier, it does not allow you to introduce new operators.
>>Make that ``trivially easier''. ...
>Wrong. If your compiler uses ANY kind of table-driven parsing scheme, it is
>next to impossible to allow programmer-defined operators. The parser must
>know what an operator looks like, and what precedence it has with respect
>to all other operators. This is usually predetermined, at
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. The difficulty with knowing
what precedence a given operator has, or indeed exactly which characters
constitute an operator, is then exactly analagous to the "typedef" problem
in C (determining whether an identifier is a type name or not), and can be
handled with the same sort of hack (feeding information from the parser
back into the lexer).
All the same, it is not trivial. If you also have to worry about backwards
compatability with C, it becomes very difficult indeed, I suspect.
Fergus Henderson email@example.com.OZ.AU
Return to the
Search the comp.compilers archives again.