Groups | Search | Server Info | Login | Register


Groups > comp.compilers > #198

Re: Parsing C#-like generics

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 <cr88192@hotmail.com>
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> (permalink)
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

Show key headers only | View raw


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".

<snip>

>
> 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:
T<x,y>x

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.

Back to comp.compilers | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Parsing C#-like generics "Harold Aptroot" <harold.aptroot@gmail.com> - 2011-07-11 20:22 +0200
  Re: Parsing C#-like generics Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2011-07-12 13:25 +0100
    Re: Parsing C#-like generics BGB <cr88192@hotmail.com> - 2011-07-14 13:13 -0700
  Re: Parsing C#-like generics BGB <cr88192@hotmail.com> - 2011-07-12 16:39 -0700
  Re: Parsing C#-like generics "Ben L. Titzer" <ben.titzer@gmail.com> - 2011-07-13 10:19 -0700

csiph-web