|Book - Parsing with Sandstone's Visual Parse++ (2001) firstname.lastname@example.org (Quinn Jackson) (2017-09-17)|
|From:||Quinn Jackson <email@example.com>|
|Date:||Sun, 17 Sep 2017 06:58:44 -0600|
|Injection-Info:||gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="10802"; mail-complaints-to="firstname.lastname@example.org"|
|Posted-Date:||18 Sep 2017 01:52:42 EDT|
In 2001, I was commissioned to write a book that would guide
technologists using SandStone's Visual Parse++ product through the
process of writing parsers using that tool. I have been given
permission to place this book on ResearchGate, and I do so with the
hope that it will, despite its specificity to the Visual Parse++ tool,
be useful to parsing enthusiasts in general.
CHAPTER ONE - Introduction to Parsing
This chapter introduces some of the general theory and background a
developer should have to make working with Visual Parse++ a more
manageable experience. The theory behind parsing is really not very
complicated, but many tools assume that the programmer has a
background in the concepts and terminology. After reading this chapter
and reviewing the concepts, the reader will be in a better position to
understand some of the most important terms and concepts of the field,
and will therefore be in a stronger position to start using Visual
Parse++ effectively. Readers who already have a background in parse
theory and terminology may wish to skim through this chapter to see
how the general theory applies specifically to Visual Parse++.
CHAPTER TWO - The Craft of Grammar Design
This chapter discusses some of the issues involved when a developer is
presented with a parsing task to be addressed using Visual Parse++. As
has already been discussed, LALR(k) parsing is a predictable
mathematical process, and the generation of a parser from a grammar
specification is carried out in a provably reproducible fashion;
however, the process of converting a loose language specification into
a suitable grammar can be considered as much of a craft as a science.
As with all crafts, the experience and insight of the craftspeople
involved in the process have considerable bearing on the outcome.
Given the same family of text to parse, it is entirely possible that
two different developers will produce two different Visual Parse++
specifications of the language. If both specifications accept the same
language, they are equivalent, but one of the two specifications may
be simpler to work with in everyday development. Moreover, one of the
specifications may be simpler for a third party who was not directly
involved in the grammar's development to modify if the specification
CHAPTER THREE - Writing a Parser from the Ground Up
This chapter applies many of the concepts introduced in the previous
chapters and steps through writing an actual parser from an informal
specification. This example case will be framed as a tiny language
required by a software development company (let's call it YoyoDyne
Inc.) for which the reader is assumed to be a developer who has been
asked to design and implement a parser using Visual Parse++ and
Microsoft's Visual C++ 6.0 (Professional) development environment.
Once the primary issues of this project have been discussed, the
project, well on its way, is left as an exercise for the reader.
The book may be found here:
Quinn Jackson SMIEEE FRSA
Return to the
Search the comp.compilers archives again.