This week I wanted to get back to my pet Sinatra clone–Shatner. Last time I tried working on it, I was trying to figure out how to get views working like they do in Ruby. I want to end up with a dsl like this(gist):
Where you can call edb :view_name just like you call erb :view_name in Sinatra, and it figures out what you want.
I tried to do this by injecting a call to the def_edb macro into the class’s AST node. That didn’t work. Because def_edb was getting expanded before the outer macro, instead of passing it a proper AST node representing a method name, I was passing it an Unquote, which it didn’t know what to do with.
This looked like a rather difficult thing to untangle, so I gave up on it for now and file a bug (#152).
I moved on to fixing some bugs.
I made a quick list of four boogs that looked promising
- #110 ICE with an empty block
- #108 closure generation
- #109 incorrectly attaching macros to the wrong node type
- #123 ICE from methods that have same name as previously defined macro
#110 ICE with empty block
Somewhere the AST node for the body of the block was being set to nil. This caused some later code to blow up when it attempted to iterate over the block’s children. I fixed it by ensuring that the body of a block is always set to some value.
I looked at some pretty interesting bits of the compiler while fixing this. Did you know that Mirah’s block support works in two ways? You can use it like you would in JRuby, and pass a block in place of an interface implementation, which is cool. And, you can also pass it a block that contains the definitions of the methods you want to implement. For example (gist)
#108 closure generation
I was able to reproduce this, and figure out roughly what’s going on, but haven’t fixed it yet. The problem is that we’re not generating the signature of the method a block passed as an interface correctly all the time. When the block has no arguments, but the method it’s supposed to implement does, Mirah generates a method with the same name but no arguments. Problem.
#109 incorrectly attaching macros to the wrong node type
I reproduced this but didn’t look into it. It’s interesting it only happens when the macro is used somewhere else in the code.
#123 ICE from methods that have same name as previously defined macro
The problem here was that a macro’s return type is InlineCode, and the MethodDefinition node didn’t know how to validate it’s own signature against a macro with the same name. I put in a condition that will cause inference to fail with an error that says the method has the same name as a macro. It’s not particularly elegant, but I don’t think it’s a bad thing for the compiler to do.