Segfault that disappears when the debugger is turned on. You know what that means. I forgot to initialize something in my constructors.

We did it, feddit!

And just 14 lines over 500. Now I have some cleanup to do.

The best thing about this is that the build process is:

gcc *.c -o ../fool

Anyway, now I have to write an actual compiler, rather than emitting bytecode from the guts of the parser.

For the record, if I could have merger the lexer inside and have a monstrous lexer-parser-compiler, I would have.

Turns out I don't and I can keep my franken-compiler online until I need other stuff, like variable name resolution, type deduction and all the other good stuff you need a syntax tree for.

Also I might as well use one of my trash domain names to setup a gitea with the code for this damned thing.

Now you can peek at the horrible horrible code I've hacked upon this past week, at

https://templeoferis.com/trickster/the-fool

For today I want to add floats to the mix, right now it can only evaluate ints. And I have 2 ways of doing it:

1. Make the base value of the VM a tagged union so that every values carries runtime type info with it so that ops like ADD or MUL can check what the common denominator type is and coerce before executing the operation.

This means dynamic typing, for now; but when I eventually start writing a syntax tree and doing types anyway, I will have a head-start on the `var` type.

2. Generate an actual syntax tree that can be walked in order to resolve at compile time which coercions need to be done at which point and just emit bytecode that does it.

This also means that after adding ops that do int->float and float->int I can keep all of my other ops clean, specialized and devoid of dynamic guesswork.

I'll probably go with #2.

The parser to syntax tree bit is done. Next is syntax tree to bytecode.

And then finally I can add a supplementary step between the two, the type checker, that will actually mark each node with a type and allow me to add floats.

Now the compiler's done and I'm back where I started from. In order to show something new, I wrote something to disassemble the code object.

Now I'm missing a lot of error handling. I should probably add some flags to the binary to get it to spit out the syntax tree or disassembly instead of just jury-rigging it in `main.c`

I was also missing running code from a file, oopsie, that's done now.

Took me the whole week but I finally added floats.

This was a biggie because I added a new pass to the backend. After parser, the syntax tree goes through the type checker, which deduces what type each and every expression has. This includes intermediate ones:

For example:

300 / 9 + 60 * 2

is checked as:

(+::float
(/:: float
300::int
9::int)
(*::int
60::int
2::int))

And yes, 300 / 9 comes out as a float, I also snuck in integer dvision as //

The other big change was in the VM, now we obviously have operations to handle floats, but, we also need conversion operations.

Ops expect their inputs to be of certain types. For example 10 + 3.0 requires that 10 is promoted to a float in order to execute ADD_FLOAT.

Here's the same example from the previous post, 300 / 9 + 60 * 2, being compiled and run:

Now, the plan for this weekend is to add booleans, logical operations and, time permitting, strings, that won't do much for now except concatenation and interpolation.

Ugh, recursive descent parsing is such a pain in the arse when you have a lot of levels of precedence. Might switch to Pratt parsing.

I added a Pratt parser. Shockingly, it worked on the first try after compiling. Even though I had to fill up a gnarly function-pointer filled table to use it.

@trickster Quantum computer invented. Gotta notify the scientists.

@trickster collecting useless domain names seems to be a leading hobby this days

@trickster i think i let most of the stupid ones expire
image.png

@trickster
Flawless

@trickster looks good but where's the 69? where's the 420? doesn't seem very scientific to me without "god's numbers"