HP PPL compiler big, nasty, hairy, smelly, creapy BUG!

[veeblefester]

Thanks to Han we now know how to do indirect addressing on the HP Prime.

There is a bug in the HP PPL compiler that causes a syntax error during runtime but not during Edit Check.

This compilation error occurs in the code line EXPR(varptr + ":=" + var1);

Read ALL the comments in the code below.

With regard to Han, he either has some great inside connections to HP
or he is HP or he is the Grand Imperial Poobah of all things Prime.

I do not care which.

Many thanks to Han and the stuff between his ears.

See the thread "Indirect addressing in HP PPL. Is it possible?"

Code that brings about indirect addressing follows. Again, read ALL the comments.
Including the comments imbedded in the code.

****************************
// The following code performs indirect addressing if var1 is a real, integer or symbolic such as π (pi). Does not work if var1="string", you get a syntax error during 'Run' BUT NOT DURING 'Check' in Edit. Read the comments in the code lines for the work around by Han to this HP PPL compiler big, nasty, hairy, smelly, creapy BUG.
//
// The syntax error is caused by line EXPR(varptr + ":=" + var1);
//
// It is curious that the compiler is allowing this syntax during compilation but not allowing it during runtime.
//
EXPORT SYMBOL1,WHATTYPE;
EXPORT Indirect_Addressing()
BEGIN
LOCAL var1="why",varptr;
INPUT(varptr,"Variable Name","Varnam=","In quotes, enter the var name","A");// Key in "SYMBOL1".
TYPE(var1)▶WHATTYPE;// Even though TYPE == 2 (string)
IF TYPE(var1)==2 then var1:=STRING(var1); end;// this line is needed to prevent a syntax error
EXPR(varptr + ":=" + var1);// by this EXPR(varptr + ":=" + var1); line.
END;
****************************

Han, thanks again for your help.

I hope that your efforts and contributions in HP's launch of the Prime are recognized by HP.

[Thomas Klemm]

(01-10-2014 09:59 AM)veeblefester Wrote:  EXPR(varptr + ":=" + var1);

I have no idea what I'm talking about, but the string in var1 probably needs quoting:
EXPR(varptr + ":=\"" + var1 + "\"");

Could be something else as I'm not familiar with HP PPL:
EXPR(varptr + ":='" + var1 + "'");

At least thats my understanding why using a number in var1 is fine but a string is not.

HTH
Thomas

[patrice]

If the bug is so easy, simplify your code !

Code:

EXPORT Indirect_Addressing()
BEGIN
EXPR("A:=9");
END;

is enough code. Either it bug or not, everyone can tell if you made a mistake or not.
replace "A:=9" with your own expression

Quote: he is the Grand Imperial Poobah

Me Great Mamamouchi of Prime

[Han]

There is no bug. The problem was that you never initialized varptr so it defaulted to a real type. Then, when you entered in the name SYMBOL1 without double quotes, the program used the value of SYMBOL1, which was zero as it too was not initialized. Thus, when it executed EXPR(varptr + ":=" + var1) what it was executing was essentially the command: 0:="why" -- which is why you are getting the error. On the other hand if you used double quotes around SYMBOL1 then the INPUT() complains about invalid types.

Please pay careful attention to what I wrote earlier in the other thread (not sure why you needed to start a new one): "...type G for the varname (no need for double quotes since varptr was initialized to be a string)" Since you did not initialize your pointer variable to a string (even an empty one), this is the issue.

Code:


export SYMBOL1;

export indir()
begin
  local varptr="", var1=""; // noticed that both are initialized to an empty string

  input(varptr,"Variable name","Varname=","Enter the var name", "A");
  input(var1,"Variable value",varptr + "=","Enter the value to save",var1);
  if TYPE(var1)==2 then var1:=STRING(var1); end; // ensure double quotes for var1 preserved
  expr(varptr + ":=" + var1);
end;

NOTE: INPUT() generally expects the user's input for varptr (and var1) to be of the same type as varptr (and respectively var1) just prior to executing. That is, if var1 is a real number, INPUT() will expect the user to enter a real number. This is why we pre-initialize the variables to empty strings. If you decide that strings are not what you want, you can change the type prior to running INPUT() by simply using a dummy value (e.g. var1:=0 if you want a numeric value).

[veeblefester]

Han, if this is not a bug then why the following unnecessary line

IF TYPE(var1)==2 THEN var1 := STRING(var1); END;

This line is saying if var1 is ALREADY a string (type 2) go ahead and convert it
to a string ANYWAY so the following EXPR line will work!

If this is necessary, this IS a bug that needs a work around.

Somebody tell me this is wrong.

Note: BOTH varptr and var1 were being input as strings.

[veeblefester]

Patrice, thanks for your feedback.

Your line EXPR("A:=9"); is doing nothing more than assigning the value 9
to the reserved HOME Real variable A.

The line has nothing to do with indirect addressing.

There is no pointer in your code that points indirectly to a variable!

[Han]

(01-10-2014 11:42 PM)veeblefester Wrote:  Han, if this is not a bug then why the following unnecessary line

IF TYPE(var1)==2 THEN var1 := STRING(var1); END;

This line is saying if var1 is ALREADY a string (type 2) go ahead and convert it
to a string ANYWAY so the following EXPR line will work!

If this is necessary, this IS a bug that needs a work around.

Somebody tell me this is wrong.

Note: BOTH varptr and var1 were being input as strings.

