brownc@utah-cs.UUCP (02/01/86)
This is a message from a friend of mine; I *DID NOT* write this. However,
I *will* forward responses to him.
-----------------------------------------------------------------------------
There have been several proposals to extend Modula 2 to include exceptions.
I believe that extending the language is not needed. Below is a small
definition module that I think will take the place of the exceptions
proposed. The implementation module should not be difficult to write.
Most of it can be stolen from the setjmp and longjmp code for C. Of course
the implemenation module will be machine specific.
This code was inspired by Lisp's catch and throw. For those who are not
familar with lisp catch takes a tag (any atom) and an expression to evaluate.
If in the process of evaluating the expression a throw is executed, the
system goes hunting for the catch with the same tag. There is no
easy way to implement a tags in modula because each module may want to add
more tags. There are several possible solutions: use cardinals or integers
and have the user assure that the numbers are different between each different
case, or use strings.
Strings are attractive since they are much more descriptive that just a
number. Notice in the definition module below there is no dependence on the
size of the string. The implementation module may only use a limited size
string (e.g. only the first 32 chars are significant).
DEFINITION MODULE Exceptions;
EXPORT QUALIFIED CatchResult, Catch, Throw, Caught;
TYPE
CatchResult = (NormalExit, Thrown);
PROCEDURE Catch(tag: ARRAY OF CHAR; p: PROC): CatchResult;
PROCEDURE Throw(tag, prompt: ARRAY OF CHAR);
PROCEDURE Caught(tag: ARRAY OF CHAR): BOOLEAN;
END Exceptions.
One other nice feature is the function Caught. This allows the lower level
module to take care of the problem itself. Example:
IF Caught("DiskFull") THEN
Throw("DiskFull");
ELSE
WriteString("***** FATAL ERROR ***** The disk is full!");
HALT;
END; (* IF *)
I have not yet implemented the implementation module because I have not needed
exceptions.
I would like to some other discussion of proposed extentions to Modula 2.
In February's Computer Language there is a discussion of many extensions
to the language. In my opinion most of them are not needed. Any other
comments?
Jeffrey McArthur
------------------------------------------------------------------------------
End of forwarded message.
Eric C. Brown
UUCP: ...!{decvax, ihnp4, seismo}!utah-cs!brownc
ARPA: brownc@utah-cs.ARPAjipping@UIOWA.CSNET (Mike Jipping) (02/03/86)
Jeff -- via Eric Brown...
Maybe I'm just daft, but without an implementation, I fail to see how
these "exception" definitions will work on *general* implementations of
Modula-2. Sure, rigged versions of "setjmp" and "longjmp" on a UNIX version
of M2 will work, but how about a PC version? I'd sure like to hear your
ideas of implementing general versions of these routines (which look good
in the definition module). There just doesn't seem a way to do it in the
language definition for general implementations.
-- Mike Jipping
U of Iowa Dept. of CS
jipping@uiowa (via CSNet)
jipping%uiowa@CSNET-RELAY
(via ArpaNet)nagler%orb@SUN.ARPA (Rob Nagler) (02/03/86)
I would like to some other discussion of proposed extentions to Modula 2.
In February's Computer Language there is a discussion of many extensions
to the language. In my opinion most of them are not needed. Any other
comments?
I whole-heartedly agree. Instead of spending time changing the language,
people should be using their time to improve (or create) implementations
for the language as it stands. The exceptions module sent with the above
message is a perfect example of what Wirth wanted: extend the language
with modules not with features that must be implemented in the compiler.
RobRalph.Hyre@C.CS.CMU.EDU (Ralph W. Hyre Jr.) (02/03/86)
Only major problem I have with the proposal is the use of strings rather than
integers. I'd like to see integer error code numbers and string comments.
This allows the programmer maximum flexibility in interpreting the error
in the appropriate context.
The CLU language has something similar (better, in my opinion) to this,
exceptions have names and optional parameters, so that a routine to read
from an open file can return the error not_possible("protection violation")
or not_possible ("end_of_file"). With this proposal, the only thing that
might need to be standardized are the exception numbers.
- Ralph
-------info-modula-2@ucbvax.UUCP (02/03/86)
I was not happy with the Computer Language article since it gave only weak justification for its proposed extensions. More constructive would have been a list of functionality that is missing or inconvenient according to the current language definition, and an analysis of the least damaging solution. I've heard complaints from language designers that users and compiler writers really shouldn't be in the business of changing a language. Taken too literally, of course, this is silly, but there is a tendency to add a quick and dirty feature rather than think hard about how to use the existing language definition to accomplish the goal. I heard Wirth speak last February and he admitted that Modula-2 was not perfect, but he wholeheartedly disapproves of random extensions. As for exceptions, my impression is that the exception-handler of Ada is similar to the user-specified error procedures in the Volition libraries. Both schemes have the demerit of losing context -- you cannot patch up the problem and restart the offending block of code. --Bob Hofkin
brownc@utah-cs.UUCP (Eric C. Brown) (02/05/86)
In article <8602031436.27242@ur-cayuga.rochester.arpa> jipping@UIOWA.CSNET (Mike Jipping) writes: >Jeff -- via Eric Brown... > Maybe I'm just daft, but without an implementation, I fail to see how >these "exception" definitions will work on *general* implementations of >Modula-2. Well, the problem is that the IMPLEMENTATION of these modules are system-specific. For example, on the PC, you basically need to save and restore CS, IP, BP, and SP. Other registers may be necessary if your compiler caches constants in other registers. On the 68K, you need A7, PC, and whatever register your compiler uses for static links. Personally, I do not find it very difficult to write a Setjmp/Longjmp set of routines for a given processor, but these routines *must* be rewritten for each processor. Eric C. Brown brownc@utah-cs.ARPA ..!{ihnp4, decvax, seismo}!utah-cs!brownc