Threaded Mode | Linear Mode

Claudio L. · 05-20-2014, 05:38 PM

While developing newRPL I stumbled upon this "feature" on the 50g:

According to the AUR:

Quote:Evaluating Local Names
Local names are evaluated differently from global names. When a global name is evaluated, the object stored in the corresponding variable is itself evaluated. (You’ve seen how programs stored in global variables are automatically evaluated when the name is evaluated.)
When a local name is evaluated, the object stored in the corresponding variable is returned to the stack but is not evaluated. When a local variable contains a number,the effect is identical to evaluation of a global name, since putting a number on the stack is equivalent to evaluating it. However, if a local variable contains a program, algebraic expression, or global variable name — and if you want it evaluated — the program should execute EVAL after the object is put on the stack.

So, with global variables, for example I write:

Code:

4 'X' STO 'X' 'A' STO 'A' 'B' STO

Then doing:

Code:

'B' EVAL

Should EVAL B, but per the AUR, the contents of B will be evaluated, which evals to 'X' which will in turn be evaluated and give 4 as a final result. This works as expected.

Now doing:

Code:

'X+1' 'A' STO 'B' EVAL

Should EVAL B, which gives 'A' and its contents evaluated 'X+1' = 5.
But the symbolic is NOT evaluated, resulting in 'X+1' on the stack. Pressing EVAL does indeed return the expected 5. Why is the EVAL not executed automatically?
Are there some objects for which auto EVAL is disabled? Is this documented anywhere?

Thanks for the help.
Claudio

kakima · 05-21-2014, 06:05 AM

I believe it's documented in the passage you cited: "When a global name is evaluated,..." (emphasis mine).

In your first example, 'X' is a global name (object type 6) and thus is evaluated to give 5. In the second example, 'X+1' is an algebraic (object type 9) and thus is not evaluated automatically.

Claudio L. · 05-21-2014, 12:51 PM

(05-21-2014 06:05 AM)kakima Wrote: I believe it's documented in the passage you cited: "When a global name is evaluated,..." (emphasis mine).

I disagree with your use of ellipsis... can we also use the rest of that same sentence?

Quote:...the object stored in the corresponding variable is itself evaluated.

That would mean 'X+1' has to be EVALuated too, no?

Claudio L. · 05-21-2014, 01:30 PM

I found the answer in the EVAL section of the AUR:

Evaluating a global name causes the following effects:

Quote:Calls the contents of the variable:
• A name is evaluated.
• A program is evaluated.
• A directory becomes the current directory.
• Other objects are put on the stack.
If no variable exists for a given name, evaluating the
name returns the name to the stack.

So the statement

Quote:... the object stored in the corresponding variable is itself evaluated.

is not accurate. Only names, programs and directories are evaluated. I wonder why this specific behavior. Why not EVAL everything? Most objects would push themselves on the stack anyway, and if you don't want it EVAL'd just use 'VAR' RCL instead of VAR. It would be more consistent to have one behavior for all object types.

For example, the function y=x, and y=k*x, written as:

Code:

'x' 'y' STO

or

Code:

'k*x' 'y' STO

Even if we define k=1, then y will return the value of x in one case, or the algebraic 'k*x' in the other. Only if 'x' is undefined it works consistently.
But changing this would wreck most existing code, so I guess we have some thinking to do before making a decision.

Claudio

kakima · 05-21-2014, 03:39 PM

Okay, I think I see your point about my ellipsis.

The key phrase is "... the object stored in the corresponding variable is itself evaluated" where, as you point out in your later post, the evaluation depends on the type of the object. Algebraics clearly fall into the "Other objects are put on the stack" category.

As to why this is so, instead of the algebraic getting evaluated, the only thing that pops to mind at this time is to be consistent. Putting an algebraic onto the stack does not cause it to be evaluated, whether it was just typed in or recalled from a variable. But that's just a theory, since I had nothing to do with the development of RPL.

Claudio L. · 05-22-2014, 09:31 PM

(05-21-2014 03:39 PM)kakima Wrote: Okay, I think I see your point about my ellipsis.

Yeah, I meant it as a joke, since you cut the sentence just when it was starting to get interesting!

(05-21-2014 03:39 PM)kakima Wrote: The key phrase is "... the object stored in the corresponding variable is itself evaluated" where, as you point out in your later post, the evaluation depends on the type of the object. Algebraics clearly fall into the "Other objects are put on the stack" category.

As to why this is so, instead of the algebraic getting evaluated, the only thing that pops to mind at this time is to be consistent. Putting an algebraic onto the stack does not cause it to be evaluated, whether it was just typed in or recalled from a variable. But that's just a theory, since I had nothing to do with the development of RPL.

