Book: Lex & Yacc

I picked up a copy of Lex & Yacc off TradeMe the yesterday, and I’m quite excited.

I’m hoping it will help me get my head around parser writing, for my still to-be revealed side project…

For a while now I have been working on a side project to add editor support for Erlang in Visual Studio.

I have a Google Code project for it, and it currently has syntax colour highlighting, but I was getting stuck with writing othe parser.

This is where the project has stalled over the last few months as I have been reading lots.

Originally I was basing my work on Lua Langage Pack for Visual Sudio. This package is a C# based plug-in that uses the CSTools project by Malcolm Crowe.

With the help of Code Project documents, MSDN and Blogs I slowly got a plug-in that has colour highlighting working (if you run it in the debug Visual Studio).

I was also reviewing how the IronPython project does it’s parser, but that used seemed to use python to do some parsing.. so

I then was trying to get Antlr to work, via AntlrWorks, but was banging my head on the debuggers limited support.

The next problem was how do I actually define the grammar for Erlang.

Erlang ships with a  grammar defined in yecc, it’s version-thing of yacc.  So I started translating this to Antrl but was getting left-right recursion errors, even though the problem was not the standard definition of left-right recursion problem.  Yecc is recursive decent as Erlang does recursion so well, but this was not playing well with Antlr. I then discovered I was looking at a subset of the Erlang gramma, and the full yecc gramma was huge, so hand translations was not an option.

So I then found the yecc grammar for yecc, and thought that I could hand roll a C# recursive decent parser for yecc, which would allow the auto-writing of a proper grammar for CSTools. But I wasn’t so keen on the .dll dependency of that tool chain.

I started reading the dragon book (Compilers: Principles, Techniques, and Tools) around this time, so was starting to get my head a little better positioned.

I then stumbled on to the Irony project which is a Visual Studio language development framework.  Eek they have most of what I was trying to workout how to-do, mostly worked out. But they have their own lex and yacc like tools.  This project also refers to the Visual Studio’s lex and yacc tools called MPLex and MPPG (distributed in the Visual Studio SDK)

I have just found that the newer version of the Lua project for Visual Studio 2008 uses the Irony project, and is hosted on CodePlex.

So I was getting keen again to work out how to use lex and yacc correctly, thus why when I saw this book for $3, I bid and anxiously waited to se if I’d win.  Of the 19 counted page view on the auction, 17 were mine.

So I’m half way through the first chapter and have just realised I don’t need to write a hand parser of yecc, I just need to write a lex parser that translates yecc to yacc, and rebuild that with MPPG to get a C# Erlang parser that is not hand rolled. Which means if the Erlang language changes, I can just re-run the whole process on the new gramma, and still be compliant.

New old books

The Christchurch City Library had their annual book sale on a few weekends ago.  I popped along, as it was held at the same venue I swim at each day.

The book sale is a two day event, and I actually went three times, first before my swim at 1pm, then again one hour later at 2pm and the last time on the Saturday at 1pm with my family.

The first visit was crowed, and the hall was full of trestles covered in books, one hour later half the books were gone, and the next day half again were gone. It was quite amazing, and also incredibly dirty feeling running your hand over the books to read the titles, while everybody else was doing the same thing.

poplAnyway, I picked up two books Programming C# 4th Ed by Jesse Liberty, because it was $2 and it never hurts to have a good reference book.  The other was Principles of Programming Languages 3rd Ed by Bruce J. Macleannan, as I really have been enjoying language/compiler books recently. Principles is a really good history of and why to it is that way type of book. A great read.

Why you lose at bridge

I have recently taken-up studying bridge, and picked up Why you lose at bridge at a second-hand book sale for $1.

My first running joke was “I lose because I don’t play”, but jokes aside, it was a great read, even 63 years after it being published.

The book is aimed at experienced players, offering insight to common mistakes in bidding and game play.  It was interesting jumping ahead of myself, as  I have only read a beginners guide a couple of times, and the subtlety of the bidding signals seemed over the top, but after reading how the hand is played out, and how the inferences are used to guide play, I’ve become motivated to learn correct bidding.  Bridge feels very similar to Preference or 500, just with a mind boggling large set of signaling bids and plays.

Much learning ahead, but I’m excited…

The Black Swan

Michaela bought me The Black Swan by Nassim Nicholas Taleb for Christmas. The Black Swan - Cover
It was a perspective changing book. I loved it.  Buy it, read it, now!  I’ll wait…..

Right, so now we are in the same head space, wasn’t it just great!  Just like it’s back cover says, The Impact of the Highly Improbable.

I loved the concept that it only takes 1 black swan to prove that All Swans are White is wrong, yet you can never prove it’s correct.  I loved how he expands this idea to show how most people’s concept of risk management is really sticking your head in the sand and hoping for the best.  As they do not manage the risks (the impacts) but use tiny probabilities to feel happy that it won’t happen (short term thinking and looking out for the quarterly/yearly bonus).

Another section that strike me quite personally, was how we cannot forward project.  One example he uses, is that when thinking about buying a new car you get excited about how grand it will be, yet you fail to remember feeling that way about your current car, and you fail to project the loss of that feeling going forward.  So tying that to me, as a software developer. When you get someone else’s code, and the first things you say is what were they thinking, where’s the documentation, it’s all spaghetti.

Yet I fail to see how my grand vision of perfect code, done correctly, will be compromised due to time constraints, or prioritised by business value add. Or how there will be bugs in other sub-systems, needing ugly work around code. I’ll be rushed off my feat, and thus not document it, ever, and when asked to, I’ll ask documents (which will ages quickly) or bug fix, and you know what will win. And that’s how it is, because of the scale of software we are developing, and how we are part of a bigger company, thus need to be profitable and resources are limited (as the really should be). So I give myself all the credit of plans, and saying it’s alright to shortcut here, I’ll fix it later, but all my predecessors were muppets, that had no vision, and wrote unreadable code!

So my current mental track is to try forgive others, as I hope to be forgiven myself.

I enjoyed this book enough, that as I was reading it, I was already looking forward to reading it again, as I couldn’t recall all the things that made me go – da, now you point it out!, but it sure happened a lot.  Michaela got tired of me excitedly recalling (poorly) the book to her!

Wikipedia’s The Black Swan page is quite a good summary.

Paradigms of Artificial Intelligence Programming – Finished!

I’ve finished reading Paradigms of Artificial Intelligence Programming: Case Study in Common Lisp. On the whole, the book was a slog (bought it 4 months ago), just like its name. A top quality slog, but reading large chunks of Lisp while not taking the time to enter each program and getting a feel for how it “works” was hard.

The historic perspective and evolutions of early AI programming was fantastic. I loved the section on natural grammar/parsing, and the impact of how you store your ” model data” impacting how you can process the input, made a lot of sense. Before reading that section, I had spent a few nights grappling with how I wanted to parse text, and how I’d store my knowledge and I was getting mentally caught up in the chicken – egg of it all, so it seemed very timely after that to read how it was really tricky (Chapter 14 – Knowledge Representation and Reasoning).

Now that I have read the book, and gotten an overall comprehension of what it covers, I look forward to using it as a reference for learn Lisp and for fundamentals of AI development.

One of my takes one the whole Lisp front, is that it is really nice the idea of not having to have every thing strongly typed up front. Seeing how solutions organically evolve is quite a strong argument for dynamic languages. I also really liked how functional composition stacks blocks of doing together to make a greater whole.