Re: Parsing C#-like generics

BGB <>
Tue, 12 Jul 2011 16:39:25 -0700

          From comp.compilers

Related articles
Parsing C#-like generics (Harold Aptroot) (2011-07-11)
Re: Parsing C#-like generics (Hans-Peter Diettrich) (2011-07-12)
Re: Parsing C#-like generics (BGB) (2011-07-12)
Re: Parsing C#-like generics (Ben L. Titzer) (2011-07-13)
Re: Parsing C#-like generics (BGB) (2011-07-14)
| List of all articles for this month |

From: BGB <>
Newsgroups: comp.compilers
Date: Tue, 12 Jul 2011 16:39:25 -0700
References: 11-07-019
Keywords: parse
Posted-Date: 12 Jul 2011 20:05:28 EDT

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:

will parse as: T<x,y> followed by x.

should probably work I think, and wont (usually) give an unintended parsing.

except when someone types:
"foo(x<y, y>z);"

and wonders why they get a syntax error... ("parse error before 'z'.",
or similar).

next issue though is how to address things like:
T<V<x, y>>

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.

Post a followup to this message

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