Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!midway!iitmax!gkt
From: gkt@iitmax.iit.edu (George Thiruvathukal)
Newsgroups: comp.lang.modula2
Subject: Re: definition module loops
Message-ID: <1991May17.162223.5539@iitmax.iit.edu>
Date: 17 May 91 16:22:23 GMT
References: <9105161749.AA06495@ctc.contel.com>
Organization: Illinois Institute of Technology / Academic Computing Center
Lines: 28

In article <9105161749.AA06495@ctc.contel.com>, reid@CTC.CONTEL.COM (Tom Reid x4505) writes:

>                                      It is perfectly legitimate for two
> classes to exchange messages and thus, do mutual importation.  It is also
> legitimate for each module/class to initialize itself.

> The bottom line is that one should not disparage a construct just because
> one does not see a use for it.

Actually, I saw the "use" for it, but I disagree with the notion that the "use"
is all that useful.  Modules which are so tightly coupled should be collapsed
onto one module.  On further examination, I would suggest that what ought to be
disallowed are cycles which arise in the "import" graphs (whose nodes are both
definition and implementation modules) and edges are "imports."  Thus, two 
different modules (implementation parts) can borrow definitions and procedures
from each other.  However, their definition modules cannot do the same. It goes
without saying that this restriction is NOT severe, because there are no
mechanisms in Modula-2 for conditional compilation.

Thanks for your comments.  It is somewhat refreshing to see some positive and
scientific discussion occurring in this newsgroup.

-- 
George Thiruvathukal

Laboratory for Parallel Computing and Languages
Illinois Institute of Technology
Chicago