Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt.cs.cmu.edu!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.lang.modula2
Subject: Re: Tyro questions
Message-ID: <467@aw.sei.cmu.edu.sei.cmu.edu>
Date: Wed, 3-Dec-86 09:21:09 EST
Article-I.D.: aw.467
Posted: Wed Dec  3 09:21:09 1986
Date-Received: Wed, 3-Dec-86 20:13:46 EST
References: <4740@ism780c.UUCP>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu.UUCP (PUT YOUR NAME HERE)
Distribution: net
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 79

In article <4740@ism780c.UUCP> darryl@ism780c.UUCP (Darryl Richman) writes:
>
>I am a neophyte in Modula 2 land, so if these questions are simpleminded,
>please be patient with me.  I have Wirt's PIM2, edition 2 (I can't locate a
>copy of edition 3).
>
>1)  If I build an application with multiple modules, what, if anything, am
>I guaranteed about each module's initialization code?  (I've looked at
>several books and they either ignore the issue or say contradictory things).
>In particular, am I guaranteed any particular order of execution?  What
>happens if one module's initialization code bootstraps the application, but
>other modules haven't had a chance to execute yet?

[References are to PiM2, Third Edition.  Sections are as in the Report bound
 into the back of that edition]

  "As in local modules, the body of an implementation
   module acts as an initialization facility for local
   objects.  Before its execution, the imported modules
   are initialized in the order in which they are listed.
   If circular references occur among modules, their
   order of initialization is not defined" [Sect 14]

   I interpret this as meaning that, given the dependency
   graph of the program, the modules are initialized
   bottom-up, ie an IMPORTed module before any of its
   importers.

>2)  What did Wirt change from edition 2 to 3?  In particular, what does he
>say about NEWPROCESS, TRANSFER, and IOTRANSFER?  (My compiler, which is from
>ETH, does not supply these procedures and implies that they are not
>required.  Instead they have a process stacking paradigm that's not as
>powerful.)

   "A new process is created by a call to

	PROCEDURE NEWPROCESS (P:PROC; A:ADDRESS; n:CARDINAL; VAR p1: ADDRESS)

	P  denotes the procedure which constitutes the process
	A  is the base address of the process' workspace
	n  is the size of the workspace
	p1 is the result parameter.

   A new process with P as program and A as workspace of size n is assigned
   to p1.  This process is allocated, but not activated.  P must be a
   parameterless procedure declared at level 0.

   A transfer of control between two processes is specified by a call to

	PROCEDURE TRANSFER (VAR p1,p2: ADDRESS)

   This call suspends the current process, assigns it to p1, and resumes
   the process designated by p2...

   ... IOTRANSFER ... should be considered as PDP-11 implementation specific"
   [Sect 13]

   What Wirth calls a "process" is evidently a coroutine, and processes should
   be used as one would use coroutines.  However, since Modula procedures can
   keep internal state (using imported modules), you probably don't need
   coroutines as well.   

>3)  Is it really considered a feature of the language that, given frp is a
>function returning a pointer, the expression "frp()^.xyz" is not allowed and
>must be coded as "tempP := frp(); tempP^.xyz"?

   Yes, it is a feature.  The syntax of "assignment" requires a
   "designator" on the LHS, and the left part of a designator must
   be a "qualident", which can be only selected, indexed, or
   dereferenced.  Klaus screws up again.
>
>	    --Darryl Richman, INTERACTIVE Systems Corp.
>	    ...!cca!ima!ism780!darryl
>	    The views expressed above are my opinions only.

   Well, my opinion is that, for all its sillies, Modula-2 is the best
   systems implementation language available, and I wish you well with it.

Robert Firth