wyant@APOLLO.UUCP (Geoffrey Wyant) (02/18/86)
I'd like to generate some discussion on the proposals for extending
Modula-2 that were in the Feb. issue of Computer Language. My
personal opinion is that most of the proposals wre ill-considered
and unwarranted. The only reason I can see for extending a langauge
is when a commonly-used mechanism cannot not be simulated w/in the
language without a great deal of overhead or loss of generality.
1) Dynamic strings, Dynamic arrays: To have these imbedded in the
language forces the compiler writer to choose a representation
or call a run-time support function with a pre-chosen representation.
The chosen representation is almost always a compromise which works
well in the small case, but breaks down in the face of extremely
large strings/arrays, or strings with a high insertion/deletion
rate. A much better solution can be had using procedure variables
that lead to a representation independent mechanism for manipulating
dynamic strings/arrays. The only thing lost is some syntactic
nicities.
2) Exceptions: Here I think one could validly argue that modula-2
is difficient. There are several ways of handling the problem of
signalling exceptional conditions within the current modula-2
definition, but I don't find any of them particularly satisfying.
One way is to define a "setjmp/longjmp" mechanism.
One problem with this is that it provides no "I don't want to
handle this exception, so pass it on up the exception handler
chain" type of handling. Another problem is that it tends to
lead to non-modular code. The "jmpbuf" must be passed along the
entire call chain in order for this to be modular. In most
cases the exception will not be encountered, and so the
"jmpbuf" is just extra baggage. This leads most programmers
to make these global.
Another way is to define exception procedures that are passed
to routines to invoke on an error condition. There are 2
problems with this. One is the "extra baggage" problem from
above. The other problem is that these exception handling
procedures are not visually associated with the call that caused
the exception, and one usually winds up scampering through
pages of code looking for function definition.
I don't know what the right way of doing this is, but I would be
interested in more discussion.
3) Operator overloading: I'm sorry, but I find operator overloading
to be evil. It's the poor man's substitute for polymorphism. My
major objection is that one cannot tell where the defintion for a
given use of an operator can be found, and that it disguises
operations with widly differing semantics. In addition,
it makes compiler implementation that much harder without major
benefit. If you really require something like this, why not go that
extra step and define a variation on the language that provides
true polymorphism.
As a last note, are there some truely basic facilties that would greatly
enhance the power of modula-2 w/o adding substantially to language
complexity, compiler, or runtime complexity ?
Geoff Wyant
-------nagler%orb@SUN.ARPA (Rob Nagler) (02/25/86)
I'd like to generate some discussion on the proposals for extending
Modula-2 that were in the Feb. issue of Computer Language.
You ask for it, you get it. I agree with you on basic principles: Modula
is what it is, leave it alone! If you want to program in something else
do so, but don't make me change everything I have already written.
2) Exceptions: Here I think one could validly argue that modula-2
is difficient.
Negative. I think that Modula-2 did the smart thing. Leave it to a module.
If exceptions were in every system, then they would be used by everyone
for everything (a la Ada). If they are an exceptional construct, then
they only get used in exceptional circumstances (END_OF_FILE not being
one of them!).
One problem with this is that it provides no "I don't want to
handle this exception, so pass it on up the exception handler
chain" type of handling.
Why? The implementation suggestion that I sent to this mailing list
certainly allows this. You can either "re-Raise" the exception or
the exceptions module can export a "Defer" procedure.
Another problem is that it tends to lead to non-modular code.
The "jmpbuf" must be passed along the entire call chain in order
for this to be modular.
Well, this is true of any system which needs global data (file handles,
random number seeds, network connection ids, ...). Sorry, but this is
fact of life. It is true in any language that has implemented a general
exception mechanism. I really don't see this as a big problem. Where
do we use exceptions? Files module is a good example. If you were to
define the module as follows:
DEFINITION MODULE Files;
....
PROCEDURE GetException( f : File )
: Exceptions.Exception;
END Files;
Then only those modules which care about exceptions on that particular
file need to know about it or pass it along. However, this causes the
stupid problem with having to declare a handler for each file... So
you define it this way:
PROCEDURE GetException(): Exceptions.Exception;
and the exceptions module is defined to be:
DEFINITION MODULE Exceptions;
....
PROCEDURE Raise( exception : Exception;
code : ARRAY OF SYSTEM.BYTE );
...
PROCEDURE Catch( exception : Exception;
VAR code : ARRAY OF SYSTEM.BYTE );
END Exceptions;
so upon each invocation, there is a random value passed along to
the handler. Alas, where is the type checking? Nothing is
perfect, but any other standard structured language would not be
able to define a way of type checking parameters to an Exception
handler. You could put a set of procedures in the Files module
which did the checking for you, but that just sucks (kind of like
the I/O of opaque objects). My feeling is that exceptions are
an advanced topic (kind of like randomly accessable files) and
the hacker must be aware. Lest us lead the naive into the valley
of temptation....
3) Operator overloading: ... evil.
Yup.
As a last note, are there some truely basic facilties that
would greatly enhance the power of modula-2 w/o adding
substantially to language complexity, compiler, or runtime
complexity ?
Yes. Standardization and some quality implementations (w/ standard
IO libraries) ...
Rob "you get what you pay for" Nagler