=?UTF-8?Q?Bison_determinis=E2=80=8Btic_LALR=281=29_parser_for_Java=2FC=2B=2B_=28?= =?UTF-8?Q?kind_of_complex_langauge=29_without_=27lexar_hack=27_support?=

Fri, 17 Aug 2012 11:22:38 -0700 (PDT)

          From comp.compilers

Related articles
=?UTF-8?Q?Bison_determinis=E2=80=8Btic_LALR=281=29_parser_for_Java=2FC hsad005@gmail.com (2012-08-17)
Re: Bison =?UTF-8?B?ZGV0ZXJtaW5pc+KAi3RpYyBMQUxSKDEpIHBhcnNlciBm?= =?U DrDiettrich1@aol.com (Hans-Peter Diettrich) (2012-08-18)
=?UTF-8?Q?Re=3A_Bison_determinis=E2=80=8Btic_LALR=281=29_parser_for_Ja hsad005@gmail.com (2012-08-18)
Re: lexer speed, was Bison DrDiettrich1@aol.com (Hans-Peter Diettrich) (2012-08-20)
Re: Bison =?UTF-8?B?ZGV0ZXJtaW5pc+KAi3RpYyBMQUxSKDEpIHBhcnNlciBm?= =?U anton@mips.complang.tuwien.ac.at (2012-08-20)
Re: lexer speed, was Bison DrDiettrich1@aol.com (Hans-Peter Diettrich) (2012-08-20)
Re: lexer speed, was Bison cr88192@hotmail.com (BGB) (2012-08-20)
[8 later articles]
| List of all articles for this month |

DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=cc:from:subject:date:sender:message-id:mime-version:content-type:content-transfer-encoding:vbr-info; s=ae98.502ef06a.k1208; i=johnl@user.iecc.com; bh=h5qJYacHvJ2eJs6bIqDgHyTAOBYTKHEjETnbQJ0gWJ0=; b=sd9CX0X5ZBJkkjpRRJiuh4lXpivW5KzIsxAa/htnwGIC1auVZTZAI6lmVrIGjDGqHav5WoWsbUdhhdWLslV1G1xMm5x5y8Rk8aAKfX5qIOECw50/LuyNQSDoBwScUWvbLr3h/MczP/8vhcx6gbQmx7Kj4Ti1j4L3GusxwclvAig=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
From: hsad005@gmail.com
Newsgroups: comp.compilers
Date: Fri, 17 Aug 2012 11:22:38 -0700 (PDT)
Organization: Compilers Central
Keywords: bison, question
Posted-Date: 17 Aug 2012 21:31:22 EDT

I need to write a parser for a programming langauge which is as
complex as C++/Java, and to even complicate the matter, there are
constructs in this langauge that doesn't allow me to use
type/identifier dis-ambiguating lexer hack. In other words, I will
have to return just one lexical token (say IDENTIFIER) from the lexer
for both type references as well as non-type variable references.

Given these restrictions, I was wondering if it would be a good idea
to pick yacc/bison for my parser...? Or, should I consider a hand
written recursive descent parser.

[Get it working in bison, then in the unlikely event that's not fast
enough, profile your compiler to see where it's spending its time and
fix what needs to be fixed. Although in theory GLR can be very slow,
in practice the ambiguities are generally resolved within a few tokens
and the performance is fine. compilers always spend way more time in
the lexer than the parser anyway. Writing RD parsers by hand can be
fun, but you never know what language it actually parses. -John]

Post a followup to this message

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