Even if varptr and var1 were input as strings you would not get a valid input from INPUT() if you did not also initialize varptr and var1 to strings prior to executing INPUT(). If you CAREFULLY look over each instance of your code posts, you will see where the errors on your part are. If not, I can always quote your code and highlight it in bold for you.

It is NOT a bug because you need to account for the fact that you are "adding" strings. The command EXPR() takes a string, and converts it into a command as if typed from the command line without the container double quotes. So, if you would normally type:

SYMBOL1:="this is a test"

then the string that needs to be fed to EXPR() must look like:

"SYMBOL1:="this is a test""

Do you notice the "extra" set of double quotes that appears around the right hand side of the word 'test' ? If you simply do:

"SYMBOL1" + ":=" + "this is a test"

then all you get is

"SYMBOL1:=this is a test"

which when executed from the command line, would look like:

SYMBOL1:=this is a test

and undoubtedly result in an error. The point of the STRING() command applied to an object that is already a string is to insert an "extra" set of double quotes, since the overloaded operator + will strip the outer set of double quotes in such a manner that the final result will only have the far outermost double quotes.

I don't think I can explain it any more basic than that.

[veeblefester]

Thomas Klemm, thanks.

I think you underestimate what you know.

Your first line produced a syntax error.

However, your second line
EXPR(varptr + ":=' " + var1 + "'");
showed some promise.

The second line, stored indirectly, the contents of var1 in
the variable pointed to by the contents of varptr.

The problem with the second line you submitted was that it
stored the var1 contents string as s*t*r*i*n*g.

That is to say, there was an asterisk between each charactor
of the string because of the way it was being parsed.

A minor tweak of your EXPR line produced the desired results
without the compiler bug workaround work around line of
IF TYPE(var1)==2 THEN var1 := STRING(var1);END; before the EXPR line.
This line is saying, if var1 is ALREADY a string then go ahead and convert
it to a string ANYWAY! This is a bug work around.

The tweak of your line that eliminated the asterisk between each
charactor is:

// This performs indirect addressing.
EXPORT SYMBOL1="wrong";
EXPORT Thomas_Klemm()
BEGIN
LOCAL varptr="SYMBOL1",var1="right";
EXPR(varptr+":="+'"var1"');
END;

This allows varptr to be constructed and point to
SYMBOL1, SYMBOL2, SYMBOL3...
That is to say, indirect addressing.

Many thanks to Thomas Klemm.

This is a much simpler and more elegant solution than the bug work around.

[Han]

(01-11-2014 03:05 AM)veeblefester Wrote:  IF TYPE(var1)==2 THEN var1 := STRING(var1);END; before the EXPR line.
This line is saying, if var1 is ALREADY a string then go ahead and convert
it to a string ANYWAY! This is a bug work around.

EXPR(varptr+":="+'"var1"');

I don't get why you still insist on some sort of bug or compiler workaround. What exactly do you think the difference between effect of STRING(var1) and '"var1"' is? You are doing exactly the same thing. If anything, the '"var1"' (putting single quotes around a double-quotation of a variable that is ALREADY a string) is a hack because single quotes are delimiters for symbolic objects, as opposed to the STRING() solution. The STRING() command will add double quotes around any object, including strings. You need the extra set of double quotes because the addition operator + will strip the outer pair. Did you even read the explanation I gave regarding string addition? * palm to face *

Edit: Please humor me and type, in the command line, the following:

STRING("a string")

and post here EXACTLY what you see, including the exactly number of double quotes that show up in the result.

[veeblefester]

Han, I will stop calling it a bug.

The point is that the single line of code

EXPR(varptr+":="+'"var1"');

that came about because of the efforts of three members

Han, Thomas Klemm and a minor contribution by veeblefester

is a better, more elegant solution than

IF TYPE(var1)==2 then var1:=STRING(var1); end;
EXPR(varptr + ":=" + var1);.

With this solution to indirect addressing in hand

I am ready to start having some fun writing code for my app
on my new Prime.

Best wishes to all that helped me.

I am certain, that with no Advanced User Guide for HP PPL

you boys and girls will be hearing from me in the not

too distant future.

Happy coding from veeblefester.

[patrice]

Quote:Your line EXPR("A:=9"); is doing nothing more than assigning the value 9
to the reserved HOME Real variable A.

The line has nothing to do with indirect addressing.

There is no pointer in your code that points indirectly to a variable!

The EXPR line is something like the minimum code to exhibit a supposed bug.

What do you think your indirect thing is doing?
You forge an arbitrary string that is fed to EXPR, my arbitrary string is "A:=9".
That your string is a constant or that you build it on fly following any way you want, you end up with a string.

do you prefer ? Is it indirect enough for you ?

Code:

EXPORT Indirect_Addressing()
BEGIN
LOCAL Ptr, Value, Tmp;
Ptr:="A"; Value:=9; Tmp:= Ptr+ ":="+ Value;
EXPR(Tmp);
END;

[Han]

(01-11-2014 07:42 AM)veeblefester Wrote:  The point is that the single line of code

EXPR(varptr+":="+'"var1"');

is a better, more elegant solution than

IF TYPE(var1)==2 then var1:=STRING(var1); end;
EXPR(varptr + ":=" + var1);.

The single line of code which you think is elegant relies on what can be best described as a bug. Single quotes are for symbolic expressions. It would not be surprising to see your code no longer work upon the next firmware update. I cannot help but wonder whether you have truly understood the way the addition operator + has been overloaded to handle string addition, and in general the addition of two objects of different types.