Add optional mutable keyword about millfork HOT 3 CLOSED

Currently, const is reserved for compile-time constants only, there's no language support for what Java calls final variables (variables that are ever assigned only once), but if I add it, I won't call it "const", I want const to remain really const.

I did some measurements on my Millfork projects and it turns out between 29 to 45% of local variables are final, which means 55 to 71% of them would have to be marked as mut.

Anyway, it's not as easy as just adding a new keyword. There are few roadblocks before Millfork gets final local variables:

• currently, there is only one scope per function and variables cannot be defined within a compound statement, only at the function's top level

• local variable declarations cannot contain any initialization, only constants and global variables can

so you have to write ugly things like

byte value1, value2
value1 = g()
if condition {
    value2 = f()
    // do some work with value1 and value2
} else {
    // value2 is still in scope here, uninitialised
    return value1
}

I think the rationale for that second rule was to avoid this thing from C:

/* these ones always return 1, barring threading issues in unoptimized code */
int const1a() {        int x; x = 0; return ++x; }
int const1b() { static int x; x = 0; return ++x; }
int const1c() {        int x = 0;    return ++x; }
/* this one doesn't */
int counter() { static int x = 0;    return ++x; }

One of the Millfork designs philosophies is "do it C way, unless the C way is ugly, then don't do it at all". Which is not adhered to at all times, but the lack of variable initializers, the dearth of unary operators, or restricted semicolons are all like that due to that philosophy. So is mutability by default, which is something you see in other languages for the same platforms, like Basic, Pascal, or Action.

So to summarise, in order to add the mut keyword, the roadmap should look like this:

• allow for declaring local variables with narrower scopes

• lower the count of mutable local variables by allowing for loops define their own counters (requires aforementioned narrower scopes)

• allow for memory overlap for variables declared in the same function, but in different, disjoint scopes

• allow for initializers in local variable declarations, either both static and non-static or just non-static (although it's actually the local static variables that need it more)

• figure out what to do with function parameters, as they are considered mutable right now

• measure the percentage of final vs mutable variables again

• look into new optimization opportunities (although the optimizer already handles final variables reasonably well enough)

• based on the results of the previous two steps, see whether it's worth it to mark all mutable variables explicitly or not

I'll revisit the whole mut idea when I'm done with the first four steps. The first three are something I'll definitely wanna tackle (I mean, lots of Millfork code is littered with byte i and then i is just used in one loop as a counter) regardless of everything else. But it won't be trivial.

Sorry for rambling, but it's gonna be a while before I can give a definite answer to your suggestion, so I wanted you to know why.

from millfork.

That's a very thorough answer! It's interesting to see the challenges, such as nested scopes, which I hadn't thought about. I'll be happy to wait until these are more fleshed out. I really appreciate what you're doing here, by the way. Millfork is really opening up 6502 development for me, which is something I was often reluctant to do in the past due to the lack of a performant high-level-ish language and the tedium of assembly compared to something like the Z80. Thank you for your thoughtful response and for your work on this project.

from millfork.

I'm closing it due to lack of any progress.

from millfork.