I just finished taking compiler techniques class this semester and I'd like to write my own based on the one used in the class. The class uses Java with JLex and JavaCUP, but I don't really like Java and I want to rewrite it in FP. However, there are some choices for writing the scanner and parser:

1. PLex & PYacc
Question: Differences between 4.1a and FP distributed version? Pros: Easier to translate from original version
Cons: Not so easy to translate from EBNF notation

2. Coco/R
Question: TP vs Delphi version, which one is more appropriate for FP? Pros: Very close to EBNF, Modula-2 / Oberon-like structure, has many features
Cons: Needs changes from original version (my lecturer doesn't give EBNF notation)

3. Handwritten
Question: Need some references other than Jack Crenshaw's book Pros: Easier to maintain (someone said, but no prove) Cons: I don't have any practical background on this

From the given choices, which one will you suggest?

Hi,

There is also Gold Parser builder at http://www.devincook.com/ , wich has a Delphi engine.
IIRC, it uses BNF for the grammars, though.

It depends on the language, basically. If the language you want to compile can be easily parsed by a recursive descent parser, then it's not that difficult.
I don't think it's easier to maintain. If you change the grammar, in a table driven parser you would only have to regenerate the tables. In a hand written parser, you must implement the changes yourself. On the other hand, it's YOUR code that you are maintaining, so it should make some sense to you. ;-)
Wirth's book "Algorithms + Data Structures = Programs" contanis a recursive descent parser+p-code compiler+p-code interpreter for a subset of pascal.
I studied it and used it as a base for an integrated interpreter in a commercial app years ago with success.

Regards,

Gerard.

There's also "Compiler Construction" by Prof. Wirth, Addison-Wesley, 1996, ISBN 0-201-40353-6. It describes a subset of Oberon, rather than Pascal, but it does have the advantage that he seems to have released it (or rather, a revised 3rd edition) as a PDF. The original link I found was

http://www.oberon.ethz.ch/WirthPubl/CBEAll.pdf

but http://www.oberon.ethz.ch/WirthPubl seems to have disappeared since he retired. Google says the PDF is on a website of the National Technical University of Athens, at

http://www.dbnet.ece.ntua.gr/~adamo/csbooksonline/CBEAll.pdf

Frank

Frank Peelo wrote:
...

There's also "Compiler Construction" by Prof. Wirth, Addison-Wesley, 1996, ISBN 0-201-40353-6. It describes a subset of Oberon, rather than Pascal, but it does have the advantage that he seems to have released it (or rather, a revised 3rd edition) as a PDF.

This is probably a better link than the one in the previous post: http://www.cs.inf.ethz.ch/~wirth/

Sorry if this is off-topic (although the code in the book is not difficult to translate to FPC), but I thought I'd better post this as a correction, in case there'd be legal-type questions about copyright and such.

Frank

Frank Peelo wrote

There's also "Compiler Construction" by Prof. Wirth, Addison-Wesley, 1996, ISBN 0-201-40353-6. It describes a subset of Oberon, rather than Pascal, but it does have the advantage that he seems to have released it (or rather, a revised 3rd edition) as a PDF. The original link I found was

Excellent resource, thanks for the link.

Regards,

Gerard.

I decided to go with Coco/R Delphi (http://tetzel.com/CocoR/). Has anyone managed to compile it with FP? There's a weird bug in StringTools.pas unit, which I think is a bug of FP.

There's only one unit in the uses clause, which is Graphics. After converting the source with Lazarus, compilation gives "circular unit reference between CocoAGI and StringTools".

I try removing StringTools from CocoAGI uses clause, now it gives another one "circular unit reference between StringTools and Graphics".

Graphics doesn't have uses clause, so how could it happen?

In our previous episode, leledumbo said:

I decided to go with Coco/R Delphi (http://tetzel.com/CocoR/). Has anyone managed to compile it with FP? There's a weird bug in StringTools.pas unit, which I think is a bug of FP.

Start by renaming the duplicate unit names (at least crt and probably crc too) to something else.

Start by renaming the duplicate unit names (at least crt and probably crc

too) to something else.

Thanks, Marco. Just as I thought, that would be the problem. It compiles fine now.
But shouldn't the compiler message be more informative? I usually get "duplicate unit found" or something, which IMO should be the correct one.

3. Handwritten Question: Need some references other than Jack Crenshaw's book Pros: Easier to maintain (someone said, but no prove) Cons: I don't have any practical background on this

I have written a very simple Pascal to Java-bytecode compiler. It compiles a very simplified Pascal.

I did it handwritten because that's what the professor wanted.

It's documented in portuguese, but here is the link in case it helps:

http://p-tools.svn.sourceforge.net/viewvc/p-tools/fpjava/

My professor uses Wirth notation for the gramatics