newRPL: Alpha demo 0.9 released [UPDATED 2017-10-25]

[Claudio L.]

(08-26-2017 07:29 PM)The Shadow Wrote:  That's not a bad idea. (Just out of curiosity, why 'pi0' instead of just 'pi'?)

It's not a constant per se, but a command that returns the value of pi to twice the system precision. Only needed temporarily to verify how the trig functions were working (when angles are passed close to pi, you need pi to twice the system precision to get any significant digits from the difference), so I didn't want to call it the same as an actual pi constant. Then I never removed it, though it might eventually be removed when the actual constant pi is implemented. Consider it a temporary patch.

(08-26-2017 07:29 PM)The Shadow Wrote:  By the way, I accidentally discovered that half-space or whatever it's called on AH-SPC. It's very nice-looking when used as a digit separator in SETLOCALE! Much better than the comma, and takes up less space too. It has tripped me up a couple times when programming, though. It looks close enough to a space that it's not an obvious issue.

It's the default separator of the fractional part, but looks good anywhere. I read somewhere that ISO recommends using the Unicode Thin Space character as digit grouping, so I did. And yes, it's bound to Alpha-hold-space, we need to put that in the wiki.

(08-26-2017 07:29 PM)The Shadow Wrote:  Thinking back, both times this happened, the variable was being used in the test part of a WHILE loop.

Like, in the more recent case I had:

WHILE n p / <blah> REPEAT <blah> 'n' STO <blah> END

The n in both places got changed to INVALID_COMMAND. When I tried to retype in the n's, I got an 'Invalid word' error.

Both times, it happened in a long program, multiple flow structures deep, and only on the innermost structure. (Which, as mentioned, was a WHILE in both cases.)

Ahhhh, then there's no memory corruption anywhere! That's good news, no bugs in any command, but the compiler itself. It seems something in your code threw off the decompiler's variable name tracking.
Long story: The first time you do LSTO or create locals with -> << >> the compiler creates the variables and track their names. Next time it finds the name, it doesn't include the name but a special GETLAM/PUTLAM style opcode. The decompiler needs to do the reverse: It analyzes the binary code and tracks the names of the variables you create, so when it finds those weird PUTLAM/GETLAM opcodes it decompiles them as the actual variable name. It seems you hit a case where the decompiler is losing track of the names somehow, so it couldn't decompile the GETLAM into anything, leaving an INVALID_COMMAND in its place.

** EDIT: Could you find a specific piece of your code that fails consistently? a test case would help a lot **

The "Invalid word" is a different story, it's only generated when compiling symbolics, when no library wanted to accept a certain token. For example, you get it when you introduce an invalid character in a symbolic, like double quotes:

'MYFUNC"' --> Invalid word

In this case, MYFUNC" is an invalid name for a variable, or function, or command, hence called a "word", I'm all ears if you can think of a better error message than "invalid word".
Sometimes if you don't close the ticks on a variable name and starts compiling your code as a symbolic you might also get an invalid word error.