I don't know the reasons, but I suspect speed of execution being the cause, so they don't try to evaluate trivial things like numbers.
In any case, I think from the perspective of a user trying to learn the language, it's better to give one rule for all cases: "when a name is evaluated, its contents will be recalled to the stack and evaluated", doesn't matter what type of object, and also doesn't matter whether it's a global or local. Then if you want the content to be recalled but not evaluated, then just use RCL.
The question now is whether this will cause a nightmare to port programs from userRPL to newRPL, or if this will be acceptable.

Claudio

kakima · 05-24-2014, 03:30 AM

Of course, if you want one rule for everything, there's the devil's advocate viewpoint: "When a name is evaluated, its contents will be recalled to the stack." Then if you want the object evaluated, just use EVAL.

(I'm not saying this is better, just pointing it out.)

Either way will break some existing code, though I don't know whether it would reach nightmare proportions.

Didier Lachieze · 05-24-2014, 11:02 AM

(05-20-2014 05:38 PM)Claudio L. Wrote: Are there some objects for which auto EVAL is disabled? Is this documented anywhere?

Thanks for the help.
Claudio

Chapter 3 "Objects and Execution" in Bill Wickes book "HP 48 Insights - Part 1: Principles and programming (G/GX edition)" should provide you some of the rationals for the current implementation, and the difference between execution and evaluation (section 3.3).

In particular, from section 3.5.2 page 53:

Quote: The ability of algebraic objects to act as data when executed, or as programs when evaluated, is one of the foundations of the HP 48's ability to perform symbolic mathematics.

A lot of thought has been put in the HP RPL implementation and I would be very cautious when deciding for a different implementation.

David Hayden · 05-26-2014, 10:09 PM

Note that global and local identifiers behave differently when they don't exist also. If you execute a global that doesn't exist, the calculator pushes the ID on the stack. If you execute a local that doesn't exist, it generates an "undefined local name" variable.

I'm with you, Claudio: I don't see a reason why it works the way it does.

Dave

Claudio L. · 05-27-2014, 01:43 PM

(05-24-2014 11:02 AM)Didier Lachieze Wrote: In particular, from section 3.5.2 page 53:

Quote: The ability of algebraic objects to act as data when executed, or as programs when evaluated, is one of the foundations of the HP 48's ability to perform symbolic mathematics.

A lot of thought has been put in the HP RPL implementation and I would be very cautious when deciding for a different implementation.

I am being cautions, otherwise I wouldn't even bother asking...
Regarding the quote from the book: it's not quite the same. I understand not evaluating the algebraic object when it's being executed:

Code:

<< 'x+1' >>

Should simply push 'x+1' it on the stack, otherwise you can't do anything symbolic. Then when EVALuated it behaves as a program, which we are in 100% agreement. The question goes not so much to the behavior of algebraic objects, but the behavior of EVALuating or not the content of a variable, when it's name is used unquoted in a program.
The big problem with the current approach is that it impacts expandability of the new language.
Using a simpler approach, either "EVAL the content regardless of type", or "RCL the contents to the stack", allows user libraries to add custom objects in the future, and provide consistent behavior.
If you add a special behavior based on type to something as basic as evaluating a variable, then you'd have to define specialized treatment of any new object type. In other words, to add a new object you need to hack into very old code.
Perhaps the solution would be to have 2 separate overloadable operators: EVAL and autoEVAL. EVAL is when the user uses the EVAL command, and autoEVAL when a variable contents are EVAL'd. But this makes writing libraries to add new objects more complex.

To innovate or not to innovate, that is the dilemma...

Claudio

Claudio L. · 05-27-2014, 02:14 PM

(05-26-2014 10:09 PM)David Hayden Wrote: Note that global and local identifiers behave differently when they don't exist also. If you execute a global that doesn't exist, the calculator pushes the ID on the stack. If you execute a local that doesn't exist, it generates an "undefined local name" variable.

I'm with you, Claudio: I don't see a reason why it works the way it does.

Dave

We need to come up with a specification of the behavior we want and stick to that. I think we should either EVAL everything or RCL everything, and whatever breaks, breaks.
The EVAL approach: Will work on most objects the way we are used to, but will break symbolics.
The RCL approach: Will work on most objects the way we are used to, but will break programs.
I think it's more important to have programs in a variable being executed automatically than algebraics recalled unevaluated.

Claudio

Didier Lachieze · (This post was last modified: 05-27-2014 02:33 PM by Didier Lachieze.)

Well I’m not an expert in RPL, but today if I do:

Code:

'X^2' 'A' STO

'X+1' 'B' STO

2 'X' STO

Then executing << A B + >> returns 'X^2+(X+1)' not 7 as it would with your proposed change if I understand it correctly. This seems to be a quite significant change of the symbolic operations.
I will let RPL gurus (and I know there are a few on this forum) provide more inputs.

EDIT: Btw, do you know how this is done in RPL/2?

RMollov · 05-27-2014, 02:36 PM

So your innovation would lead to << 'B' EVAL >> EVAL and << B EVAL >> EVAL to give the same result? I'd rather have it as it is.

Claudio L. · 05-27-2014, 02:39 PM

(05-27-2014 02:23 PM)Didier Lachieze Wrote: Well I’m not an expert in RPL, but today if I do:

Code:

'X^2' 'A' STO 'X+1' 'B' STO 2 'X' STO

Then executing << A B + >> returns 'X^2+(X+1)' not 7 as it would with your proposed change if I understand it correctly. This seems to be a quite significant change of the symbolic operations.
I will let RPL gurus (and I know there are a few on this forum) provide more inputs.

Didn't think about that one. You are right, if we EVAL everything you'd have to write:

Code:

 << 'A' RCL 'B' RCL + >>

Not the end of the world, but not very elegant either. Perhaps we could introduce a syntax for RCL and a syntax for EVAL of a name. For example, VAR@ could mean RCL, while VAR could be EVAL.
So your example would be:

Code:

<< A@ B@ + >>

Of course, doesn't have to be the @ symbol, can be something better.

RMollov · 05-27-2014, 02:54 PM

(05-27-2014 02:23 PM)Didier Lachieze Wrote: Well I’m not an expert in RPL, but today if I do:

Code:

'X^2' 'A' STO 'X+1' 'B' STO 2 'X' STO

Then executing << A B + >> returns 'X^2+(X+1)' not 7 as it would with your proposed change

And << 'A' 'B' + >> returns 'A+B', and both return 7 on the second EVAL. Should both return 7 on the first EVAL?

Claudio L. · 05-27-2014, 03:47 PM

(05-27-2014 02:54 PM)RMollov Wrote:
(05-27-2014 02:23 PM)Didier Lachieze Wrote: Well I’m not an expert in RPL, but today if I do:

Code:

'X^2' 'A' STO 'X+1' 'B' STO 2 'X' STO

Then executing << A B + >> returns 'X^2+(X+1)' not 7 as it would with your proposed change
And << 'A' 'B' + >> returns 'A+B', and both return 7 on the second EVAL. Should both return 7 on the first EVAL?

On the other hand, if B=X:

Code:

<< A B + >>

gives 'X^2+2' instead of 'X^2+X'

Didier Lachieze · 05-27-2014, 03:53 PM

A general comment about New RPL: in a previous thread it was defined as providing “UserRPL” source code level compatibility with HP RPL and as having specifications based on RPLMAN.DOC. It seems you are moving away from this initial objective.

(Chapter "2.4 Execution" of RPLMAN.DOC covers the details of object execution and evaluation).

Claudio L. · 05-27-2014, 04:31 PM

Well, on the same thread we also mentioned that it is not the intent to replicate every obscure quirk of the existing system. Compatibility will be preserved the best we can, but per my last post, X=2, A=X^2, B=X, A+B=X^2+2, is this something worth replicating?
It should be either X^2+X (proper algebraic manipulation) or 6 (completely evaluated), I agree with both ways to some point, but the existing way is not the right way in my opinion.

We'll think long and hard before breaking anything, but honestly, those quirks shouldn't be there...

Claudio

Claudio L. · 05-27-2014, 09:02 PM

I feel like a complete fool. Why should I bother if some old programs break?

I just found this:

Quote:Due to some specific issues resolved, certain user programs may not run on the new system without changes first.

Guess where? In the latest update for the HP Prime. If they can break code on a product they just released (not even 1 year old), then we shouldn't worry too much about breaking code compatibility.
Keep that sentence in mind, and we'll code a consistent language that breaks with old habits.

Claudio

**rprosperi** · 05-27-2014, 10:55 PM

(05-27-2014 09:02 PM)Claudio L. Wrote: If they can break code on a product they just released (not even 1 year old), then we shouldn't worry too much about breaking code compatibility.

Claudio

I think the key issue here is that there are many 10's of thousands of 50g RPL programs in use in many, many disciplines and (I assume) you're hoping to get as many of those folks to use newRPL as possible; absolute (or as close as is feasible) compatibility is by far the best feature to achieve that goal.

The Prime, as you say less than a year old, has (IMHO) FAR fewer programs in actual use, so the impact is dramatically smaller; also it being new, changes and improvements are expected (or should be) and it's quite likely the early adopters making Prime applications are following these changes and adapting their apps to accomodate.

Don't misunderstand me, I totally see your point and agree with your core issue, but I think you're comparison isn't aplicable between newRPL and Prime.

In any case I am looking forward to trying out newRPL when ready, however you choose to go with key decisions (like the EVAL issue discussed herein).

Is any level of SysRPL (e.g not including any assembler) likely to be supported? Things like CST custom menus go a long way with a little bit of SysRPL support.

Thanks