Evaluation of variables in 50g

[Claudio L.]

(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