Many confusions about the syntax of SML seem to arise from the use of an interactive REPL (Read-Eval Print Loop) while trying to learn the basics of the language. While writing your first SML programs, you should keep the source code of your programs in a form that is accepted by an SML compiler as a whole.
The {{{and}}} keyword
It is a common mistake to misuse the and keyword or to not know how to introduce mutually recursive definitions. The purpose of the and keyword is to introduce mutually recursive definitions of functions and datatypes. For example,
fun isEven 0w0 = true | isEven 0w1 = false | isEven n = isOdd (n-0w1) and isOdd 0w0 = false | isOdd 0w1 = true | isOdd n = isEven (n-0w1)
and
datatype decl = VAL of id * pat * expr
(* | ... *)
and expr = LET of decl * expr
(* | ... *)
You can also use and as a shorthand in a couple of other places, but it is not necessary.
Constructed patterns
It is a common mistake to forget to parenthesize constructed patterns in fun bindings. Consider the following invalid definition:
fun length nil = 0 | length h :: t = 1 + length t
The pattern h :: t needs to be parenthesized:
fun length nil = 0 | length (h :: t) = 1 + length t
The parentheses are needed, because a fun definition may have multiple consecutive constructed patterns through currying.
The same applies to nonfix constructors. For example, the parentheses in
fun valOf NONE = raise Option | valOf (SOME x) = x
are required. However, the outermost constructed pattern in a fn or case expression need not be parenthesized, because in those cases there is always just one constructed pattern. So, both
val valOf = fn NONE => raise Option
| SOME x => x
and
fun valOf x = case x of
NONE => raise Option
| SOME x => x
are fine.
Declarations and expressions
It is a common mistake to confuse expressions and declarations. Normally an SML source file should only contain declarations. The following are declarations:
datatype dt = ... fun f ... = ... functor Fn (...) = ... infix ... infixr ... local ... in ... end nonfix ... open ... signature SIG = ... structure Struct = ... type t = ... val v = ...
Note that
let ... in ... end
isn't a declaration.
To specify a side-effecting computation in a source file, you can write:
val () = ...
Equality types
SML has a fairly intricate built-in notion of equality. See EqualityType and EqualityTypeVariable for a thorough discussion.
Nested cases
It is a common mistake to write nested case expressions without the necessary parentheses. See UnresolvedBugs for a discussion.
(op *)
It used to be a common mistake to parenthesize op * as (op *). Before SML'97, *) was considered a comment terminator in SML and caused a syntax error. At the time of writing, SML/NJ still rejects the code. An extra space may be used for portability: (op * ). However, parenthesizing op is redundant, even though it is a widely used convention.
Overloading
A number of standard operators (+, -, ~, *, <, >, ...) and numeric constants are overloaded for some of the numeric types (int, real, word). It is a common surprise that definitions using overloaded operators such as
fun min (x, y) = if y < x then y else x
are not overloaded themselves. SML doesn't really support (user-defined) overloading or other forms of ad hoc polymorphism. In cases such as the above where the context doesn't resolve the overloading, expressions using overloaded operators or constants get assigned a default type. The above definition gets the type
val min : int * int -> int
See Overloading and TypeIndexedValues for further discussion.
Semicolons
It is a common mistake to use redundant semicolons in SML code. This is probably caused by the fact that in an SML REPL, a semicolon (and enter) is used to signal the REPL that it should evaluate the preceding chunk of code as a unit. In SML source files, semicolons are really needed in only two places. Namely, in expressions of the form
(exp ; ... ; exp)
and
let ... in exp ; ... ; exp end
Note that semicolons act as expression (or declaration) separators rather than as terminators.
Stale bindings
Unresolved records
Value restriction
See ValueRestriction.
Type Variable Scope
See TypeVariableScope.