Paper announcement: What is a Recursive Module? [fwd]

Peter Schachte pets at cs.mu.OZ.AU
Wed Oct 21 11:57:13 AEST 1998


Thought you might be interested....


-- 
Peter Schachte                | The only thing that makes life possible is
mailto:pets at cs.mu.OZ.AU       | permanent, intolerable uncertainty; not
http://www.cs.mu.oz.au/~pets/ | knowing what comes next.
PGP: finger pets at 128.250.37.3 |     -- ursula K. Le Guin 


----- Forwarded message from Robert Harper <rwh at cs.cmu.edu> -----

From: Robert Harper <rwh at cs.cmu.edu>
To: types at cis.upenn.edu
MMDF-Warning:  Parse error in original version of preceding line at postoffice.srv.cs.cmu.edu
Subject: Paper announcement: What is a Recursive Module?
Date: Tue, 20 Oct 1998 13:30:49 -0400
Importance: Normal
Errors-To: types-errors at cis.upenn.edu

[----- The Types Forum, http://www.cis.upenn.edu/~bcpierce/types -----]

The following paper is available at URL
http://www.cs.cmu.edu/~rwh/papers/papers.html or
http://www.cs.cmu.edu/~crary/papers/index.html.


				What is a Recursive Module?

			  Karl Crary   Robert Harper   Sidd Puri

Hierarchical module systems are an effective tool for structuring large
systems.  The restriction to acyclic import dependencies inherent in such
systems can impede modular programming by forcing mutually-dependent
components to be consolidated into a single module.  Recently there have been
several proposals for module systems that admit cyclic dependencies, but it is
not clear how these proposals relate to one another, nor how one might
integrate them into an expressive module system such as that of Standard ML or
O'Caml.  To address this question we provide a type-theoretic analysis of the
notion of a recursive module in the context of the ``phase-distinction''
formalism for higher-order module systems.  We extend this calculus with a
recursive module mechanism and a new form of signature, called a
\emph{recursively-dependent signature}, to support the definition of recursive
modules.  These extensions are justified by an interpretation in terms of more
primitive language constructs.  This interpretation may also serve as a guide
for implementation.

Comments and suggestions are most welcome.

Bob Harper and Karl Crary


----- End forwarded message -----



More information about the developers mailing list