www.digitalmars.com         C & C++   DMDScript  

D.gnu - lexer for flex

reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8Bit

I have written a flex lexer for d - source attached
please point out any bugs

(bison parser to follow when written)

C 2002/6/11
Jun 11 2002
parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
"C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
news:ae5bmk$2u97$1 digitaldaemon.com...
 Content-Transfer-Encoding: 8Bit

 I have written a flex lexer for d - source attached
 please point out any bugs

 (bison parser to follow when written)

It seems you have started what I did too :-) However, I ran into problems with the declaration grammar. The problem is that bison does not do N look-ahead that seems to be required by the D grammar - at least if "parse.c" is to be translated more or less directly. The problem is the Parse::is...() methods in "parse.c" that makes the grammar LALR(N). I have not figured out any way to solve this problem. Another problem is that you cannot easily destinguish type names from other names as in C. If you find your way around these problems, I would very much like to hear about it. I stopped for these reasons. I did the statements and expressions, though, and the grammar attached to this mail might help you or someone else getting started. I guess TOK_TYPENAME should not be defined as a token as i did, but I did not know better. After once having problems porting a flex generated lexer to an EBCDIC platform, I haven't used it since - so I don't have a .l file like you. But if you substitute the token names it should do. Regards, Martin M. Pedersen
Jun 11 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
Why not just use lexer.c and parse.c more or less directly?
Jun 11 2002
next sibling parent C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
Walter wrote:

 Why not just use lexer.c and parse.c more or less directly?

No offence, but they are written in C++, which will not interface to BTL and would probably be a pain to interface to GCC. And anyway the best way to understand a language fully is to write a compiler for it. PS: Thanks to MMP for the parser yacc source, my version mainly consists of rebuilding a grammar I wrote some time ago to parse oomic - just got some shift/reduce conflicts to resolve. C 2002/6/12
Jun 12 2002
prev sibling parent "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ae60k2$iq5$1 digitaldaemon.com...
 Why not just use lexer.c and parse.c more or less directly?

My reasons are the same as described by C.R.Chafer, portability and understanding. Also, using a tool like bison documents the grammar, makes it easier to maintain and experiment with, and it pinpoints ambiguties in the grammar. Regards, Martin M. Pedersen
Jun 12 2002
prev sibling parent reply Erik de Castro Lopo <nospam mega-nerd.com> writes:
"Martin M. Pedersen" wrote:
 
 It seems you have started what I did too :-) However, I ran into problems
 with the declaration grammar. The problem is that bison does not do N
 look-ahead that seems to be required by the D grammar - at least if
 "parse.c" is to be translated more or less directly. The problem is the
 Parse::is...() methods in "parse.c" that makes the grammar LALR(N). I have
 not figured out any way to solve this problem. Another problem is that you
 cannot easily destinguish type names from other names as in C. If you find
 your way around these problems, I would very much like to hear about it. I
 stopped for these reasons.

Bison is also able to generate GLR parsers (since 1.50) via the "%glr-parser" option. Have you looked that using this? Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ Fundamentalist : Someone who is colour blind and yet wants everyone else to see the world with the same lack of colour.
Jul 09 2004
parent reply "Nicolas Lehuen" <nicolas.lehuen thecrmcompany.com> writes:
I'm not expert in the parsing department, but I used ANTLR =
(http://www.antlr.org/) which is a LL(k) parser generator, outputing =
Java, C# or C++. Maybe they could be nudged into generating D code as =
well ?

Regards,
Nicolas Lehuen

"Erik de Castro Lopo" <nospam mega-nerd.com> a =E9crit dans le message =
de news:40EF24E3.B5BE2EB5 mega-nerd.com...
 "Martin M. Pedersen" wrote:
=20
 It seems you have started what I did too :-) However, I ran into =


 with the declaration grammar. The problem is that bison does not do =


 look-ahead that seems to be required by the D grammar - at least if
 "parse.c" is to be translated more or less directly. The problem is =


 Parse::is...() methods in "parse.c" that makes the grammar LALR(N). =


 not figured out any way to solve this problem. Another problem is =


 cannot easily destinguish type names from other names as in C. If =


 your way around these problems, I would very much like to hear about =


 stopped for these reasons.

Bison is also able to generate GLR parsers (since 1.50) via the=20 "%glr-parser" option. Have you looked that using this? =20 Erik --=20 +-----------------------------------------------------------+ Erik de Castro Lopo nospam mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ Fundamentalist : Someone who is colour blind and yet wants everyone else to see the world with the same lack of colour.

Oct 01 2004
parent Deja Augustine <deja scratch-ware.net> writes:
Nicolas Lehuen wrote:
 I'm not expert in the parsing department, but I used ANTLR
(http://www.antlr.org/) which is a LL(k) parser generator, outputing Java, C#
or C++. Maybe they could be nudged into generating D code as well ?
 
 Regards,
 Nicolas Lehuen
 
 "Erik de Castro Lopo" <nospam mega-nerd.com> a écrit dans le message de
news:40EF24E3.B5BE2EB5 mega-nerd.com...
 
"Martin M. Pedersen" wrote:

It seems you have started what I did too :-) However, I ran into problems
with the declaration grammar. The problem is that bison does not do N
look-ahead that seems to be required by the D grammar - at least if
"parse.c" is to be translated more or less directly. The problem is the
Parse::is...() methods in "parse.c" that makes the grammar LALR(N). I have
not figured out any way to solve this problem. Another problem is that you
cannot easily destinguish type names from other names as in C. If you find
your way around these problems, I would very much like to hear about it. I
stopped for these reasons.

Bison is also able to generate GLR parsers (since 1.50) via the "%glr-parser" option. Have you looked that using this? Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ Fundamentalist : Someone who is colour blind and yet wants everyone else to see the world with the same lack of colour.


To the best of my knowledge, Andy Friesen on the d.D newsgroup posted his D ANTLR grammar. Might be able to save yourself some work. -Deja
Oct 02 2004