Nov 02, 2018

What do you think?

Doing testing on closures. This also makes my head hurt.

What do you think this will print?

local t = {
    bar = 100
    f = function() {
        print(this.bar)
    }
}

t2 <- {
    bar = 200
}

t2.f <- t.f

local r = {
    bar = 1000
    function do_call(f) {
        f()
    }
}

r.do_call(t2.f)

Now with Answers

Well, not answers in the definitive truth of the universe way...

If you compile and run this code in Squirrel, the answer is 1000. This surprised me a little. I was expecting 200, but would have taken 100. As I build this new compiler, being some-what compatible with Squirrel is important, since I have a shit-lot of code already written in Squirrel that needs to run in the new compiler.

My new language (called Dinky, btw) is about 90% syntactically compatible with Squirrel, but subtile functionality like what 'this' means might be more important since it can fundamentally change the nature of the game's scripting code I've already written.

I don't think I've ever written anything as convoluted as the last function call shown, so it might not be important to adhere to, and instead treat 'this' more conventionally. I do wish I knew what the philosophy behind Squirrel's notion of 'this' is. I'm hesitant to just change it and miss some genius buried in why it works that way it does.

Currently my compiler and interrupter produces the same output as Squirrel and I'll probably stay with that until I understand the 'why' a little better.

I've spent three weeks on the new compiler and am now ready to move it over the my new game and start using it. I figure it will take a good part of this week to get the game fully functional under the new compiler and back to where I was with Squirrel.

Oct 29, 2018

Unit testing ternary operators...

...in my compiler makes my head hurt.

i = 1 ? 2 : 3
Assert(i == 2)
i = !1 ? 2 : 3
Assert(i == 3)
i = !1 ? 2 : 3 ? 4 : 5
Assert(i == 4)
i = !1 ? 2 ? 3 : 4 : 5 ? 6 : 7
Assert(i == 6)
i = 1 ? 2 ? 3 : 4 : 5 ? 6 : 7
Assert(i == 3)
i = 1 ? !2 ? 3 : 4 : 5 ? 6 : 7
Assert(i == 4)
i = 1 ? 0 ? 3 : 4 : 5 ? 6 : 7
Assert(i == 4)
i = 1 ? !2 ? 3 ? 4 : 5 : 6 : 7 ? 8 : 9
Assert(i == 6)

Any others I should test?

Oct 25, 2018

Casting Values

I have a scary Halloween story to tell you...

I was running into a bug in my new compiler where large ints where loosing precision. After tracing through my compiler's C++ code for about an hour trying to catch the spot, I came to this function:

int intConstValue() { return _type == kFloat ? _float : _int; }

It took me a bit of starring and then it hit. Something from the deep recesses of C-lore came jumping up.

Do you know the issue?

I won't keep everyone in suspense...

The both sides of trinary operator must return the same type, and in this case I was returning an INT and a FLOAT, so it cast the INT to a FLOAT before returning the value. I didn't notice it until one of my units tests sent large INT's through, larger than a FLOAT can store without loosing precision. Since the function (intConstValue) is returning an INT, I guess I assumed the it would downcast the float, but you know what they say about assuming.

I seem to recall being bitten by a similar bug 20 years ago. I guess I'm good until 2038... just in time for Unix time roll over.

Much like the Vulcan Pon farr, every seven years I am compelled to write a compiler.

Next