MSRS002@ECNCDC.BITNET.UUCP (10/01/87)
not be using any normal I/O modules, indeed, it may be some burried
program for which the term I/O doesn't really apply. Anyhow, the
module which was called outside its environment would take some sort
of exception.
It would be perfectly acceptable to allow this sort of call if the
procedure being called did not reference any variables global to itself,
except perhaps variables defined in the module itself.
Any thoughts on this matter?
R
Rec
Recurs
Recursive
Recursively yours,
Tom Ruby
MSRS002@ECNCDC
Modula allows a variable to be a procedure type, and that variable to
be assigned the "value" of different procedures. This is a very usefull
thing when making programs such as operating systems or I/O drivers, but
it leads to one question. Consider the following scrap of code:
PROCEDURE A ;
VAR
P : PROC ;
PROCEDURE B ;
VAR
X : CARDINAL ;
PROCEDURE C ;
BEGIN
X := 17 ;
END C ;
BEGIN
P := C ;
END ;
BEGIN
B ;
P ;
END A ;
Now, I realize this wouldn't compile because I forgot to say END B, but
once that was finished, what would you expect to happen at run time?
When procedure C assigns the value 17 to X, X does not exist because the
activation record for B does not exist.
I haven't actually tried this on any compilers, but I would expect the
same sort of "crash" as you get when you assign a value to a dereferenced
pointer after the pointer has been de-allocated, that is, you set some
word in memory to 17, and nobody really knows what word that is.
I can think of a device to catch this error, if it is considered an error.
Each procedure would be assigned a unique number by the compiler, and this
number would be placed in the activation record at run time. When a
procedure is entered, either directly or through a variable, it would check
the activation records for procedure numbers to check if it is in the proper
environment. If not, it would issue some sort of helpful ( please )
message, then terminate the program. Of course, in Modula, you're not
always sure what "Issue a Message" means since the application program mayavi@taux01.UUCP (Avi Bloch) (10/01/87)
In article <INFO-M2%87093023534491@UCF1VM> Info-Modula2 Distribution List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> writes: >Modula allows a variable to be a procedure type, and that variable to >be assigned the "value" of different procedures. This is a very usefull >thing when making programs such as operating systems or I/O drivers, but >it leads to one question. Consider the following scrap of code: > > > PROCEDURE A ; > VAR > P : PROC ; > PROCEDURE B ; > VAR > X : CARDINAL ; > PROCEDURE C ; > BEGIN > X := 17 ; > END C ; > BEGIN > P := C ; > END ; > BEGIN > B ; > P ; > END A ; > > >Now, I realize this wouldn't compile because I forgot to say END B, but >once that was finished, what would you expect to happen at run time? >When procedure C assigns the value 17 to X, X does not exist because the >activation record for B does not exist. > Maybe this is why Wirth states emphatically (Programming in Modula-2 ed. 3, pp. 82): To conclude, we emphasize the restriction that procedures that are assigned to variables or are passed as parameters, must not be declared local to any other procedure. Therefore any procedure represented by a procedure variable will reference only local variables or global variables. Note that in Pascal, which only has procedure parameters, this problem does not exist, since that at the point where the procedure is passed as a parameter to a subroutine, if the procedure is accessable then all the activation records it needs must exist and will continue to exist at least until the return from the subroutine. Therefore the restriction Wirth mentions regarding Modula-2 does not exist in Pascal. (I purposely used different terms, i.e. procedure and subroutine to differentiate between the called procedure and the procedure passed as a parameter). Avi Bloch National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007 Herzlia 46104, Israel (011-972) 52-522263 avi%taux01@nsc