ANSI X11.1-1995 M Considerations

ANSI X11.1-1995 M Considerations

As GT.M currently only supports the ANSI X11.1-1995 version of M/MUMPS, it doesn't incorporate extensions made to the standard by Intersystems.  As part of code convergence, some version have incorporated Intersystems extensions.  These must documented for resolution.

Greater than or equal to expression.

Cache Expression:  >=

ANSI Expression: '<

Less than or equal to expression.

Cache Expression:  <=

ANSI Expression: '>

 

The relevant part of the proposed standard is documented at:

http://71.174.62.16/Demo/AnnoStd?Frame=Main&Page=a107195&Edition=MDC

like0

Comments

Experiment with non-standard M operators

DAVID Whitten's picture
As an experiment, I wrote a test program named ZZTST which consisted of: ZZTST ;DJW/WV ;;1.0;Test XINDEX;****;April 3,2012 LTE W 1<=2 GTE W 2>=1 NEQ W 1<>2 CAND W 1&&2 COR W 1||0 QUIT For clarity, I put a label on each line. These were the errors that GT.M identified: LTE W 1<=2 ^----- At column 9, line 3, source module /home/wvehr-2-test/EHR/r/ZZTST.m %GTM-E-RHMISSING, Right-hand side of expression expected GTE W 2>=1 ^----- At column 9, line 4, source module /home/wvehr-2-test/EHR/r/ZZTST.m %GTM-E-RHMISSING, Right-hand side of expression expected NEQ W 1<>2 ^----- At column 9, line 5, source module /home/wvehr-2-test/EHR/r/ZZTST.m %GTM-E-RHMISSING, Right-hand side of expression expected CAND W 1&&2 ^----- At column 10, line 6, source module /home/wvehr-2-test/EHR/r/ZZTST.m %GTM-E-RHMISSING, Right-hand side of expression expected COR W 1||0 ^----- At column 8, line 7, source module /home/wvehr-2-test/EHR/r/ZZTST.m %GTM-E-SPOREOL, Either a space or an end-of-line was expected but not found I then ran XINDEX. GTM>D ^XINDEX V. A. C R O S S R E F E R E N C E R 7.3 [2008 VA Standards & Conventions] UCI: EHR CPU: EHR Apr 03, 2012@15:26:26 Routine: ZZTST ZZTST Current total of 1 routine. Routine: Select BUILD NAME: Select PACKAGE NAME: Print more than compiled errors and warnings? YES// Print summary only? NO// Print routines? YES// Print (R)egular,(S)tructured or (B)oth? R// Print errors and warnings with each routine? YES// Index all called routines? NO// DEVICE: TELNET V. A. C R O S S R E F E R E N C E R 7.3 [2008 VA Standards & Conventions] UCI: EHR CPU: EHR Apr 03, 2012@15:26:26 Routines: 1 Faux Routines: 0 ZZTST --- CROSS REFERENCING --- Press return to continue: Compiled list of Errors and Warnings Apr 03, 2012@15:26:26 page 1 ZZTST * * 8 Lines, 121 Bytes, Checksum: B38275 CAND W 1&&2 CAND F - General Syntax Error. COR W 1||0 COR F - General Syntax Error. --- Routine Detail --- with REGULAR ROUTINE LISTING --- Press return to continue: ZZTST * * 8 Lines, 121 Bytes, Checksum: B38275 Apr 03, 2012@15:26:26 page 2 7 bytes in comments ZZTST ;DJW/WV ;;1.0;Test XINDEX;****;April 3,2012 LTE W 1<=2 GTE W 2>=1 NEQ W 1<>2 CAND W 1&&2 COR W 1||0 QUIT ***** ERRORS & WARNINGS IN ZZTST ***** CAND F - General Syntax Error. COR F - General Syntax Error. ***** INDEX OF ZZTST ***** Local Variables Line Occurrences ( >> not killed explicitly) ( * Changed ! Killed ~ Newed) NONE Press return to continue: ***** INDEX OF ZZTST ***** Apr 03, 2012@15:26:26 page 3 Global Variables ( * Changed ! Killed) NONE Naked Globals NONE Marked Items NONE Label References NONE External References NONE ***** END ***** --- END ---
like0

