X-Comment1: #############################################################
X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs #
X-Comment3: # If this address does not work please ask your mail #
X-Comment4: # administrator to update your NRS & mailer tables. #
X-Comment5: #############################################################
> > | Our Haskell in Haskell compiler modules are often unavoidably mutually
> > | recursive. For small programs you may be right, but for large programs
> > | mutually recursive modules are almost inevitable:
> > |
> > | i) There's always some implementation limit
> > | on module size, even with a C compiler...
> > |
> > | ii) Readability or the need for separate working
> > | may demand that a large module be broken into parts.
> >
> > I'm not sure I buy this.
>
> Nor I. It looks like a confusion of module with compilation unit.
Certainly not. I said separate working, not separate compilation.
What I meant to say was "separate programming by multiple
programmers". I plead a headache caused by simultaneously studying
category theory and microcode :-)
The readability/abstraction issue is also independent of compilation
units. It may simply be more appropriate to define mutually-recursive
functions or abstract types in their own modules (example below).
> If the reason for allowing multual ref is to allow large modules
> to be broken up, a mechanism specifically for that purpose would
> be better.
That would also be nice, but it still doesn't eliminate the
need for mutually recursive modules.
The example I really had in mind was two programmers working on
a collection of mutually recursive definitions (e.g. a type-checker
with separately written modules for type-checking definitions and
expressions). Now the interfaces between the modules are well-defined,
and the separation is one of abstraction, not merely compilation
(it's not necessary for the module checking definitions to know
about local functions used when checking expressions or vice-versa).
Such a separation, and abstraction may also be desirable even if only
a single programmer is involved.
These are the interfaces for the relevant modules:
interface DataTypes where
data Type = ...
data Expr = ...
data Defn
interface TypeDefn where
import DataTypes(Type,Expr,Defn)
tcDefn :: Defn -> Type
interface TypeExpr where
import DataTypes(Type,Expr,Defn)
tcExpr :: Expr -> Type
The implementations of TypeDefn and TypeExpr may be written
independently.
Kevin
PS You could perhaps view a collection of mutually recursive
modules as a meta-module. Then the collection of meta-modules
which comprises a program is hierarchical (you might want
several levels of module structure). These meta-modules
correspond to your view of modules, I think.
