[GoLUG] A tad bit pricey!

[Steve Litt]

Kyle Terrien said on Mon, 4 Dec 2023 21:11:59 -0800

>On 12/3/23 14:27, Hendrik Boom wrote:
>> On Fri, Dec 01, 2023 at 01:29:21AM -0500, Steve Litt wrote:  
>>> And whether or not you get that course, you should attend the coming
>>> GoLUG meeting to learn the basics so you're not starting from
>>> scratch.
>>>
>>> SteveT  
>> 
>> Here's a compiler book that I like:
>> 
>> Modern Compiler Design
>> by
>> Dick Grune, Henri E. Bal, Cerial J.H., Jacobs and Koen G. Langendoen.
>> 
>> I have the first edition.  I gather there has been another edition
>> since.
>> 
>> -- hendrik  
>
>While we are on the topic of books, I located a historical source that 
>you may find interesting:
>
>* Brian Kernighan & Robert Pike, "The Unix Programming Environment", 
>Prentice Hall, 1984.
>
>This book may be hard to find, but if you can get a copy, take a look
>at chapter 8 (Program Development).  This is a whirlwind guided tour
>on how to use lex and yacc to progressively develop a domain-specific
>language, in this case a four function calculator called hoc.

Hi Kyle,

I think my part of the presentation at tomorrow night's GoLUG meeting is
a critically vital prerequisite to reading your book's Chapter 8, or
Lexx & Bison by Levine, or the vast majority of books and online docs.
It's definitely a prerequisite to David Billsbrough's presentation,
which is much more technical than mine.

My presentation discusses tens of key understandings that are necessary
to learn or code any kind of Flex=>Bison compiler or converter. Without
these key understandings, other documents are ambiguous and often
incomplete, and without these key understandings one cannot fill in the
blanks for the missing information, even with exhaustive web search and
experimentation. With these key understandings, coding a Flex=>Bison
compiler or converter becomes a linearly discoverable process.

I'll give you one key understanding right now: The Flex=>Bison
representation is a mislead. It's not the case that the Flex scanner
runs and passes its information to the Bison parser. You cannot have
the Flex scanner's stdout feed the Bison parser's stdin and expect
anything productive. Rather than two distinct modules, they're more
like conjoined twins with a very thick interface: Perhaps one heart and
four legs. Or in the case of Flex and Bison, they share token constants
declared in the Bison program, and often a custom yylex() function from
the Flex scanner. Only one of them produces an executable and has a
main() function; the other is just a library. Usually the Bison derived
Parser has the main() function, and that's what I'll present tomorrow
night.

There are many other key understandings necessary to work with the
thick interface between the Flex derived scanner and the Bison derived
parser. I gained these key understandings through two weeks of
exhaustive web search, ChatGPT sessions, and brutal experimentation,
most of which was dead-end. Just this morning I completed a working
Flex/Bison Hello World. I predict that armed with this I'll be able to
create my promised blankline delineated text file to HTML tagged
paragraphs in an incremental process. Whether I'll be able to do it in
time for tomorrow's meeting is up for debate, given that I need to
rewrite major portions of my presentation to account for a bad dead end
I went down.

If you're at all curious about lex/yacc or Flex/Bison parsers, in order
to be able to learn anything at all you need to be at tomorrow night's
meeting.

SteveT

Steve Litt 

Autumn 2023 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21