Adapting XINDEX ? - proposed patch for XINDX9.m

Luis Ibanez's picture

David,

This is a great practical example.

Thanks for putting it together.

 

It looks like we should explore the option of adapting XINDEX to capture and flag the use of these non-standard expressions.

 

If I'm following you correctly, what we want is XINDEX to report syntax errors in the expressions:

 

LTE W 1<=2 GTE W 2>=1 NEQ W 1<>2

 

Just as it currently does with the expressions:

CAND W 1&&2 COR W 1||0

 

The error code for syntax errors seems to be "21" in XINDX1.m, 

https://github.com/OSEHRA/VistA-FOIA/blob/master/Packages/Toolkit/Routines/XINDX1.m

in location ERROR+21

 

This seems to be invoked as:

D E^XINDEX(21)

 

from

XINDEX.m   (for missing command)

XINDX2.m (for missing arguments)

XINDX9.m (in three cases): at PAS2+8, PAS2+12 and PAS2+15:

https://github.com/OSEHRA/VistA-FOIA/blob/master/Packages/Toolkit/Routines/XINDX9.m

 

The syntax error of the COR case is caught in PAS2+12, where it is checking for duplicate operators.

 

One potential way to detect these three new cases is to add the specific IF statements at the end of the PAS2 parsing loop (not very elegant, but apparently effective).

 

Here is a proposed patch, modifying XINDX9.m to detect the three cases of non-ANSI LTE, GTE, and NEQ that you pointed out.

http://review.code.osehra.org/#/c/162/

 

Here is the side-by-side comparison of the proposed change:

http://review.code.osehra.org/#/c/162/1/Packages/Toolkit/Routines/XINDX9.m

 

With these change, I get XINDEX to report the non ANSI LTE, GTE and NEQ expressions as syntax errors, when running this in the VistA-FOIA VM:

 

 

Compiled list of Errors and Warnings Apr 03, 2012@18:38:50 page 1 ZZTST * * 9 Lines, 135 Bytes, Checksum: B48303 LTE W 1<=10 LTE F - General Syntax Error. GTE W 1>=10 GTE F - General Syntax Error. NEQ W 1<>10 NEQ F - General Syntax Error. COR W 1||10 COR F - General Syntax Error.           

There are probably many smarter ways to make this modification in XINDX9.m...      :-)

 

So please see this just as a starter for a thread discussion for this patch in Gerrit.

 

    Thanks

 

 

like0

ANSI Considerations

STEVEN MCPHELAN's picture

What if any influence will we have with the VA? The use of Cache specific (or GT.m or any other M extensions) is not allowed by the VA SAC. Any deviation from the SAC requires explicit approval from the SACC. Have those using these types of extensions in VA VistA Class I M SAC received the approval of the SACC? Where is VA's QA validation for adherence to the SAC?

like0

ANSI Considerations

STEVEN MCPHELAN's picture

I meant to add.  As OSEHRA guidelines for enhancements, I believe we should restrict the use of M implementation specific code within VA FOIA released modifications (if practical).  Like the Kernel, we should then encourage any use of such syntax like this or Cache object script or whatever should be confined (if practical) to an external routine which any ANSI standard M implementation can invoke via a DO or GO or $$ synatx.

Is not one of the primary goals of OSEHRA to encourage enhancements to FOIA VistA in such a manner that it makes it easier for the VA to incorporate those modifications within the FOIA VistA source code base?  As such, should not this group encourage those programming practices which further that objective instead of the old classic cowboy style of programming?

