Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!decwrl!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!a.cs.uiuc.edu!p.cs.uiuc.edu!johnson From: johnson@p.cs.uiuc.edu Newsgroups: comp.lang.smalltalk Subject: Re: Language Processing Applications Message-ID: <80500036@p.cs.uiuc.edu> Date: 15 Jul 88 14:10:00 GMT References: <36094@linus.UUCP> Lines: 14 Nf-ID: #R:linus.UUCP:36094:p.cs.uiuc.edu:80500036:000:834 Nf-From: p.cs.uiuc.edu!johnson Jul 15 09:10:00 1988 Smalltalk is great for writing recursive descent parsers. A parser is a class, and each rule of the grammar becomes a method. You can derive a new parser from an old one by inheritance. We use this to good effect in our Typed Smalltalk compiler, and have about six different parsers within a common framework. The original Smalltalk compiler was broken into two, one that compiled methods and the other that compiled and evaluated expressions. They had virtually the same grammars, but the second one had a different environment for looking up a name. I had a student write an LR parser generator for a class project. Except for speed problems, it seemed very suitable. There were classes for grammars, rules, and parsers, where a parser was given a grammar when it was created and built the appropriate tables for itself.