constexpr evaluation, or at least very fast code.
No I wrote it from scratch in c++ except vector/string/map/regex from std. I considered using a parser generator briefly but I wanted to do the fun parts myself to learn so I had to figure out the tree traversal and recursive descent parsing myself which I hadn't done before, hence the pain.
Just c interpolation for now and ever (probably), which itself isn't finished yet but it can generate function/struct definitions. If I ever want to go beyond that I might do an llvm backend first and see how that works as I've never written an optimizing compiler and have minimal assembly experience, but I want it to be tightly integrated with c so generating c code text and letting gcc/clang/whatever do the heavy lifting should be enough. It's all up in the air until I have a fully working prototype soon(tm)
My old compilers from my uni days involved a lot of
strtok and migraines.
What's the advantage over just making three functions for neutral element, composition, and inverse that satisfy certain relations?
So, by the nature of groups, these mappings are bijections and pure, which means that they lend themselves to some very clean optimizations. I also think formalizing the concept is useful. A lot of programmers use group theory mechanisms without realizing it, and I think making it more explicit could improve code design
function go_left=(pos,amount) => {pos.x=- amount}
function go_up=(pos,amount) => {pos.y=+amount}
Type DirectionOp= (name,action,conditional)
enum movement<DirectionOp> = {(LEFT,go_left,left_button_down),(UP,go_up,up_button_down)}
for (temp in movement){
if(temp.conditional){
temp.action(pos,1)
}
}So is the core idea having an explicit, immutable set of mappings between objects at compile/runtime? If so, you could probably pull that off with something like Go's
interfaces.
You're not going far enough, you also need to replace "int" with "commutative ring on Z_n".
Pretty much. Logically speaking,
element.operation <=> resultElement