As to modifying XINDEX, I would not want to see the notification to disappear.  I would like to see any non-ANSI 1995 violations flagged in some manner.  Unfortunately, the SACC has allowed a few such violations.  The VA XINDEX routine checks for SAC compliance.  I do not remember from memory if XINDEX provides a notification if ANSI is violated but SAC is not.

like0

Adding XINDEX warnings for non-ANSI operators

Luis Ibanez's picture

It seems that we are in the same page.

David's example was intended to illustrate the kind of non-ANSI operators that may have percolated in some versions of the code base, and that we should strive to remove, in order to ensure that the code base can be used in different platforms.

 

The proposed modification to XINDEX:

http://review.code.osehra.org/#/c/162/

is intended to flag these non-ANSI operators as syntax warnings, so that we can locate them in the code and propose patches to replace them with ANSI operators.

 

Currently XINDEX is not identifying the following operators as syntax errors:

<=, >=, <>

 

The proposed XINDEX modification will cause the generation of warning when these non-ANSI operators are found in the code. It is adding new notifications, not removing existing notifications.

It may actually be worth considering to creat a specific error entry for non-ANSI code. For example  in

https://github.com/OSEHRA/VistA-FOIA/blob/master/Packages/Toolkit/Routines/XINDX1.m

we could have a new error code "64", specifically targeted to the detection non-ANSI code.

like0

ANSI X11.1-1995 M Considerations

Wes Turner's picture

Just as a general note, we work by the adage "If it isn't tested, then it
is broken." This is not always true, but it is true often enough that it
makes a useful watchword. I'll remain silent on the question of whether or
not ANSI Mumps is or should be required by the SAC. This is up to the
larger community including yourselves and the VA to decide, but once the
decision is made we need too ensure that the resulting SAC is tested and
validated by the testing framework. Anything else means that a lot of
non-critical errors and violations will creep in.

On a related note, if anyone has code snippets that validate different
portions of the SAC not adequately tested by the Xindex tests currently in
the testing harness, we would be happy to help them roll them into the
testing framework. Then as we walk through code convergence, we can be
sure to pick or engineer solutions to the convergence problems that meet
the SAC.

- Wes

On Wed, Apr 4, 2012 at 10:11 AM, smcphelan <smcphelan@dssinc.com> wrote:

> I meant to add. As OSEHRA guidelines for enhancements, I believe we
> should restrict the use of M implementation specific code within VA FOIA
> released modifications (if practical). Like the Kernel, we should then
> encourage any use of such syntax like this or Cache object script or
> whatever should be confined (if practical) to an external routine which any
> ANSI standard M implementation can invoke via a DO or GO or $$ synatx.
>
> Is not one of the primary goals of OSEHRA to encourage enhancements to
> FOIA VistA in such a manner that it makes it easier for the VA to
> incorporate those modifications within the FOIA VistA source code base? As
> such, should not this group encourage those programming practices which
> further that objective instead of the old classic cowboy style of
> programming?
>
> As to modifying XINDEX, I would not want to see the notification to
> disappear. I would like to see any non-ANSI 1995 violations flagged in
> some manner. Unfortunately, the SACC has allowed a few such violations.
> The VA XINDEX routine checks for SAC compliance. I do not remember from
> memory if XINDEX provides a notification if ANSI is violated but SAC is not.
> --
> Full post: http://www.osehra.org/wiki/ansi-x111-1995-m-considerations
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/667
>

--
Wesley D. Turner, Ph.D.
Kitware, Inc.
Technical Leader
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4920

like0

ANSI Standards

STEVEN MCPHELAN's picture

I forget that this is not a predominantly VA based audience.  Adherence to ANSI M standards has been part of the VA's programming Standards and Conventions (SAC) for 25 years or more.  The VA's SAC Committee (SACC) approves any changes to those standards and they also approve exemptions to those standards.  The standards for M development are much more well defined than corresponding non-M development.  It has been strict adherence to those standards that has contributed to the success of VistA in the VA across multiiple platforms and to support the concept of distributed, independent development over the entire US without developers stepping on each other.

like0

