+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: Bug? accessing LOCAL var in shared scope (/thread-2550.html)
Bug? accessing LOCAL var in shared scope - lenborje - 12-03-2014 10:37 PM
I have been using LOCAL vars declared outside the programs, to get the equivalent of variables shared between routines in the same program, but not exported globally.
There is something strange going on whenever I try to use these variables as function arguments; they are not accessed at all. I always have to copy them to a local variable first. Example:
Code:
LOCAL foo=[[1,2],[3,4]];
EXPORT GlobalVarIgnored()
BEGIN
PRINT();
PRINT(foo);
PRINT(colDim(foo));
LOCAL bar=foo;
PRINT(bar);
PRINT(colDim(bar));
END;I would expect both PRINT(colDim(foo)) and PRINT(colDim(bar)) to print out same number (2), but instead the output of the program is:
Code:
[[1,2],[3,4]]
colDim(foo)
Error: Bad Argument Value
[[1,2],[3,4]]
2(Discovered in 6030; confirmed in 6940.)
RE: Bug? accessing LOCAL var in shared scope - Snorre - 12-03-2014 11:42 PM
Hello lenborje,
I think you shouldn't use LOCAL outside functions.
To my knowledge there are 3 types of variables:
a: LOCALs inside functions: only accessible and existent within the function.
b: global (in program context) but not EXPORTed: only accessible within the program, but keeping their value even if the program is left (a kind of private vars).
c: EXPORTed: accessible from everywhere and also keeping their value.
The first type has to be declared inside a function, the last two types have to be declared outside functions:
EXPORT c;
b;
myFunction() BEGIN LOCAL a; END;
Type b variables are a nice feature to preserve some program state without polluting the variable menu and without having to fear the user or another program may accidently set them to an invalid value.
Greetings
(sorry, English is not my mother tongue)
RE: Bug? accessing LOCAL var in shared scope - lenborje - 12-04-2014 07:15 AM
(12-03-2014 11:42 PM)Snorre Wrote: I think you shouldn't use LOCAL outside functions.
I get the same error even if I leave out the "LOCAL" on the declaration of "foo".
Your "global" variable kind is exactly what I'm trying to achieve, i.e. variables local to the program, accessible to all its routines, but not exported to other programs.
RE: Bug? accessing LOCAL var in shared scope - Snorre - 12-04-2014 10:58 AM
Sorry. My fault. You're right. Now it seems to me as a bug too.
RE: Bug? accessing LOCAL var in shared scope - Han - 11-12-2015 04:22 PM
Sorry to dig up an old thread.
This is an issue related to CAS commands and the separation of Home and CAS views. They (CAS commands) currently can only see local variables inside HPPPL (i.e. non-CAS) programs, not ones declared outside. Even EXPORTed variables don't always behave as expected (referencing an entry inside a matrix using square brackets, for example, comes to mind).
RE: Bug? accessing LOCAL var in shared scope - StephenG1CMZ - 11-18-2015 06:19 PM
May not be relevant but should
Local foo equals ... =
Be
Local foo assignment :=
Or are these equivalent?
RE: Bug? accessing LOCAL var in shared scope - cyrille de brébisson - 11-23-2015 06:19 AM
Hello,
The local in the global scope of the program is optional (it is the default, EXPORT is a must if you want to export however).
= and := in variable creation are absolutely equivalent.
so, the syntax is (if my memory on syntax writing is correct):
[LOCAL|EXPORT] name[[:]=expression][, name[[:]=expression]]+;
Cyrille
RE: Bug? accessing LOCAL var in shared scope - lenborje - 11-23-2015 08:10 AM
Cyrille,
may I ask if you have some insight on my original question in this thread?
Best regards,
RE: Bug? accessing LOCAL var in shared scope - cyrille de brébisson - 11-24-2015 07:49 PM
Hello,
Yes, the problem, as explained to some extend by Han is that the CAS is not local or program aware.
To access a local (as is function local), or program global variable (exported or local), the CAS would need to know what program/function is running. Which it does not because the Home/Cas interconnection is not 'that great'.
The result is that you can access from the CAS a program exported variable (because the CAS can find it), although it is dangerous because if you have 2 programs that export a variable with the same name (remember, they are still 2 variables in this case), then the CAS might pick any of them (actually, the one from the first program in the list...) but can not find a function local or program non exported variable.
Now, in order to try to 'hide' the problem as much as possible for 'non advanced' programs, when you call a cas function from a HPPL function, if they are any function local variables in the arguements, they will be replaced by their values, but this does not happen with program globals (maybe it should)...
One of the issue is that HPPL never knows when the cas need symbolic data or value data when it is called, this makes it fairly hard to know/guess what the user wants to do.
Cyrille
RE: Bug? accessing LOCAL var in shared scope - lenborje - 11-24-2015 10:26 PM
Thank you for the explanation.
I must add that what confused me in Han's hint was that I did not understand what CAS had to do with it.
I understand now that colDim is a CAS function. This was not immediately apparent to me.
Are all functions with mixed case names CAS functions, or is there some other way to distinguish between CAS and "normal" functions?
RE: Bug? accessing LOCAL var in shared scope - cyrille de brébisson - 11-25-2015 06:35 AM
Hello,
As a general rule, lower case function are CAS function. UPPERCASE functions are home functions. When CAS and HOME share a function, to allow HOME/CAS compatibility, CAS will also use uppercase.
The above is mostly legacy from the 38 series times.
Home later on added more functions which are often Mixed case (because it's more modern and nicer).
As a general rule, HOME functions are NOT case sensitive TeXtOuT will be recognized. CAS does accept some functions in both UPPERCASE and lowercase form, but never using a random mixed case. But they are some exceptions :-)
Most Mixed case functions in home are in fact app functions, not 'main' functions.
Hope that this does help.
Cyrille
RE: Bug? accessing LOCAL var in shared scope - lenborje - 11-25-2015 07:55 AM
Well, at least I understand I must be more careful in order to avoid CAS functions.
(I thought I had to prefix them all with "CAS." when called from HOME.)
You learn something new every day.
Thanks,
RE: Bug? accessing LOCAL var in shared scope - cyrille de brébisson - 11-26-2015 06:38 AM
Hello,
the CAS.name syntax is only necessary if there is a conflict with a home function.
for example CAS.sin will call the CAS sin from home. sin would call the home sin.
But when a function exists only in cas, you can call it directly.
Cyrille
RE: Bug? accessing LOCAL var in shared scope - Dirk.nl - 11-26-2015 12:24 PM
Hi Cyrille,
Thank you for your explanation about Home and CAS variables.
You write about; general rule, CAS/Home share functions, mixed cases, some exceptions, most mixed case functions, app/main functions, etc.
I have read more threads about Home/CAS functions/commands. I think it is still confusing, specially for me.
My question is; which of ALL functions are specially for Home, which are for CAS, which are the same for Home and CAS and what are the exceptions?
As an example:
SIN for Home and sin for CAS.
In the catalog you can only select SIN in uppercase and not in lowercase. My simple conclusion is that SIN in uppercase is a Home function, but you can also use it in CAS but you must type in lowercase and that is not selectable in the catalog.
Proposal:
Don't use a general rule but use a straight forward rule with no exceptions; everything in uppercase are Home functions and everything in lowercase are CAS functions.
So, implement in the catalog also sin in lowercase, do this for all other (shared) functions.
Do it consistently/logically, then you have never questions about which are Home and CAS functions (I hope).
Implement also other hidden functions in the catalog.
Thanks!
RE: Bug? accessing LOCAL var in shared scope - Marcus von Cube - 11-28-2015 11:58 AM
(11-26-2015 12:24 PM)Dirk.nl Wrote: As an example:
SIN for Home and sin for CAS.
The function used depends on the environment from where the catalog is opened. While in CAS, sin() is returned to the command line. If you insert π in the parentheses and hit ENTER you get SIN(π) in the history and 0 as the result.
The rewriting to uppercase looks a bit strange but the zero result proves that the CAS.sin function is called.
RE: Bug? accessing LOCAL var in shared scope - Dirk.nl - 11-28-2015 06:22 PM
Hi Marcus,
When I select the catalog in CAS, I see SIN in uppercase. Conclusion, it's a Home function, but maybe yes or no, after selecting it, it will be copied in lowercase to the command line. New conclusion, if you are not be sure if it is also a CAS function, try to copy it to the command line!
I have used length() in a Home program, it was not copied in uppercase, but it works in my program! A lowercase CAS function that works well in a Home program without CAS. before the function!
I think that the difference (maybe not the good word for it) between Home/CAS is not consistent enough. Request to HP; make this more clearer!!