littlelogs

More work on my #go parser/compiler today. I can now parse function calls, the last rule left in my minimal grammar that’ll let me make an MVP. Woo! The next step will be to actually start turning the AST into Go code.

Unfortunately I also discovered a bug in the parser library I’m using. Someone else had already submitted an issue about it last year, and the project author replied, “I’m not using this for my own work any more, sorry, you’re on your own.” I get that, but it’s still frustrating that I’ll now have to understand and fix his code to proceed with my own.

I did some more work on my #go parser/compiler yesterday, getting everything organised a little better. I hadn’t touched this for weeks previously, because the scale of all the syntax I want to support felt so huge I didn’t know what to do next. But this week I realised I don’t need to support all syntax up-front — I can parse and compile a subset, enough to build some toy examples, and keep iterating in this way with more parsing rules until I can parse and compile the whole language to Go.

I think the only thing left before I can work on compiling this minimum viable language is supporting function calls. Hopefully I’ll find some time to get them happening soon.

Did some more work on my #go parser today. PEG rules are really confusing me as the recursion is a lot harder to follow than using the EBNF style as implemented in rply, and parser library’s error messages are just useless. So I spent a long time going around in circles trying to work out why some new rules didn’t work. In the end I emerged the victor, though, so on top of previous rules I have if/else if/else blocks working now too 😊

Made some more progress with #go parsing today. It’s lucky that I get a kick out of seeing basic syntax parse correctly because that’s still all I’m up to! I’ve got operator precedence set up correctly, I can assign things to other things, and I can define functions that take arguments and contain statements.

Wrote some more #go today as I start to build my parser for a higher-level language built on Go. I’m thinking (but don’t hold me to this) that I’m going to copy Reason’s syntax as much as possible. #Ocaml but with a more C-like syntax should work well if I can make all the concepts work in Go.

Anyway, I made more progress this time, thanks to reading some examples grammars, so I feel like I’m slowly getting a handle on PEGs. So far I’m just building up the various types of literals, then I’ll start working on more complicated stuff like assignment statements and so on.

So recently I decided I was officially giving up on porting Rply to #go. Porting was helping me understand the language, but it wasn’t that fun and I was really only doing it so I could get to the point where I could use it. That’s the fun part.

So I decided instead to use an existing parser called Pigeon that implements PEG (Parsing Expression Grammars) which boils down to a weird combo of lexing and parsing, with slightly different rules that can use lookaheads and stuff. I tried to implement a basic calculator example with it tonight and eventually understood it enough to build something non-trivial. Progress! Looking forward to writing some actual source code grammar and beginning a new language project.

Did a bit more work porting rply to #go this afternoon. Now I’m into building the parser things are getting tricky. #Rply is also barely commented at all so it’s often hard to follow. Also because #python is dynamic, there are no types for anything! So I have to be the human type inferrer. It’s been a bit frustrating working out what type a variable is (or what a dictionary holds) when I can’t see the raw values going in.

Remember I was going to try writing a language (either #braid, or something Braid-like) that compiles to #go? I decided that I should learn Go a bit more thoroughly before getting stuck into that, and I also wasn’t keen on using yacc for the parsing stage — it’s really old, and has a weird syntax. So why not combine the two and start by porting rply (rpython lex yacc, a modern implementation of those tools) to go? At first I thought this wouldn’t be a huge undertaking, and then of course I realised how little I knew. But tonight I got the lexer finished and working! It didn’t take too long at all. 🎉

I grappled with Go a little bit, but didn’t have huge problems. It’s mostly pointers I have to really think about. I agree with those who say the core language is easy to pick up, although I think people conflate (at least I did) “modern” with “high-level”. It’s really not high-level 😐 but that’s why we’re writing a language on top of it, right?

Maybe tomorrow I’ll start porting the parser.

Remember my toy language #braid? I’ve been thinking a lot about making something similar that compiles to #go. Go has a lot of benefits, like good concurrency primitives, fast GC, cross-platform compilation, but it lacks some niceties like algebraic data types and generics. Maybe I could write a language that provides these and compiles to go, so it can take advantage of its benefits too, like the many interesting languages that compile to javascript. I’m not sure I can actually implement what I have in mind, but I’m curious to try, just for fun.

Today I got some simple lexing set up using a package called lexmachine. Next I’ll be learning to use yacc so I can plug the resulting tokens into a parser. Small steps.

Wrote about implementing #protocolbuffers in #Go and #JavaScript: http://davewalk.net/2015/08/31/protocol-buffers-in-go-and-javascript.html

Reading about using #go as a shared library you can access from #python (with very little overheard in python 3, too). Even goroutines work. Seems like a nifty way of combining python with some more performant/concurrent code where needed. https://blog.filippo.io/building-python-modules-with-go-1-5/

Only tonight found out that #go has no support for default arguments. Look at the crazy shit you have to do to emulate them: http://joneisen.tumblr.com/post/53695478114/golang-and-default-values yuck.