Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1918
| From | Quinn Jackson <thothic.quinn@gmail.com> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Book - Parsing with Sandstone's Visual Parse++ (2001) |
| Date | 2017-09-17 06:58 -0600 |
| Organization | Compilers Central |
| Message-ID | <17-09-013@comp.compilers> (permalink) |
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 changes. 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: https://www.researchgate.net/publication/319851057_Parsing_with_Sandstone%27s_Visual_Parse -- Quinn Jackson SMIEEE FRSA
Back to comp.compilers | Previous | Next | Find similar | Unroll thread
Book - Parsing with Sandstone's Visual Parse++ (2001) Quinn Jackson <thothic.quinn@gmail.com> - 2017-09-17 06:58 -0600
csiph-web