Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!news.glorb.com!transit3.readnews.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!nerds-end From: BGB Newsgroups: comp.compilers Subject: Re: Parsing C#-like generics Date: Tue, 12 Jul 2011 16:39:25 -0700 Organization: albasani.net Lines: 64 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-07-022@comp.compilers> References: <11-07-019@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: gal.iecc.com 1310515528 65440 64.57.183.58 (13 Jul 2011 00:05:28 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Wed, 13 Jul 2011 00:05:28 +0000 (UTC) Keywords: parse Posted-Date: 12 Jul 2011 20:05:28 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:198 On 7/11/2011 11:22 AM, Harold Aptroot wrote: > Hi, > > I'm having some trouble parsing generics when mixed with comparisons. The > way I try to do it, there is an ambiguity between LessThan and a "list of > types between angle brackets". > > Can this be done with an LALR parser at all? If so, how? > don't know about LALR, but in general, the solution I would think would be to require each '<' to have a matching '>' and exclude expressions which contain comparisons. say, we have the construction (informal BNF-like syntax here): sharplist = '<' sharpargs '>' sharpargs = sharparg [ ',' sharpargs] generic = qname sharplist generic could then be used wherever a generic is needed, possibly nearer the top of the expression tower (higher precedence), or it could only be placed in contexts where a type-name is expected (this depends some on language, such as whether or not expressions and type-expressions are unified, ...). now, what about sharparg? it is an expression type that presumably excludes comparrisons: sharparg = expr_addsub //+,- and above this way, since we only have the top end of the precedence tower, the '<' and '>' operators are excluded, and thus will not be eaten by the expression parsing. so, an expression like: Tx will parse as: T followed by x. should probably work I think, and wont (usually) give an unintended parsing. except when someone types: "foo(xz);" and wonders why they get a syntax error... ("parse error before 'z'.", or similar). next issue though is how to address things like: T> where a naive tokenizer will parse '>>' as a single token rather than '>' followed by '>'. in my parsers, it is less of an issue since I use recursive descent and tokenize inline, hence I can cheat it, but with a more generic lexer one might have to, say, treat '>>' itself as a special case.