It is currently Tue Nov 21, 2017 4:47 am


All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: 2. X11/1993-39, $REFERENCE
PostPosted: Tue Jan 28, 2014 7:58 am 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
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 293 times

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus
Top
Offline Profile  
 
 Post subject: Re: 2. X11/1993-39, $REFERENCE
PostPosted: Tue Jan 28, 2014 2:18 pm 
User avatar

Joined: Mon Nov 01, 2010 3:33 pm
Posts: 103
Location: Australia
Real Name: Ray Newman
Began Programming in MUMPS: 01 Jul 1976
Hmmm - MUMPS V1 does not fully comply in that it does not allow SETting of $REFERENCE.

Ray Newman


Top
Offline Profile  
 
 Post subject: Re: 2. X11/1993-39, $REFERENCE
PostPosted: Tue Jan 28, 2014 2:36 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
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.

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Re: 2. X11/1993-39, $REFERENCE
PostPosted: Tue Jan 28, 2014 6:51 pm 
User avatar

Joined: Mon Nov 01, 2010 3:33 pm
Posts: 103
Location: Australia
Real Name: Ray Newman
Began Programming in MUMPS: 01 Jul 1976
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


Top
Offline Profile  
 
 Post subject: Re: 2. X11/1993-39, $REFERENCE
PostPosted: Wed Jan 29, 2014 1:06 pm 
User avatar

Joined: Wed Jul 20, 2011 11:49 am
Posts: 9
Location: Russia, Moscow
Real Name: Eugene Karataev
Began Programming in MUMPS: 10 Mar 1997
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


Top
Offline Profile  
 
 Post subject: Re: 2. X11/1993-39, $REFERENCE
PostPosted: Fri Jan 31, 2014 11:10 am 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
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.

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Re: 2. X11/1993-39, $REFERENCE
PostPosted: Fri Jan 31, 2014 5:30 pm 
User avatar

Joined: Mon Nov 01, 2010 3:33 pm
Posts: 103
Location: Australia
Real Name: Ray Newman
Began Programming in MUMPS: 01 Jul 1976
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


Top
Offline Profile  
 
 Post subject: Re: 2. X11/1993-39, $REFERENCE
PostPosted: Fri Jan 31, 2014 7:18 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
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. :)

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Re: 2. X11/1993-39, $REFERENCE
PostPosted: Sat Feb 01, 2014 4:09 am 
User avatar

Joined: Mon Nov 01, 2010 3:33 pm
Posts: 103
Location: Australia
Real Name: Ray Newman
Began Programming in MUMPS: 01 Jul 1976
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


Top
Offline Profile  
 
 Post subject: Re: 2. X11/1993-39, $REFERENCE
PostPosted: Sat Feb 01, 2014 10:32 am 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
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.

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net