Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end From: glen herrmannsfeldt Newsgroups: comp.compilers Subject: Re: Compiling expressions Date: Sat, 29 Dec 2012 23:33:36 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 53 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-12-036@comp.compilers> References: <12-12-035@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1356903476 41705 64.57.183.58 (30 Dec 2012 21:37:56 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sun, 30 Dec 2012 21:37:56 +0000 (UTC) Keywords: parse Posted-Date: 30 Dec 2012 16:37:55 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:820 James Harris 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