Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!oakhill!val!aubrey
From: aubrey@val.UUCP (Aubrey McIntosh)
Newsgroups: comp.lang.modula2
Subject: Re: Termination code
Keywords: Circular references.
Message-ID: <313@val.UUCP>
Date: 31 Mar 89 16:15:24 GMT
References: <846.242C4BE0@dawggon.fidonet.org> <6354@medusa.cs.purdue.edu>
Reply-To: aubrey@val.UUCP (Aubrey McIntosh)
Organization: Video Associates Labs - Austin, TX
Lines: 79

In article <6354@medusa.cs.purdue.edu> rjh@cs.purdue.edu (Bob Hathaway) writes:

[edited heavily throughout.  Hope I preserved the correct flavor.]

>Anyway since I'm typing this in I'll bring up an issue which has been in the 
>back of my mind for a long time.  Modula restricts imports to a hierarchy,
>i.e. a tree.  To my knowledge, this precludes recursively defined abstract
>data types.  
>
>1.   >-------> table:  Create Initialize Lookup Insert Print
>     |          /|\    GetDefaultValue
>     |         / | \
>     |        /  |  \
>     |       /   |   \
>2.   |    list  tree  hash table ...:  Initialize Insert Lookup Print
>     |     /     |     \
>3.   ^__ ...    ...    ... :  objects
>
>Tables were to be implemented as abstract data types as were lists, trees,
>and hash tables.  Objects were abstract data types also and explicitly 
>referenced tables, resulting in a recursive definition.   
>
>Bob Hathaway
>rjh@purdue.edu

*Although* I have always made my DEF modules hierarchical, I view this
as a style.  In fact, as a benchmark of style, the first Modula-2 code
I wrote was very fuzzy about the distinction between DEF and MOD files,
and I went through considerable agony before it dawned on me that I
could import fairly freely into MOD files.  Please note that I don't
recommend doing that, because of the expense of changing the DEFs,
but it did come in handy on that first project.

Bob's article made me curious enough about this that I picked up a
copy of PIM2, 3rd corr., and broused a bit.  In the Report part, 
"chapter" 14, p169 (Compilation units), I find:

   (discussion about definition modules and implementation modules)
`  ... Opaque export is restricted to pointers ... '

`  As in local modules, the body of an implementation module acts
   as an initialization facility for its 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.
'

Additionally, in 4, p 146 (Declarations and Scope rules) I read
rules 1..3 as applicable...
    1.  If an identifier ... is used in another declaration ...
        then D1 must textually preceed D2.
    2.  A type T1 can be used in a declaration of a pointer type T
        which textually precedes the declaration of T1 if both are
        declared in the same block.  This is a relaxation of rule 1.
    3.  If an identifier ... is exported from compilation unit M1 ...
        the scope extends to all those units which import M1.



I admit that I haven't read PIM2 in its entirety since the first
edition, but I didn't find a prohibition in those places I would
first look.

As I type this, I believe that a simple circular reference among
DEF modules, where opaque types are used in subsequent definitions,
doesn't violate anything.  What's also going through my mind, is
that I also expect any implementation which compiles SYM files to
have an implementation restriction on this. :-(  Perhaps I will
go and try some contrived cases.   If I do put much more time into
this, I will use either the Logitech or the C18 compiler to check
things out, and one of the circular imports will have two versions
of the DEF file.

 
-- 
Whatcha' call a boomerang that doesn't come back?      --Lost--
--------------------------------------------------------------
1-(512)-346-5781 (v)                                Using Modula-2.     
Austin, TX 78759   ...!cs.utexas.edu![dell|oakhill|kvue]!val!aubrey