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.