ANSI X11.1-1995 M Considerations

Wes Turner's picture

If you make the change available in a git repository, I will try to get an
Experimental run to see just how often this occurs in the FOIA.

- Wes

On Wed, Apr 4, 2012 at 1:06 PM, luisibanez <luis.ibanez@kitware.com> wrote:

> It seems that we are in the same page.
>
> David's example was intended to illustrate the kind of non-ANSI operators
> that may have percolated in some versions of the code base, and that we
> should strive to remove, in order to ensure that the code base can be used
> in different platforms.
>
>
>
> The proposed modification to XINDEX:
>
> http://review.code.osehra.org/#/c/162/
>
> is intended to flag these non-ANSI operators as syntax warnings, so that
> we can locate them in the code and propose patches to replace them with
> ANSI operators.
>
>
>
> Currently XINDEX is not identifying the following operators as syntax
> errors:
>
> <=, >=, <>
>
>
>
> The proposed XINDEX modification will cause the generation of warning when
> these non-ANSI operators are found in the code. It is adding new
> notifications, not removing existing notifications.
>
> It may actually be worth considering to creat a specific error entry for
> non-ANSI code. For example in
>
> https://github.com/OSEHRA/VistA-FOIA/blob/master/Packages/Toolkit/Routin...
>
> we could have a new error code "64", specifically targeted to the
> detection non-ANSI code.
> --
> Full post: http://www.osehra.org/wiki/ansi-x111-1995-m-considerations
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/667
>

--
Wesley D. Turner, Ph.D.
Kitware, Inc.
Technical Leader
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4920

like0

ANSI X11.1-1995 M Considerations

Wes Turner's picture

All,

I received this note from Joe after assking him to run the code. We can
provide raw data if it would be useful.

- Wes

Hi Wes,

The experimental that you asked for is on the dashboard at:

http://code.osehra.org/CDash/buildSummary.php?buildid=1172

It caused an increase of 21 errors with 2 new packages failing:

- Emergency Department Integration Software
- Quasar

On Wed, Apr 4, 2012 at 2:35 PM, Wes Turner <wes.turner@kitware.com> wrote:

> If you make the change available in a git repository, I will try to get an
> Experimental run to see just how often this occurs in the FOIA.
>
> - Wes
>
> On Wed, Apr 4, 2012 at 1:06 PM, luisibanez <luis.ibanez@kitware.com>wrote:
>
>> It seems that we are in the same page.
>>
>> David's example was intended to illustrate the kind of non-ANSI operators
>> that may have percolated in some versions of the code base, and that we
>> should strive to remove, in order to ensure that the code base can be used
>> in different platforms.
>>
>>
>>
>> The proposed modification to XINDEX:
>>
>> http://review.code.osehra.org/#/c/162/
>>
>> is intended to flag these non-ANSI operators as syntax warnings, so that
>> we can locate them in the code and propose patches to replace them with
>> ANSI operators.
>>
>>
>>
>> Currently XINDEX is not identifying the following operators as syntax
>> errors:
>>
>> <=, >=, <>
>>
>>
>>
>> The proposed XINDEX modification will cause the generation of warning
>> when these non-ANSI operators are found in the code. It is adding new
>> notifications, not removing existing notifications.
>>
>> It may actually be worth considering to creat a specific error entry for
>> non-ANSI code. For example in
>>
>>
>> https://github.com/OSEHRA/VistA-FOIA/blob/master/Packages/Toolkit/Routin...
>>
>> we could have a new error code "64", specifically targeted to the
>> detection non-ANSI code.
>> --
>> Full post: http://www.osehra.org/wiki/ansi-x111-1995-m-considerations
>> Manage my subscriptions:
>> http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/667
>>
>
>
>
> --
> Wesley D. Turner, Ph.D.
> Kitware, Inc.
> Technical Leader
> 28 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4920
>

--
Wesley D. Turner, Ph.D.
Kitware, Inc.
Technical Leader
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4920

like0