hokey@plus5.uucp (The Moderator) (05/21/85)
std-mumps Digest Mon, 20 May 85 Volume 1 : Issue 17
Today's Topics:
Activation blocks and block structuring
Problem with definition of fixed length reads.
----------------------------------------------------------------------
Date: Mon, 20 May 85 11:52:18 cdt
From: ihnp4!umn-cs!ncs-med!bi (Bob Isch)
Subject: Activation blocks and block structuring
To: umn-cs!ihnp4!plus5!std-mumps
> In the Routine Structure proposal, I would prefer to use an explicit
> symbol to initiate execution of an inner block:
>
> D[O] postcond L doargument
>
> doargument::= $ postcond
> entryref postcond
> labelref actuallist postcond
> @ expratom V L doargument
>
> Note that this permits the execution of the inner block to be controlled
> by a postcond.
>
> This scheme has the added benefit of making it easy to pass parameters to
> the inner block, if that capability is so desired. It also opens the way
> to the possibility of "extrinsic blocks", which would provide a tremendously
> powerful means of implementing control structures like REPEAT/UNTIL,
> DO/WHILE, CONTINUE, BREAK, and several combinations not available in
> other languages.
>
> The use of $ also has a convienient mnemonic tie with extrinsics, and "fits"
> with the heirarchical nature of Mumps.
I more or less agree with the above but would like to make some
observations. First use of the $ when not returning a value is
inconsistent with it's use elsewhere. Second, the block structuring
proposal could be extended nicely to handle all of the above cases
by allow a "DO {" type of syntax. (Sort of substituting the { for
the $ above). This allows the programmer to either have namespace
control within a block (ala PL/1) or not have it (ala Pascal). For
example:
if a=b {
... no funny symbol table stuff going on here
things like: goto error work in here
}
-or-
if a=b do {
n i,j
... local variables here
(not a good idea to branch in or out of here, but allowed)
}
And yes, we might even allow things like:
do { ... }(a,b,.c)
to pass in parameters. I suppose what hokey was suggesting (I think)
might be more along the lines of:
do {(a,b,c) ... }
and maybe:
s a=$${ ... }(a,.b)
A bit strange perhaps but consistent with other procedure calling since
the general form is:
DO what_to_do(params)
and $$what_to_call(params)
> Bob Isch:
>
> In your latest block structure proposal you limit the scope of the statement
> to a single line. I understand this is good because it limits the search
> to the same line for the closing symbol, but is the capability really
> useful in such a constrained environment?
Yes, it useful. The question is how useful. An interesting thing
to do is to compare the original proposal with the new (restrictive)
proposal. How many differences do you find in the specifications?
mod.lang.mumps questions:
How many people read this group? How many people are interested in
this group? Why is this a moderated group? Assuming enough interest
exists to warrent the group how about making it unmoderated, it's not
like it is likely to cause traffic jams on the net...
How about sending responses to hokey so he can summarize or post them
to the newsgroup?
--
Bob Isch -bi (612) 893-8137 ihnp4!umn-cs!ncs-med!bi
------------------------------
Date: Mon, 20 May 85 09:23:15 cdt
From: ihnp4!umn-cs!ncs-med!bi (Bob Isch)
Subject: Problem with definition of fixed length reads.
To: umn-cs!ihnp4!plus5!std-mumps
There is what I consider a serious problem with the definition of
the fixed length read in the current Mumps standard. The problem
is with the description of read lvn#intexpr on page I-43. The
second paragraph reads:
... Otherwise, 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, which may be
******************* ******** ******
the receipt of the nth character. ...
*** emphasis mine.
This seems to mean that there is no way for a programmer to write
portable code using the fixed length read. (unless provisions are
made for all possible implementation definitions). I have already
encountered two different interpretations for simple terminal input
in popular implementations. One terminates the read on the nth
character. The other terminates the read on the n+1st character
throwing away the n+1st character. The first interpretation is
probably preferred for a number of reasons including:
> it is probably the way most implementations will do it.
> it does not throw away a character (or require the character
to be retrieved via $z-something.)
> as a result it probably works better with many communications
protocols.
> it makes more intuitive sense for sequential file i/o.
I am not quite sure what the MDC was addressing with the device-dependent
clause above but it seems to me that it would be just as well to have
the fixed length read terminate under all the same circumstances as a
normal read (which is not well defined either but would probably be
considered device-dependent) plus receipt of the nth character.
Thus, I would like to propose that the following line be removed from
the above paragraph:
"an implementor-defined, possibly device-dependent procedure, which may be"
resulting in it reading:
... Otherwise, the input message
is a string whose length is at most n characters, and which is terminated by
the receipt of the nth character. ...
Other opinions?
--
Bob Isch -bi (612) 893-8137 ihnp4!umn-cs!ncs-med!bi
------------------------------
End of std-mumps Digest
******************************