TRUE and #TRUE and 1 are the same speed.

This doesn't say anything about them being the same speed though. Perhaps when it occurs in DATA it's a constant, but maybe it's a "variable" otherwise. DATA is especially weird when it comes to constant-handling; it doesn't consider "AAA"*3 or similar to be a "constant expression." Some speed data would help you. I remember testing on the O3DS and they did appear to differ, but not to a degree that actually really mattered.

"AAA"*3 isn't a constant since only numerical expressions are pre-evaluated. For example, ?"A"+1 won't cause an error during precompilation since it isn't evaluated then, but ?1/0 will.

"AAA"*3 isn't a constant since only numerical expressions are pre-evaluated.

No reason this should be the case. If you're already optimizing numeric expressions, then you're already doing a bit more than static analysis and you could totally optimize this, I think. Could be wrong though. The expression is constant in the sense that its result never changes, unless you run out of memory, the 3DS sets on fire, the world ends or something else.

"AAA"*3 isn't a constant since only numerical expressions are pre-evaluated.

No reason this should be the case. If you're already optimizing numeric expressions, then you're already doing a bit more than static analysis and you could totally optimize this, I think. Could be wrong though.

I think the reason is that a numerical expression will always evaluate to something that takes up 32 or 64 bytes of memory, while a string expression can use a lot more. No reason to fill up the RAM with strings when you don't need to.

"AAA"*3 isn't a constant since only numerical expressions are pre-evaluated.

No reason this should be the case. If you're already optimizing numeric expressions, then you're already doing a bit more than static analysis and you could totally optimize this, I think. Could be wrong though.

I think the reason is that a numerical expression will always evaluate to something that takes up 32 or 64 bytes of memory, while a string expression can use a lot more. No reason to fill up the RAM with strings when you don't need to.

But strings inside the source are already heaped, aren't they? Why waste resources computing the string at runtime (potentially repeatedly) if they're most-likely going to end up being used anyway?

"AAA"*3 isn't a constant since only numerical expressions are pre-evaluated.

No reason this should be the case. If you're already optimizing numeric expressions, then you're already doing a bit more than static analysis and you could totally optimize this, I think. Could be wrong though.

I think the reason is that a numerical expression will always evaluate to something that takes up 32 or 64 bytes of memory, while a string expression can use a lot more. No reason to fill up the RAM with strings when you don't need to.

But strings inside the source are already heaped, aren't they? Why waste resources computing the string at runtime (potentially repeatedly) if they're most-likely going to end up being used anyway?

Because then you have to load ALL strings into memory for the entire time the program is running. You can prove this doesn't happen by doing something like:

END
A$="A"*10000000

removing the END causes an out of memory error, showing that string expressions aren't evaluated until they are reached

"AAA"*3 isn't a constant since only numerical expressions are pre-evaluated.

No reason this should be the case. If you're already optimizing numeric expressions, then you're already doing a bit more than static analysis and you could totally optimize this, I think. Could be wrong though.

I think the reason is that a numerical expression will always evaluate to something that takes up 32 or 64 bytes of memory, while a string expression can use a lot more. No reason to fill up the RAM with strings when you don't need to.

But strings inside the source are already heaped, aren't they? Why waste resources computing the string at runtime (potentially repeatedly) if they're most-likely going to end up being used anyway?

Because then you have to load ALL strings into memory for the entire time the program is running. You can prove this doesn't happen by doing something like:

END
A$="A"*10000000

removing the END causes an out of memory error, showing that string expressions aren't evaluated until they are reached

Assuming the code literals and heap are stored in a different space, this isn't as bad a problem. IIRC some basic bytecode structures have a notation like

LITERAL STRING
VALUE
END

or something to that effect, which push the value to the stack or heap or whatever. It DOES inflate your bytecode size though.

(I'd like to point out that I'm not arguing about whether it's a GOOD idea so much as whether it actually HAPPENS in SB)