Re: Compiling expressions

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Sat, 29 Dec 2012 23:33:36 +0000 (UTC)

          From comp.compilers

Related articles
Compiling expressions james.harris.1@gmail.com (James Harris) (2012-12-29)
Re: Compiling expressions gah@ugcs.caltech.edu (glen herrmannsfeldt) (2012-12-29)
Re: Compiling expressions mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2012-12-30)
Re: Compiling expressions james.harris.1@gmail.com (James Harris) (2013-01-02)
Re: Compiling expressions james.harris.1@gmail.com (James Harris) (2013-01-02)
Re: Compiling expressions matzebraun@googlemail.com (matzebraun@googlemail.com) (2013-01-03)
Re: Compiling expressions torbenm@diku.dk (2013-01-03)
Re: Compiling expressions james.harris.1@gmail.com (James Harris) (2013-01-03)
[5 later articles]
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Sat, 29 Dec 2012 23:33:36 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: 12-12-035
Keywords: parse
Posted-Date: 30 Dec 2012 16:37:55 EST

James Harris <james.harris.1@gmail.com> wrote:


> Compiling expressions is turning out to be more 'interesting' than I
> anticipated! My requirements I believe to be fairly generic but they
> seem not to be supported by standard algorithms so it's not as simple
> as it might be. I thought I would post here as much out of interest as
> anything. I'm not after a prebuilt solution but would be interested to
> hear from other folks who have had similar issues to address. The
> requirements are:


> 1. Hand-written, not the output of a parser generator.


An interesting requirement.


I can understand need for speed, size, and such, and maybe one
of those requires a hand-written (hand optimized) parser.


If you are so restricted, do you allow your parser to be written
in a high-level language? To be compiled by a non-handwritten
compiler?


> 2. Efficient and without backtracking.


Seems reasonable to me, though the languages has to allow for it.


> 3. Precedences (and possibly associativities) defined in tables.


Tables most easily generated automatically, by a parser generator?


> 4. Output to be a tree structure.


> 5. Parenthesised subexpressions allowed.


> 6. Some operator families are *not* to associate with each other.
> See below.


So you generate an error when such occurs. The usual problem is
to make the error message good enough that one can figure out
what happened.


> 7. Monadic prefix, dyadic infix and monadic postfix operators are all
> allowed.


> 8. Prefix and infix operators can use some same symbols (e.g. minus
> sign).


> Infix and postfix operators use distinct symbols. For example, if a
> certain symbol were used as a postfix operator it could not also be
> used as an infix operator.


(snip)


-- glen


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.