ills
illsM Computing, Volume 3, number 4, September 1995, pages 50-52
Many people feel that standards committees consist of a bunch of stuffy people, who do nothing but nitpick about commas and underlines and who spend their time discussing formal diagrams that nobody but they can understand.
Does that stereotype fit the MDC?
Well... sometimes it just does look like that: it is important that standards are written in unambiguous terms, and a certain amount of nitpicking is hard to avoid if that goal is to be accomplished. Also, there are certain matters that are easier to describe unambiguously in a formal language (metalanguage) than in common colloquial terms. When we're working on that part of the job, the MDC indeed fits the stereotype.
But that is not all. There is also a lot of exciting work going on in the various sub-groups of the committee.
I won't bore you with "Subcommittee 12345 has task groups 123 through 987 and works on the purification of sewer-byproducts after they have passed the third membrane of the secondary language manipulation stage" kind of mumbo jumbo in this month's column.
In the past columns, I reported on the latest achievements of the MDC. In this month's column, I want to focus on the new projects that are starting. Also, I want to extend an invitation to all readers to join us and help us bring these tasks to completion, or provide us with solid reasons why we should abandon them before we waste too much time on them.
It is important that the MDC work for and with the M[UMPS] community. The MDC is aware of the stereotype mentioned above, and knows how easy it is to spend meeting after meeting discussing side-issues that are only of an academic importance. What the MDC wants to achieve is to maintain M[UMPS] as a leading vehicle in the data processing world. If that's what we want, we'd better listen to what you have to say, shouldn't we?
We're at a point in the cycle of events for a standards commitee where we've just "delivered" our new baby: the draft standard is through the canvass process, and the concensus is that we should move the presented documents forward to ANSI for approval as American National Standards.
We all know that the proceedings of the canvass are being appealed, but I don't want to discuss that issue in this column. Elsewhere in this issue (or the next), there will probably be a couple of pages where the details of the appeals are being discussed.
At the end of this column I will mention as many of the new projects as I can remember (but I'm the chairman now, I don't have time anymore to attend as many task group meetings as I used to...). What I want to see happen is that you, the M[UMPS] users let us know what you feel is important.
Please, tell us which projects are academic and nitpicky.
Please, tell us which what you need and we're not working on.
One of my goals as a chairman is to ensure that my successor will not face a canvass where he or she has to hear objections like "I really need this and you never worked on the issue".
So, how do we get there from here?
Step one: let us know. You are invited and welcome to attend our meetings. You are invited to become one of our members. That is easily said, but there are travel expenses involved in doing so, and not everyone can afford the time and expenses it takes to be a member of the MDC. What everyone can do is write to us. The secretariat of the MDC is at the same address as the MTA. A letter to the MDC does not need to be in "formal metalanguage". The MDC has the people who can convert ideas written on the back of a napkin into formal language. I have done it myself, there are other people in the MDC who have done it. There are several people in Europe and Australia who are grateful that we did this for them. You won't be the first, but you have to let us know. If we don't know what you need today, you can guess how the chairperson of 2001 (or whenever the next standard will be canvassed) will respond to your objection if it falls in the category "never let the MDC know that this need existed".
Step two: remind us. This should never occur, but if you have sent us a letter, and you didn't hear from us half a year later, something went wrong. We make an issue of responding to all incoming mail, but we also have our share of coming and going officials and we are all human, and, occasionally, we simply forget something. If you don't get a response to a letter within half a year, please make sure you remind us. Write a second letter to The Chairman. Whether I still hold the chair at that time, or a successor will be there, I'm certain that this part of our goal will not change with a new chair.
Having written my share of proposals to modify the M[UMPS] language myself, I have heard two particular worries quite often: "has it been implemented?" and "can it be implemented?"
If you ask the MDC to work on an idea like: "M[UMPS] should be capable of dealing with texts in non-ASCII character sets", our people will go off on their tangents and work on the issues that they see. Being European myself, I know some things about non-ASCII collating algortihms. Of course, this does not mean that I know how to collate 5th century (AD) Old Norse, or current day Chinese.
Similar details apply to different requests.
So... The MDC will present a mechanism that will allow you to specify "what you asked for", and you may end up being stuck with a limited solution, or one where you will have to specify the "nitpicking details" yourself...
Does this sound enough like the MDC feels like we've created what you asked for, but not really what you need?
Yes, we are aware of this problem. We take credit for our solution, and we will accept the blame for its limitations.
If you tell the MDC: we need a function to get the so-many'th subscript of a name. It is a lot easier. That kind of idea is clear-cut, and the result is obvious (by the way: that function is called $QSUBSCRIPT).
But... whatever you ask the MDC to work on, keep close tabs on how the ideas develop within the committee: they say that if you ask a committee to design a race horse, you will end up with a hippopotamus. I don't know if that is inevitable with the MDC as well, I do know that, while working on ideas to change the language, quite often side-issues and compatibility issues enter into the consideration, and the final result quite often does differ from the initial ideas.
This meeting, quite a lot of new ideas were discussed.
I will try to represent them all in this column as questions. The discussion is ongoing. If you wish to have an impact, you know where to send your letters.(!)
I am aware that this (short) exposition of the current proposals will probably raise some questions as to their content. Please feel free to contact the MDC Secretatiat to order a subscription to the MDC mailings. The cost of such a subscription is based on the expense of xeroxing and postage only.
Just to set the record straight: the following is my perception of "what's currently going on". Task groups may have decided to drop items that I am cheerfully presenting here. (It will be at least another month before I can see their task group minutes, and if I couldn't attend their latest meeting, I as well depend on those to see the progress.)
Push and Pop
Can we have the ability to exit from a complex DO structure in a simple way?
Object Oriented additions
Which strategy shall we follow?
Character set 8859-1 (USA)
For "internationalization", we will need to add many character set profiles to the M[UMPS] suite of standards. But can we already deal with the American character set?
How should we support case-insensitive sorting?
Which "other" character sets should we support?
Bit operations and character set
How should we implement bit-wise logic (and, or, xor)?
Should this functionality be supported at all?
Would the addition of a "BIT" character set profile help
(that is, a character set with only two possible characters, and implementors able to store those "BIT"s as compact as possible)?
User definable I/O
There may be a binding to some entity, but if your implemenmtation does not support that binding, can you compensate for that?
Current mnemonicspace
The standard currently does not give us a means to determine what the current mnemonicspace is.
Is there a need to supply such information?
Matrix mathematics
Do we need a set of library functions to perform matrix math? If so, how should those functions interact with M[UMPS]'s premise of sparsity?
XOR operator
DO we need a logical or a bit-wise XOR operator?
A mechnism to scan all currently defined local variables
How should this be done?
$order(name)
$order(^$JOB(job#,"LVN",...))
otherwise?
Patern match string extraction
How does one find a substring that matches a (sub)pattern?
The M[UMPS] way? xxx?xxx
The Unix way? <regular expression>
(Both can get really ugly, both yield results. What do we really need, what do we really want to return?)
Do we need any explicit functionality to deal with "non-matching" substrings?
Structures for bindings
Is there a need? (most important question to answer)
If so, how do we proceed?
Naked indicator
During MERGE: should error trapping tell us "how far" we got?
At all: do we want to abandon this language feature?
If-Then-Else
We all know that $TEST is a (Turing like) state variable, but we all want ELSE to operate as it does in the language C... Or do we?
The poll that was conducted in 1991 revealed that the user community was quite happy with the way $TEST works.
Is that still true?
OMI job
Well, this is not a new one, but it hasn't seen many floodlights yet. I guess we do want to be able to JOB tasks across the network. Or do we?
Local storage
How do we standardize the premise that each M[UMPS] job may need a virtually infinite amount of storage that is treated as if it is "local" to that job, i.e. accessible to that job and no other job, and disappearing after that one job terminates?
Variable number of arguments
Did you ever want to call a function like:
$$MAX^xxx(1,98345679,PI,MU,ETCETERA)
and expect it to return the largest of the specified parameters, no matter how many parameters were specified?
How should we specify the formal parameterlist, so that a truly "unspecified" number of parameters may be passed?
User defined ssvns
Is this the M[UMPS] method of implementing object orientation, or is it an oddity to be discarded as soon as we can?
expritem indirection
The current syntax imposes limitations. Are these limitations workable?
This one is not new at all, but it is still a question:
Decimal Point Alternative
Should the MDC create "localization" functionality, or should such formatting be accomplished through $TRANSLATE?
ROUTINE management
The ZLOAD, ZINSERT and ZSAVE commands are still imlementation specific.
What do we need to do to create a standardized command that is acceptible to the M[UMPS] community and has a balanced compromise between standardized and implementation specific parameters?
Curly braces
A proposal to introduce scoping based on explicit delimiters has been "in the works" for quite a while.
How do we want to proceed with this proposal?
Portable length of names
Should M[UMPS] names be limited to 8 characters, or could they be longer?
Portable length of strings
What should be the limitation (for portability) for strings.
It used to be 255 characters.
Currently, it is 510 characters.
Should we make it any longer?
Or should we make it "unlimited"?
Ed de Moel is past chairman of the MDC
and works with Jacquard Systems Research.
His experience includes developing software for research in medicine
and physics.
Over the past ten years, Ed's has mostly focused on the production
of tools for data management and analysis, and tools for the support
of day-to-day operation of medical systems.
Ed can be
reached by e-mail.