a type bug

[Han]

(11-30-2015 10:42 PM)ji3m Wrote:  So a string functions like LEFT ("abc",2) is not a cas function.

So i cant check the return type unless i know it apriori.?

I do not understand the question. Why would you expect LEFT() to return anything except a string? So in this particular case, yes, you already know the type a priori as LEFT() is a documented command.

(11-30-2015 10:42 PM)ji3m Wrote:  If 'type' is not a cas function then what could possibly be used
in a program that would return DOM_STRING..when given
a string.??

It is quite bizzare to me that just asking a mechanical question
like type of would evaluate anything. I can see that CAS () evaluates
but what exactly is the point of having a function 'type'?

Lower-case "type" _IS_ a CAS function. In HPPPL, upper/lower case does not matter. Type, TYPE, type, tYpE are all interpreted as the TYPE() command -- the non-CAS variety. To access the CAS type() command, you can use CAS.type(). However, when called from non-CAS HPPPL programs via CAS.command(arg) the argument arg can either be a non-string expression, or an expression in the form of a string. Perhaps a better example would be the solve() command.

In CAS view, one could type solve(x^2-1,x) to get the solution (note the lower-case x). However, one cannot simply type CAS.solve(x^2-1,x) within an HPPPL program, because the expressions x^2-1 and x must be resolvable. So in order to feed the expressions x^2-1 and x (as is) as arguments without evaluation, we have to use the other option, which is to encapsulate them as a string: CAS.solve("x^2-1", "x") -- or even CAS.solve("x^2-1,x").

Thus, when using CAS.command(arg), 'arg' itself must be either completely resolvable (because we are in HPPPL land), or it must resolve to a string (or comma-separated strings). And if it is a string, then the expression inside the string is used as the actual argument from the CAS view (this is how to pass "symbolic expressions" as arguments; it also has to do with the way LOCAL variables and CAS interact per the discussion in your other posts). In your example, if 'abc' had been a variable containing a string, you would have gotten DOM_STRING. However, since 'abc' likely did not exist as a variable, this is why you got DOM_IDENT.