🚀 go-pugleaf

In article <846.242C4BE0@dawggon.fidonet.org> Pat.Terry@p101.f19.n490.z2.fidonet.org (Pat Terry) writes:
>That is, Finish.SetTerminate(T : PROC) will install T in a stack of
>procedures that are called automatically, at least when the program ends
>normally or executes HALT.  It is still to be decided what will happen in
>other situations (eg when exceptions are raised, coroutines "stop" and so
>on).

Why should procedures be called at program termination?  When the program
ends all space and resources should be freed anyway.  I can see invoking
termination blocks at module scope exit for abstract state machines or 
initialization code for runtime elaboration of Adt (opaque variable)
declarations together with termination code for Adt scope exits but I don't
see any need for termination code at program exit.

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.  One solution is to nest all abstract data types within a module
and export them from a single interface (definition module) but the 
hierarchical restriction seems unnecessary.  For instance, the following
recursive structure was desired in a recently posted article:

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.  This requires a 
general graph and cannot be implemented hierarchically.  So for discussion,
is there a better solution than nesting modules of all self referencing Adts?
Are there any reasons for restricting compilation dependency *trees* to 
hierarchies?  I've forgotten to look at the Modula-3 report for Import 
dependencies, but I hope the hierarchical restriction has been revoked.

Bob Hathaway
rjh@purdue.edu