Mumpster
http://mumpster.org/

2. X11/1993-39, $REFERENCE
http://mumpster.org/viewtopic.php?f=20&t=1763
Page 1 of 2

Author:  toad [ Tue Jan 28, 2014 7:58 am ]
Post subject:  2. X11/1993-39, $REFERENCE

Here is the second MDC Type A extension we applied to our Revised MUMPS Draft Standard (RMDS). It adds a new feature to the MUMPS language and fixes a bug in MUMPS 1995.

$REFERENCE is a new intrinsic special variable that gives us a way to access and manipulate the naked indicator, to give us greater control over this subtle - sometimes too subtle - indirect feature of MUMPS. It always equals the most recently referenced global variable name, on which the current value of the naked indicator is based, and it can be set to change the naked indicator. In special cases when the naked indicator is undefined (such as when a MUMPS process is first created and so has not yet referenced any global name), $REFERENCE equals the empty string.

The bug in MUMPS 1995 it fixes is in Section I clause 7.1.5.15 $QUERY, the last paragraph of which reads:

"If the argument of $QUERY is a gvn [global variable name], the naked indicator will become undefined and the value of $REFERENCE will become equal to the empty string."

The problem is that $REFERENCE is mentioned here, yet not defined anywhere within MUMPS 1995. It's a dangling reference.

This happened because the sponsor of $QUERY was sure $REFERENCE would be approved before $QUERY, but in the end $REFERENCE just missed the cutoff at the June 1993 meeting that closed out the extensions to be included in MUMPS 1995. It was a rare bug indeed to survive all the scrutiny of the MDC's rigorous parliamentary procedures and make it into a MUMPS standard, and it ended up being a subject much discussed during MUMPS 1995's canvass process. In the end, MUMPS 1995 was published with an inserted flyer that pointed out the bug and rightly explained it as an artifact of the standardization process and fixed in the next MUMPS standard.

As a result, when MDC Task Group 6 began its preparation of MUMPS 2015, of all the MDC Type A Extensions, this was the first one we knew we had to include to make good on that promise.

This proposal was proposed by the MUMPS Development Coordinating Committee of Europe and sponsored by Ed de Moel and developed within MDC Subcommittee 15, Programming Structures. The MDC approved this extension at its 20 June 1993 meeting in Washington, DC, by a vote of thirty-nine in favor, none opposed, and five abstentions.

Attachments:
File comment: MDC Type A Extension X11/1993-39 $REFERENCE
MDC 1993-39 $REFERENCE.pdf [251.97 KiB]
Downloaded 1804 times

Author:  raynewman [ Tue Jan 28, 2014 2:18 pm ]
Post subject:  Re: 2. X11/1993-39, $REFERENCE

Hmmm - MUMPS V1 does not fully comply in that it does not allow SETting of $REFERENCE.

Ray Newman

Author:  toad [ Tue Jan 28, 2014 2:36 pm ]
Post subject:  Re: 2. X11/1993-39, $REFERENCE

Ray, is that something you want to tackle? We have volunteers standing by, who you can sic on any extension you don't personally want to implement.

For Eugene, Keith, and the other implementors, the backstory here is that Ray donated his MUMPS V1 as the MDC's open-source reference implementation, where we can try out proposals even before they get to Type A status. For now, though, our priority for it as the same as your priorities for your implementations - to get the existing Type As implemented to create the new MUMPS standard.

Author:  raynewman [ Tue Jan 28, 2014 6:51 pm ]
Post subject:  Re: 2. X11/1993-39, $REFERENCE

Rick, I would prefer some help on the transaction stuf that I didn't implement as I don't understand it. The SET $REFERENCE is reasonably simple and I will have a go at it in the near future.

Ray

Author:  Eugene Karataev [ Wed Jan 29, 2014 1:06 pm ]
Post subject:  Re: 2. X11/1993-39, $REFERENCE

MiniM already allow left assignment of intrinsic variable $R[EFERENCE] including empty string.

As I mean, need to be specified what error must be raised if $R was assigned to non-glvn name or specify that no error need to be raised, or need vendor-specific error, or else.

It is current MiniM behaviour:

Code:
USER>s $R="ee"

USER>w $r
ee

Author:  toad [ Fri Jan 31, 2014 11:10 am ]
Post subject:  Re: 2. X11/1993-39, $REFERENCE

Eugene, I'm delighted to hear you have already implemented $REFERENCE.

What I am about to say is not a formal ruling of MDC TG17 Interpretations, just my take on it as a past standard editor, but it looks to me as if you are right that there is ambiguity in the standard about how to handle SET $REFERENCE, and that this same ambiguity exists for SET $DEVICE, but much lesser ambiguities exist for SET $X and SET $Y, and SET $KEY is not ambiguous at all.

