We have attempted to follow a number of coding conventions to keep the
style of the code consistent.

========================================
Files
==========

We use all lower-case with "-" to separate words in a filename.  We
typically put one SML module/signature per file, but occasionally include
both a named signature and module in the same file.  We use a "-fn" suffix
for files containing functors and a "-sig" siffix for files containing
signatures.  Here are some examples

	simple.sml		contains structure Simple
	ssa-sig.sml		contains signature SSA
	ssa-fn.sml		contains functor SSAFn

Some files are generated by the configure script.  For these, we follow the
convention of "_suffix.in" as their suffix.  For example,

	run-dnorm_sml.in	produces run-dnorm.sml


========================================
Orthographic conventions
==========
We largely follow the orthographic conventions specified for SML Basis (and used
by the SML/NJ Library).

	1) Alphanumeric value identifiers are in mixed-case, with a leading
	   lower-case letter.

	2) Type identifiers are all lowercase, with words separated by "_".

	3) Signature identifiers are all upper case, with words separated by "_".

	4) Structure and functor identifiers are in mixed-case, with the initial
	   letters of words capitalized.

	5) Alphanumeric datatype constructors follow either the signature
	   convention (3) or the structure convention (4).


========================================
Indentation
==========

The basic unit of indentation is two spaces.  We indent indent the 'val' and
'fun' definitions of a 'let' expression at the same level as the 'in' and 'end'.
E.g.,
	let
	val x = ...
	in
	  ...
	end

If there is room, we usually put the 'let' on the same line as its parent.  E.g.,

	fun f x = let
              val y = ...
              in
                ...
              end

or

	if (x < 0)
	  then let
	    val y = ...
	    in
	      ...
	    end


========================================
Comments
==========

Each module should have a header comment that identifies the name of the file
and includes the copyright notice.  In an ideal world, the header comment will
also include information about what the code in the file does (but not how it does
it).

Types and functions is signatures should also be commented.

========================================
Miscellany
==========

Functions and data constructors that take multiple arguments of the same type (and
where the order is not obvious) should use a labeled record as their argument.

For case expressions, we "terminate" them with an "(* end case *)" comment.  E.g.,

	case e
	 of [] => ...
	  | x::xs => ...
	(* end case *)

<script type="text/javascript">//<![CDATA[
		function toggle_ffErrors() {
			var errorsblock = document.getElementById("ffErrorsBlock");
			var errorsgroup = document.getElementById("ffErrors");
			if (errorsblock.style.display == "none") {
				errorsblock.style.display = "block";
				errorsgroup.style.right = "10px";
			} else {
				errorsblock.style.display = "none";
				errorsgroup.style.right = "300px";
			}
		}
//]]></script>
<div id="ffErrors">
<a href="javascript:toggle_ffErrors();">Click to toggle</a>
<div id="ffErrorsBlock">
	<div class="error">does not end with &lt;/html&gt; tag</div>
	<div class="error">does not end with &lt;/body&gt; tag</div>
	<div class="info">The output has ended thus: m with an &quot;(* end case *)&quot; comment.  E.g.,

	case e
	 of [] =&gt; ...
	  | x::xs =&gt; ...
	(* end case *)</div>
</div></div>
</body></html>