- Log in to post comments
User bio
404 bio not found
Member since Feb 2, 2016
Posts:
Replies:
The initial value of x=14 in the above ugly example happened because I ran it 3 times while I has debugging and modifying it. As the comment says, I originally did quit y+3 but I had to change it to quit x+3 because the second execution of the quit statement got an <UNDEFINED> *y signal before it got to the <COMMAND> signal.
- Log in to post comments
As mentioned above, ObjectScript was originally based on ANSI MUMPS. However, that ANSI standard has been retired but I believe there still exists an ISO M language standard which is identical to the ANSI M[UMPS} standard. ObjectScript still supports the ancient MUMPS/M standard but InterSystems no longer documents many of the legacy features of MUMPS/M.
There is no warning for a QUIT with expression statement in a FOR loop because it is possible that a QUIT expr could be legal in a FOR loop and that legality/illegality cannot not be detected until run-time.
Here is a messy example containing both legacy M and modern ObjectScript. It contains a quit x+3 statement that is legal when first encountered and illegal when encountered the second time.
InterSystems supports ugly legacy M features so customers do not need to rewrite ancient code. New code should not look like this ugly example as avoiding certain legacy features is strongly recommended.
USER>zp
foo(a,b)
for i=1:1:10 {
set x=$$foo2(a) zw x
goto foo3
foo2(y)
foo3 set z=a
zw a,x,y,z
zw "about to quit y+3"
quit x+3
}
USER>zw $$foo(5,9)
a=5
x=14
y=5
z=5
"about to quit y+3"
x=17
a=5
x=17
z=5
"about to quit y+3"
quit x+3
^
<COMMAND>foo3+3^foo
USER 6f2>
Note that <COMMAND> was signaled 3 lines after label foo3 and then we interactively get a prompt from the debugger.
BTW: Evgeny might ask strange questions but the properties of legacy M/MUMPS can be much weirder.
- Log in to post comments
Certifications & Credly badges:
Steven has no Certifications & Credly badges yet.
Followers:
Following:
Steven has not followed anybody yet.
The %ToJSON() method of the %DynamicAbstractObject classes in the ObjectScript languageshould never generate NaN without quotation marks. Although a %DynamicAbstractObject subclass can contain IEEE double-precision floating-point values including the special values Infinity and NaN, using %ToJSON on a %DynamicObject or a %DynamicArray that contains such special values will result in an <ILLEGAL VALUE> error signal since the JSON standard does not support such special IEEE floating-point values. It is possible some applications have extended the JSON standard to include NaN and Infinity as numeric values without quotation marks, the ObjectScript %ToJSON method does not support such an extension. However, @Julius Kavay did give an example how the ObjectScript ZWRITE command will display a %DynamicObject entry containing an IEEE NaN value.