Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site cavell.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!alberta!cavell!mouli
From: mouli@cavell.UUCP (Bopsi ChandraMouli)
Newsgroups: net.lang.c
Subject: Re: Modula-2
Message-ID: <367@cavell.UUCP>
Date: Tue, 5-Feb-85 20:04:01 EST
Article-I.D.: cavell.367
Posted: Tue Feb  5 20:04:01 1985
Date-Received: Thu, 7-Feb-85 02:38:23 EST
References: <7969@brl-tgr.ARPA>
Reply-To: mouli@cavell.UUCP (Bopsi Chandramouli)
Organization: U. of Alberta, Edmonton, AB
Lines: 23
Summary: 

In article <7969@brl-tgr.ARPA> rfm <@csnet-relay.arpa,@tufts.CSNET (Richard F. Man):rfm@tufts.C writes:
>Since dan frank asked someone to read the book on modula-2 and comment on it,
>I may as well give my two cents' worth...
>1. IO in Modula-2 is terrible. It has to use different function for different
>	type of things you want to print out.

IO is not part of Modula-2 language definition. It is left to the 
implementation to decide on the IO Module. What Wirth has suggested
in his book is just one way of doing it.

>2. Import/Export violates the classical scope rule. It is exporting the name
>	of the function/procedure, not the actual function/procedure itself.

I don't think I understand what you mean by this.  The aim behind 
exporting the name of the procedure/function (along with the parameter
declarations) is for the compiler to check the type compatibility
of parameters statically. You can use the procedures/functions
without knowing what their actual implementations are.
Regarding scope,
you can achieve one more level of scope control using "local modules".

Bopsi Chandramouli.
U of Alberta.