That is interesting. Regarding such OS change, however, would this affect compatibility with existing HP PPL programs?

Welcome to the forums, by the way

That is interesting. Regarding such OS change, however, would this affect compatibility with existing HP PPL programs?

As there hardly are any the more important question first: "would this affect compatibility with programs preinstalled?"

Except for the Graphing variables and the settings variables I don't see why any are predefined. As far as I can tell they serve no purpose whatsoever. This is what the Manual has to say:

You use Home variables to store
data that is important to you, such as matrices, lists, real
numbers, etc.

I don't get why I would want to do that.

Would it affect PPL programs? Yes. If the program used the variables while assuming they are of their respective types. For example an assignment L1:=1 now results in a list containing one element: L1={1}. This behaviour would change. If the type of L1 was initially undefined the same assignment would result in a variable of type real (I think) L1=1

Imho this is the more often expected behaviour.

Of course renaming all those home variables to chinese characters would make them rather useless (which imho they already are). So if someone from HP is reading this: How about instead add a button to create new variables in the VARS view? So that I can define my own variables "that are important to me"?
Also: Why do only variables created in the home view appear in the VARS view (some don't - something about that dialogue popping up), while some can only be found in the mem view?

We wouldn't need to replace the bootloader if it takes standard ELFs. Just load linux with it.

Quote

That is interesting. Regarding such OS change, however, would this affect compatibility with existing HP PPL programs?

As there hardly are any the more important question first: "would this affect compatibility with programs preinstalled?"

Except for the Graphing variables and the settings variables I don't see why any are predefined. As far as I can tell they serve no purpose whatsoever. This is what the Manual has to say:

Quote

You use Home variables to store
data that is important to you, such as matrices, lists, real
numbers, etc.

I don't get why I would want to do that.

Would it affect PPL programs? Yes. If the program used the variables while assuming they are of their respective types. For example an assignment L1:=1 now results in a list containing one element: L1={1}. This behaviour would change. If the type of L1 was initially undefined the same assignment would result in a variable of type real (I think) L1=1

Imho this is the more often expected behaviour.

Of course renaming all those home variables to chinese characters would make them rather useless (which imho they already are). So if someone from HP is reading this: How about instead add a button to create new variables in the VARS view? So that I can define my own variables "that are important to me"?
Also: Why do only variables created in the home view appear in the VARS view (some don't - something about that dialogue popping up), while some can only be found in the mem view?

The issue though is that if the calculator gets popular next school year when it comes out in brick and mortar stores (if ever), then many people who get or make programs will not ever know that there is a modified OS that no longer supports variables the way the official OS did and then share their programs. At the same time, some hardcore programmers who use the OS will release their own programs, flooding the web with programs compatible with only one OS at once. It doesn't matter if there aren't many HP PPL programs right now, as there could be many in the future. Basically, people will have to constantly install back and forth the unnoficial OS and official one in order to run everything they want.

I am personally making large programs for the HP Prime right now and I definitively don't want to have to re-write everything in one year when custom OSes start coming out. I already have one game out, HP Prime Tunnel, that uses L1 and A-Z variables. There are already around 20 programs on Hpcalc.org.

I think it would be best if there was some sort of emulator released that changes the behavior of the HP PPL interpreter or compiler or at least a program allowing you to dual boot. Even better: An OS that supports both syntaxes/type of vars.

Aren't those variables cleared on calculator shutdown, though?

Else, I guess that would be a good idea, assuming that this doesn't drastically increase my program file size. On the 84+ it was common practice to overwrite those predefined vars, though, since that's all we had, and nobody complained except a small minority. The issue right now is that almost every HP Prime program released so far are made by TI programmers and a lot of TI coders planned to get the calc to program it. Inevitably, a lot of programs will use those vars, since it's not considered bad practice on lower end TI models. Programmers will most likely carry those habits on the HP Prime.

That reminds me, is it possible to create permanent variables and lists that won't get deleted on program exit? I am asking, since I would like to make an adventure game with save feature.

is it possible to create permanent variables and lists that won't get deleted on program exit?

I read somewhere a couple of hours ago that matrices are indestructible and survive even resets

In a compiled language like C, all this work is done before the program ever launches

I recall Tim Wessmann talking about how the PPL is compiled before running and how the compiler is fast enough for there not being a point in saving the binaries. PPL is not an interpreted language.

My problem with the variables appears when using this calculator to do calculations. If it was just for programming it wouldn't be much of a problem since then I can just use long variable names - I'm typing on a PC anyways.

In CAS Mode however every character of the output counts because a line of the screen fills quickly. I can't just opt for R_n instead of Rn.And when you have both uppercase and lowercase variables should be used in the given task? I have to make up weird rules for picking variable names _all the damn time_ just because they are sitting there containing 0 {0}

• etc. in the Home Vars for no reason I can tell. At least all lowercase letters and their combinations with indices can be used. The uppercase letters however...

I'm not the only one complaining. Here's a post from hpmuseum: http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=256099#256099

HP: you've stolen my variables. By restricting where I can use lower or upper case variables, you've DESTROYED my work-flow. Equations require a combination of upper and lower case variables... what were you thinking?

Advanced users have no problems with "i am in charge of creating a variable". However, we have very strong feedback from lower end users and educators that having a set of predefined variables is very important and useful to them for many reasons.

Prime in its first release is not targeted directly at high end users. What was and wasn't in the first release was not targeted at the top 1% of users. If that messes up "your workflow" as was posted in that thread, and even the fact that someone is posting about calculators, pretty much by definition means they fall in that tiny power user minority.

Wow, if PPL is interpreted, then I guess that might explain why it's so fast lol.

Interpeted mean *slower*, not faster unless something is strangely wrong.

What happens is that since the compiler is so fast, the first time you use it then things are compiled for execution and will remain around until a power cycle.

It makes sense to have a system set of variables that can be transferred from program to program, but it would also be nice to have local-program variables. It seems like having both should be an option.