hokey@plus5.uucp (The Moderator) (05/21/85)
std-mumps Digest Mon, 20 May 85 Volume 1 : Issue 18
Today's Topics:
Administrivia
Activation blocks and block structuring
A reprint of my Block Structure proposal
Problem with definition of fixed length reads
----------------------------------------------------------------------
Date: 20 May 85 19:17:52 CDT (Mon)
From: plus5!hokey
Subject: Administrivia
To: plus5!std-mumps
Bob Isch asked several questions:
1) How many people read this group? How many people are interested
in this group?
I don't know, but I suspect about over a dozen people actually
pay attention to what is said, and several more probably read
it just because it's there.
2) Why is this a moderated group? Assuming enough interest exists to
warrant the group how about making it unmoderated?
The group is moderated because it feeds directly into ANSI X11.1.
One of my responsibilities as a moderator is to submit copies of
all postings to Thomas Salander, the Secretary of the MDC. These
copies are included in the official mailings of the MDC, and serve
to provide easy access to the MDC by interested parties in the
field, who would not otherwise have easy access to the Committee.
There is no reason why a non-moderated version could not exist.
Post something to net.news.group. Just realize that net.lang.mumps
would not be an official gateway to the MDC.
As soon as it can be arranged, I'd *love* to see Thomas be the
moderator. Unfortunately, he does not yet have net access.
I am hoping that the VA MailMan software will provide significantly
wider access to this group than is now possible. With any luck,
Tom Munnecke will have enough time to pull this off before the
upcoming MUG meeting in June.
Hokey
------------------------------
Date: 20 May 85 21:53:41 CDT (Mon)
From: plus5!hokey
Subject: Activation blocks and block structuring
To: plus5!std-mumps
Bob, you and I will probably never agree on this. I think explicit
block structures are *wrong* for mumps.
Adding parameter passing to an extrinsic block invocation could be done
this way (note, the block is invoked like extrinsic functions or variables,
except that extrinsic subroutines return no value):
do $$(a,.b)
.(x,y) new (x,y)
. Blah Blah
. q
-or-
s a=$$(a,.b)
.(x,y) new (x,y)
. Blah Blah
. q value
Can you imagine this instead: do {(w,x) ... do {(y,z) ... }(a,.b) {c,.d}
I would *hate* to have to scan down a bunch of code just to see what my
actual parameters are.
The alternative is this: do (a,.b){(w,x) ... do (c,d){(y,z) ... }}
I think this format is *significantly* harder to read than the examples
given above.
And don't forget, we're trying to become an ISO standard, and { and } are
national use characters.
Hokey
------------------------------
Date: 20 May 85 19:00:22 CDT (Mon)
From: plus5!hokey
Subject: A reprint of my Block Structure proposal
To: plus5!std-mumps
Plus Five
subject: Block Structuring Standard MUMPS date: May 20, 1985
from: Hokey Stenn
ABSTRACT
Implementation and stylistic issues surrounding the inclusion of a
block structure mechanism in Standard MUMPS are examined. These
issues include implicit versus explicit start- and end-of-block
designation, and whether to implement the control structure at the
command level or as an argument to the DO command.
Plus Five
subject: Block Structuring Standard MUMPS date: May 20, 1985
from: Hokey Stenn
1. PURPOSE
The addition of a block structuring mechanism will enable programmers
to write code in either a vertical or horizontal style, as befits the
application and personal style.
2. SPECIFYING A BLOCK
2.1 Explicit Block Boundaries
This approach to block structuring uses characters to delimit the
boundaries of a block of code. This approach is used in most
structured languages. Since most structured languages are compiled,
and very few (if any) have an XECUTE command, this approach makes
sense for those languages. (The problem with the XECUTE command may
be obvious - what happens if the evaluated argument of the command is
an end-of-block?) Use of explicit block boundaries would effectively
require a parsing check at each program load (or a pseudo compile
before each load) because of the time it would take to search for the
logical end-of-line. Additionally, without pre-processing each
program it would be very difficult to determine legal control
transfer points (entryrefs). Since a programmer might end several
blocks on a single physical line it would be possible for code to
"fall through" to a point Somewhere in the middle of a line. The
effect of QUIT within a block would have to be specified. Also, if a
comment extended to the end of a physical line one could not document
at the end of a block if one wanted to close off several blocks on a
single line.
The more I think about explicit blocks, the less I like them for
Mumps. If I were Terry Ragon I would not let my personal bias show
through and I would, perhaps, be able to think of some redeeming
features to this method of delineating a block in the Mumps
environment.
This method of block structuring is fine for most compiled languages.
2.2 Implicit Block Boundaries
This method of programming blocks uses two steps: invocation by some
trigger, and isolation of the block in a contextual manner. Since
this contextual delineation would exist before the first command on a
line, there would be significantly fewer problems determining the
depth of a block or the extent of a block, and there would be no
- 2 -
difference between a logical and a physical line. The QUIT command
would serve quite well in terminating a block, and there are no
problems with the XEQUTE command. As the depth of a block is
specified unambiguously by its context, there are fewer problems in
determining legal control transfer points.
This method seems much more suited to the Mumps environment.
3. INVOCATION OF A BLOCK
3.1 Invocation via a new control element
This type of invocation is basically an extrinsic block. In the
implicit block context, it would be useful if one wished to invoke an
implicit block as an extrinsic function. Since $$labelref is being
used for extrinsic functions it would not be a great leap to use $$
as an extrinsic implicit block. This would provide a very useful
mechanism for implementing WHILE and UNTIL clauses along with BREAK
and CONTINUE control. For example:
;WHILE clause
F I=0:0 Q:while D $$
. ;code
;UNTIL clause
F I=0:0 D $$ Q:until
. ;code
;repeat until subroutine says stop
F I=0:0 Q:$$
. ;code
. QUIT $S(more:0,1:1)
;WHILE with BREAK and CONTINUE
F I=0:0 Q:(while!(I=-1)) SET I=$$ IF I=0 ;rest of line
. ;code
. QUIT $S(normal:0,break:-1,continue:1)
It is a simple matter to add parameter passing to this type of
invocation. This format is also useful because there is no need to
add extra control structures to the language in order to provide
WHILE, UNTIL, BREAK, and CONTINUE clauses. I prefer this type of
flow control because all the control logic is on the same line,
instead of "bracketing" the block. This is also more flexible than
ordinary WHILE and UNTIL structures.
Using explicit block boundaries one could place the start-of-block
indicator after any command. If these boundaries were restricted to
the IF, ELSE, and FOR command then WHILE, UNTIL, BREAK, and CONTINUE
clauses will have to be added to the language. Additionally, it is
- 3 -
difficult to pass parameters to an explicit block without additional
syntactic cruft. Indentation of lines within the block would be
discretionary. Closing boundaries could be placed anywhere a command
might be found, although if this were more restrictive it would be
easier to specify (at the cost of ease of use). Since this would not
be part of the DO command, specification of environment levels would
have to be addressed.
3.2 Invocation via the DO command
This method of entering a block seems to be the best. The rules for
environment control are well specified as is the method of leaving a
subroutine. It is possible to post-conditionalize the invocation.
Installation of block structuring using the DO command will require
fewer changes to the language.
4. THE DEC PROPOSAL
The only complaint I have with the DEC proposal is that I don't like
argumentless DOs. I would prefer to see '$$' or '.' as the argument.
This would, in my opinion, be easier to read, with or without a
post-conditional.
5. GENERAL ISSUES
What about $TEST? If we use implicit blocks with '$$' as the
trigger, we can use the definition of extrinsics as the foundation
and provide a consistent interface in a more generalized fashion.
------------------------------
Date: 20 May 85 22:04:15 CDT (Mon)
From: plus5!hokey
Subject: Problem with definition of fixed length reads
To: plus5!std-mumps
There is good reason why "the input message is a string whose length is
at most n characters, and which is terminated by an implementor-defined,
possibly device-dependent procedure...".
Different block mode terminals behave in different ways. Some of us believe
the read should (usually) terminate upon receipt of the n+1th non-edit
character, in order to permit people to edit input which occupies the
entire field. Once upon a time InterSystems used to CR/LF after the nth
character was output instead of upon the n+1th character. Somehow I
suspect I wasn't the only person requesting that change.
In any event, I would not choose to throw away the n+1th character.
The real answer is to give programmers the *option* to select a particular
behavior. I would probably *never* want to terminate the read upon receipt
of the nth character, but that is my preference. My code will be written
one way, and you should be able to write yours your way. There is room
for both in this case, so ask your vendor(s) to give you the option.
We might even try to standardize these options. Just think, then we can
go for some of the other beasts, like turning echo off and on!
Hokey
------------------------------
End of std-mumps Digest
******************************