5 Here are a number of syntactic conventions useful for programming in
11 * A line of code never exceeds 80 columns.
13 * Only split a syntactic entity across multiple lines if it doesn't fit on one line within 80 columns.
15 * Use alphabetical order wherever possible.
17 * Avoid redundant parentheses.
19 * When using `:`, there is no space before the colon, and a single space after it.
24 * Variables, record labels and type constructors begin with and use
25 small letters, using capital letters to separate words.
33 * Variables that represent collections of objects (lists, arrays,
34 vectors, ...) are often suffixed with an `s`.
42 * Constructors, structure identifiers, and functor identifiers begin
43 with a capital letter.
51 * Signature identifiers are in all capitals, using `_` to separate
63 * Alphabetize record labels. In a record type, there are spaces after
64 colons and commas, but not before colons or commas, or at the
65 delimiters `{` and `}`.
72 * Only split a record type across multiple lines if it doesn't fit on
73 one line. If a record type must be split over multiple lines, put one
84 * In a tuple type, there are spaces before and after each `*`.
91 * Only split a tuple type across multiple lines if it doesn't fit on
92 one line. In a tuple type split over multiple lines, there is one
93 type per line, and the `*`-s go at the beginning of the lines.
102 It may also be useful to parenthesize to make the grouping more
112 * In an arrow type split over multiple lines, put the arrow at the
113 beginning of its line.
121 It may also be useful to parenthesize to make the grouping more
130 * Avoid redundant parentheses.
132 * Arrow types associate to the right, so write
146 * Type constructor application associates to the left, so write
160 * Type constructor application binds more tightly than a tuple type,
172 (int list) * (bool list)
175 * Tuple types bind more tightly than arrow types, so write
192 * A core expression or declaration split over multiple lines does not
193 contain any blank lines.
195 * A record field selector has no space between the `#` and the record
211 * A tuple has a space after each comma, but not before, and not at the
212 delimiters `(` and `)`.
219 * A tuple split over multiple lines has one element per line, and the
220 commas go at the end of the lines.
229 * A list has a space after each comma, but not before, and not at the
230 delimiters `[` and `]`.
237 * A list split over multiple lines has one element per line, and the
238 commas at the end of the lines.
247 * A record has spaces before and after `=`, a space after each comma,
248 but not before, and not at the delimiters `{` and `}`. Field names
249 appear in alphabetical order.
253 {bar = 13, foo = true}
256 * A sequence expression has a space after each semicolon, but not before.
263 * A sequence expression split over multiple lines has one expression
264 per line, and the semicolons at the beginning of lines. Lisp and
265 Scheme programmers may find this hard to read at first.
274 _Rationale_: this makes it easy to visually spot the beginning of each
275 expression, which becomes more valuable as the expressions themselves
276 are split across multiple lines.
278 * An application expression has a space between the function and the
279 argument. There are no parens unless the argument is a tuple (in
280 which case the parens are really part of the tuple, not the
289 * Avoid redundant parentheses. Application associates to left, so
304 * Infix operators have a space before and after the operator.
312 * Avoid redundant parentheses. Use <:OperatorPrecedence:>. So, write
326 * An `andalso` expression split over multiple lines has the `andalso`
327 at the beginning of subsequent lines.
336 * A `case` expression is indented as follows
346 * A `datatype`'s constructors are alphabetized.
350 datatype t = A | B | C
353 * A `datatype` declaration has a space before and after each `|`.
357 datatype t = A | B of int | C
360 * A `datatype` split over multiple lines has one constructor per line,
361 with the `|` at the beginning of lines and the constructors beginning
362 3 columns to the right of the `datatype`.
372 * A `fun` declaration may start its body on the subsequent line,
385 * An `if` expression is indented as follows.
394 * A sequence of `if`-`then`-`else`-s is indented as follows.
407 * A `let` expression has the `let`, `in`, and `end` on their own
408 lines, starting in the same column. Declarations and the body are
421 * A `local` declaration has the `local`, `in`, and `end` on their own
422 lines, starting in the same column. Declarations are indented 3
434 * An `orelse` expression split over multiple lines has the `orelse` at
435 the beginning of subsequent lines.
444 * A `val` declaration has a space before and after the `=`.
451 * A `val` declaration can start the expression on the subsequent line,
457 if e1 then e2 else e3
463 * A `signature` declaration is indented as follows.
473 _Exception_: a signature declaration in a file to itself can omit the
474 indentation to save horizontal space.
486 In this case, there should be a blank line after the `sig` and before
489 * A `val` specification has a space after the colon, but not before.
496 _Exception_: in the case of operators (like `+`), there is a space
497 before the colon to avoid lexing the colon as part of the operator.
504 * Alphabetize specifications in signatures.
517 * A `structure` declaration has a space on both sides of the `=`.
524 * A `structure` declaration split over multiple lines is indented as
535 _Exception_: a structure declaration in a file to itself can omit the
536 indentation to save horizontal space.
548 In this case, there should be a blank line after the `struct` and
551 * Declarations in a `struct` are separated by blank lines.
570 * A `functor` declaration has spaces after each `:` (or `:>`) but not
571 before, and a space before and after the `=`. It is indented as
576 functor Foo (S: FOO_ARG): FOO =
582 _Exception_: a functor declaration in a file to itself can omit the
583 indentation to save horizontal space.
587 functor Foo (S: FOO_ARG): FOO =
595 In this case, there should be a blank line after the `struct`
596 and before the `end`.
HCoop / hcoop / debian / mlton.git / blob