Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Parsing C#-like generics harold.aptroot@gmail.com (Harold Aptroot) (2011-07-11) |
| Re: Parsing C#-like generics DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-07-12) |
| Re: Parsing C#-like generics cr88192@hotmail.com (BGB) (2011-07-12) |
| Re: Parsing C#-like generics ben.titzer@gmail.com (Ben L. Titzer) (2011-07-13) |
| Re: Parsing C#-like generics cr88192@hotmail.com (BGB) (2011-07-14) |
| From: | "Harold Aptroot" <harold.aptroot@gmail.com> |
| Newsgroups: | comp.compilers |
| Date: | Mon, 11 Jul 2011 20:22:34 +0200 |
| Organization: | A noiseless patient Spider |
| Keywords: | parse, question |
| Posted-Date: | 12 Jul 2011 07:04:26 EDT |
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".
For example, x<x>(x<x) should be syntactically OK, and it should be parsed
to a function call x with a type parameter list < x > and a single argument
which is the expression x<x (ok not really, I threw in semantics here to
make it clearer, the actual result should just be an AST).
My parser generator (GOLD parsing system) complains about a shift-reduce
error, and the parser it produces doesn't want to parse any expression with
a LessThan in it because it believes that to be a incomplete type list
(lacking a closing > )
I know it is actually inherently ambiguous, because t<t2>(t3) could mean two
things:
- LessThan(t, BiggerThan(t2, t3)
- invoke t<t2> with argument t3
In that case I want to pick option two.
For t<t2>t3 I want to pick option one, not report "missing ( "
Can this be done with an LALR parser at all? If so, how?
harold
Return to the
comp.compilers page.
Search the
comp.compilers archives again.