Better (non-int) return values

On my list of annoyances in the code that I've been writing so far has been declaring all my functions as returning ints, because that was what worked. I just dug in and figured out what was keeping void functions from working correctly - turns out, all I needed to do was to do a ret_void() at the right places, and everything worked great.

I also thought that returning floats would require extra work, since I didn't have float support in the language until recently, and I figured there'd be something that'd have to pay attention to whether I was returning an int or a float, but the above code worked just great on the first time. Well, the second time, if you count the compiler catching a legitimate bug in the convert_rad_to_deg source code. But even that's a success.


In the "note to self" category, or maybe for people who are following these breadcrumbs, learning about the LLVM experience, when I was implementing const variable declarations, I banged my head against parsing errors - I was having a hard time parsing "const int x = 8;", for reasons that weren't making sense to me. I was thinking that there was some precedence issue, and the LALR parser was maybe not sufficient to parse the ambiguous grammar that I had built.

I ended up (after many other stabs in the dark) turning on the bit that prints out the output of the tokenizer, and I noticed that "const" was being interpreted as an identifier, not as the keyword. I moved "const" up in my list of tokens, nope, same thing. I added 'const' into my list of reserved words, and then things worked right.


Another note: as I was implementing "const", I began putting in support for function static variables - variables whose visibility is restricted to a function, but whose lifetime is for the length of the application. I haven't finished that, and it's not a priority, but I did notice that LLVM variables have a flag, so maybe it's as simple as detecting that qualifier on the declaration and setting the flag.


Next up: structures / classes / objects. This will make a significant improvement to the architecture of my Pong game, in a few ways.

• data modularity - I can have a 2d vector representing velocity, and refer to the velocity as a higher-level object, moving it around as a unit, rather than having to remember to move pairs of vx,vy.
• API cleanliness - the events coming back from SDL for keyboard events or mouse actions are complex things. They have an event type (e.g. keyboard event) and usually one or more pieces of data (e.g. what button is pressed, maybe modifier keys that are also pressed, like 'shift'). 

Being able to clean up the structure of the Pong game will make it substantially less gross for me to look at, which is really the point of that game - show me what I can't stand, and I fix it.