Why not just do a VLIST on the program and look at the compiler-generated object code to see what's actually going on?

I'd do it but don't have access to a UV machine...



It is not how the compiler deals with the information but how the runtime
engine deals with the data.
I have demonstrated the runtime engine types the data based on how it is
entered in the source code.
A = 1 is typed as a numeric by the runtime engine and A = "1" is typed as a
string. In an earlier
post I provided the following proof.

TST 0001 DEBUG 0002 A = 1 0003 A = "1" 0004 STOP
TST: 2: A = 1 :: S TST: 3: A = "1"
:: A/ INTEGER: 1 :: S TST: 4: STOP :: A/ STRING: T r L=1 `1' ::

The program simply sets the variable A to 1 or "1" and when run it goes in
to debug mode.
I then stepped through each line and displayed the contents of the variable
A by typing A/ as you can
see the runtime engine reports each line as INTEGER or STRING depending on
how the data was entered in the
source code.


-- Stewart Leicester | http://www.ThreatFocus.com V.P. Engineering | mailto:[EMAIL PROTECTED] Threat Focus, Inc. | 925-551-0130 Voice "Knowledge is your best defense" | 509-695-1373 Fax -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users

Reply via email to