The reason the latter three are less ambiguous is that in clause 8.2.18 SET the standard says:

"For each setleft, if it is a leftrestricted, the value to be assigned or replaced is truncated or converted to meet the inherent restrictions for that setleft before the assignment takes place. This means that in one SET command, the various setlefts may receive different values."

In other words, a set leftrestricted operation is expected to perform whatever type coercion is needed to produce an appropriate value for the target. This makes intuitive sense, since MUMPS prefers type coercion over errors wherever possible.

In clause 7.1.4.10 Intrinsic special variable names svn, $X and $Y are defined as containing nonnegative integers. In clause 7.1.4.6 Integer interpretation, rules are given for coercing any string into an integer. So far so good, but we have no rules for interpreting an integer into a nonnegative integer, so what should happen if someone writes SET $X=-10? Should $X be assigned the value 10 or 0 or should an error condition arise? I don't know. The only thing I know for sure is that it should not be assigned the value -10.

In clause 7.1.4.10 Intrinsic special variable names svn, $KEY is defined as containing "the control-sequence which terminated the last READ command from the current device (including any introducing and terminating characters)." Hence, SET $KEY=VARIABLE should succeed for any value of VARIABLE.

Unfortunately, greater ambiguities exist with $DEVICE and $REFERENCE.

In clause 7.1.4.10 Intrinsic special variable names svn, $DEVICE is defined as containing "one of

Code:
| M     |
| M,I   |
| M,I,T |


"where M is an MDC-defined value, I is an implementor-defined value, and T is explanatory text.

"The value of M, when interpreted as a truth value, will be equal to 0 (zero) when no significant change of status is being reported. Any nonzero value indicates a significant change of status.

"The value of I is an implementation-specific value for the relevant status-information. The value of T is implementation specific.

"Note: Since M, I, and T are separated by commas, the values of M and I cannot contain this character."

In other words, $DEVICE contains a unique data type, a string with a very specific structure. The standard neither gives rules for how to coerce general strings into this unique type, nor defines an error condition that will arise if an unsuitable value is assigned to $DEVICE.

In the MUMPS 2015, in clause 7.1.4.10 Intrinsic special variable names svn, $REFERENCE is defined as containing either the empty string or a gvn. The standard neither gives rules for how to coerce general strings into gvns, nor defines an error condition that will arise if an unsuitable value is assigned to $REFERENCE.

These ambiguities will need to be corrected in MUMPS 2015.

I suspect $DEVICE will be handled by defining an error condition, and $X and $Y by defining coercion rules from integers to nonnegative integers, but $REFERENCE could go either way. We'll put MDC TG17 Interpretations back together and get you a ruling, and we'll follow that up with a new MDC Type A Extension to build the ruling into the standard.

Thank you very much for bringing this up, Eugene.

And if you spot any other ambiguities in the standard as you proceed with implementation, please do not hesitate to bring them up, too. This kind of dialogue is crucial to refining the standard.

Author:  raynewman [ Fri Jan 31, 2014 5:30 pm ]
Post subject:  Re: 2. X11/1993-39, $REFERENCE

I didn't implement SETting of $DEVICE in MUMPS V1 as I couldn't see what use it would be and could not determine if it actually changed anything.

Ray

Author:  toad [ Fri Jan 31, 2014 7:18 pm ]
Post subject:  Re: 2. X11/1993-39, $REFERENCE

The setting of $DEVICE is not to alter the MUMPS environment, but to let us write device handling tools that can produce consistent results across different implementations, so that where implementations differ, our standard calls can change $DEVICE to be the same. I don't yet have access to the MDC Type A Extension that explains the reasoning, so I'm guessing about their reasons based on my past work on device handling tools. :)

Author:  raynewman [ Sat Feb 01, 2014 4:09 am ]
Post subject:  Re: 2. X11/1993-39, $REFERENCE

Rick,

From memory, there is no spec for what goes past the first comma in $DEVICE. I use the third piece for the device/file name and feel that changing that is a bit silly.

On ssvns, I feel that the standard needs to say a lot more here.

On Z(cmds, vars, func, etc) - MUMPS should work without these.

Ray

Author:  toad [ Sat Feb 01, 2014 10:32 am ]
Post subject:  Re: 2. X11/1993-39, $REFERENCE

Some of the MDC Type A Extensions that will be part of MUMPS 2015 do flesh out the structured system variables a bit more, but they're mainly cleanup this time around, making SSVNs full partners in the language instead of add-ons.

Page 1 of 2 All times are UTC - 8 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/