Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!lll-lcc!ucdavis!ucbvax!info-modula-2
From: wyant@APOLLO.UUCP (Geoffrey Wyant)
Newsgroups: net.lang.mod2
Subject: re: modula-2 language extensions
Message-ID: <8602200448.AA20221@uw-beaver.arpa>
Date: Tue, 18-Feb-86 09:00:17 EST
Article-I.D.: uw-beave.8602200448.AA20221
Posted: Tue Feb 18 09:00:17 1986
Date-Received: Wed, 26-Feb-86 20:10:05 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 62

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

-------