Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site pur-phy.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxi!houxm!ihnp4!inuxc!pur-ee!CSvax:Pucc-H:Physics:hal
From: CSvax:Pucc-H:Physics:hal@pur-ee.UUCP
Newsgroups: net.lang
Subject: Re: Modula-2 faults - (nf)
Message-ID: <1034@pur-phy.UUCP>
Date: Fri, 30-Sep-83 12:40:52 EDT
Article-I.D.: pur-phy.1034
Posted: Fri Sep 30 12:40:52 1983
Date-Received: Mon, 3-Oct-83 05:35:28 EDT
References: <1891@hp-pcd.UUCP>
Organization: Purdue University Physics Dept.
Lines: 94

A few comments on some of the problems presented by Nathan Myers.
Note: I use the term Modula to mean Modula-2.

Problem 1:
 Predefined Proccesses module.

Reply:
One of the nice things about Modula (and C) is that you are not forced
to use the standard modules; you can "roll-your-own".

I'm fond of saying that "Modula provides 90% of Ada's function with
10% of the complexity".  One of the features Ada provides which is
lacking in Modula is exception handling.  Nathan's mention of SetHandler
points out that this can be provided in Modula without making it part of
the language.  I'm more encouraged.
=================================================================
Problem 2:
 Module dependencies not being explicit.

Reply:
By module dependencies not being explicit, I assume that what is meant is
that if module A imports from module B which imports from module C, then
module A's dependence on module C is not apparent from the text of module
A.  But note that this dependence is still available to the compiler since
when A is compiled and references B, the definition module for B must be
scanned by the compiler and hence dependence on C is visible.

A related problem that is giving me problems (since I'm writing a compiler)
is illustrated with the following example.  Assume modules A, B, and C
have the dependencies mentioned in the previous paragraph.

DEFINITON MODULE C;
EXPORT QUALIFIED Type1;

TYPE Type1 = (con1, con2, ...); (* or a record type *)

END C.

DEFINITION MODULE B;
FROM C IMPORT Type1;
EXPORT QUALIFIED Btype;

TYPE Btype = RECORD
		f1: Type1;
	     END;
END B.

Now let's concentrate on what identifiers are known in module A which
imports type Btype from B.  The language definition states that when
a record type is exported then the field identifiers are also exported.
But what about the types of those fields!?  Must Type1 be placed on the
export list of module B?  This problem is the same whether or not Type1
is imported in to B or defined in B, as long is Type1 is omitted from
the export list.  What's to be done?
======================================================
Problem 3:
 Interrupt priority scheme not adequate.

Reply:
Changing the priority of a module at runtime could be done with some
appropriately named routine imported from SYSTEM.  In any case no
changes to the language syntax are required if the module priority
is simply regarded as the module's initial priority.
======================================================
Problem 4:
 Standard module Processes.

Reply:
I think the "roll-your-own" method (writing your own Processes module)
solves this adequately.  In this case Modula-2 retreated a little from
"Modula" by removing the Processes primitives from the language.
This gives you the freedom to use your own schedluling algorithm.
=======================================================
Problem 5:
 Programmer control over variable sizes.  

Reply:
Can't "roll-your-own" here.  If Modula had operator overloading, as in
Ada, you could extend the numeric types without altering the language.
For my own compiler (MC68000), I side-stepped this one by making the WORD
size 32 bits.
==============================================

My reference is the "Report" as it appears in the book:
"Programming in Modula-2" by (you know who)
(New York: Springer-Verlag) 1982.

Have there been changes in language?  Do I need to go out and buy a new book?
Seems to me I heard something about "corrections" someplace.

				Hal Chambers
				Physics Dept.
				Purdue Univ.
				(...!pur-ee!pur-phy!hal)