Re: Learning about Lexing/Parsing in general form?

There is the ORA book lex & yacc, 2nd ed, which while I've not read through, looks like it has a good bit of intro into the parsing processing. While it was last published in 1992, lex and yacc (and the associated Gnu tools) haven't changed much since then either, so the book's quite valid.

But as the other poster put it, the only place outside of the docs on the net are books regarding compiler programming, and these are typically limited to textbooks at the college level. And since compile programming is typically a optional CS course, the number of books here are few and far between.

The other problem is that while using lex/yacc and other tools isn't in themselves a difficult task, developing a usable grammer, and implementing that grammar with those tools *is* one. And no one has really written anything 'good' in terms of a thought process, critical review, or similar, of grammar design as much as there is of OOP, programming style, etc. I would not be surprised to find a better trove of info in older USENET archives (pre1995) than what is on the net today for grammars.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

Comment on Re: Learning about Lexing/Parsing in general form?

Replies are listed 'Best First'.
Re: Re: Learning about Lexing/Parsing in general form? by mirod (Canon) on Dec 06, 2001 at 18:30 UTC
compile programming is typically a optional CS course This is really a shame. It was compulsary in my program, back in the mid 80's and I am really glad it was: I remember my first thought when I read the description of the class: "what a waste of time, only Mr C and Mss Fortran need to know about this, why on Earth should I care, I use compilers, I don't write them!". During the class I still thought it was useless but at least it was fun... unlike some other classes (COBOL anyone?). Then when I started working I soon find myself in the middle of a huge project that essentially consisted in writing 4 compilers (including one with incremental compiling, fun!) and a run time environment for an advanced test bench, then using lex/yacc to generate tests for an other project, then writing an interpreter for an SGML transformation language. Boy was I happy not to have cut that compiler class! And I don't even mention the number of time I had to write quick and dirty interpreters for very simple languages (subsets of XPath, DB queries...). In this case I generally use regexps but at least I know what they are good for and where to stop adding features to the language because i would then need to switch to lex/yacc. In essence any software processes input that can be defined as a language, so knowing when it makes sense to define this language and how to process it is really a great asset for a programer. Plus it's really fun!	[reply]

Replies are listed 'Best First'.

Re: Re: Learning about Lexing/Parsing in general form?
by mirod (Canon) on Dec 06, 2001 at 18:30 UTC

compile programming is typically a optional CS course

This is really a shame.

It was compulsary in my program, back in the mid 80's and I am really glad it was: I remember my first thought when I read the description of the class: "what a waste of time, only Mr C and Mss Fortran need to know about this, why on Earth should I care, I use compilers, I don't write them!".

During the class I still thought it was useless but at least it was fun... unlike some other classes (COBOL anyone?). Then when I started working I soon find myself in the middle of a huge project that essentially consisted in writing 4 compilers (including one with incremental compiling, fun!) and a run time environment for an advanced test bench, then using lex/yacc to generate tests for an other project, then writing an interpreter for an SGML transformation language. Boy was I happy not to have cut that compiler class!

And I don't even mention the number of time I had to write quick and dirty interpreters for very simple languages (subsets of XPath, DB queries...). In this case I generally use regexps but at least I know what they are good for and where to stop adding features to the language because i would then need to switch to lex/yacc.

In essence any software processes input that can be defined as a language, so knowing when it makes sense to define this language and how to process it is really a great asset for a programer.

Plus it's really fun!

[reply]