SML/NJ Error and Warning Messages

The expression following the raise keyword should evaluate to an exception value, i.e. a value of type exn. In this case, the value has some other, inappropriate type. E.g.:

In a datatype replication declaration, neither the type name on the left hand side nor the type path (longid) on the right hand side should be preceeded by formal type variable arguments, even if the right hand side datatype is of arity n>0.

This occurs when an formal parameter pattern is not supplied on the left hand side in a fun declaration, or one of the formal parameters of an infix function symbol is missing.

The case object is the expression following the case keyword. It’s type must agree with the type of the lhs patterns in the rules (pat ⇒ exp) following the of keyword. All the patterns of the rules also have to agree in type, but that is another error.

In a fun definition, the function name must appear in each clause. If it is omitted from one or more clauses, this error results.

This error is also reported when the function name in two clauses of the function definition differ, for instance because of a misspelling.

In a fun declaration, each clause, or rule, separated by | (vertical bar symbol), has to have the same number of curried arguments.

A constant constructor like nil can’t be applied to an argument in a pattern.

A nonconstant constructor in a pattern must be applied to an argument pattern of the appropriate type (i.e. the domain type of the constructor).

A nonconstant constructor must be applied to an argument when it is used in a pattern (though not necessarily when it is used in an expression).

Usually occurs because the constructors for a datatype declared in a structure don’t agree with the constructors (in names or number) of the corresponding datatype spec in a signature with which the structure is matched.

The names of the constructors of a given datatype must all be distinct.

The instantiate process takes a signature and creates a dummy structure matching that signature with no extraneous sharing (i.e. no types are identified that don’t need to be). This process can fail because of various kinds of circularities. An example of one of the simpler forms of circularity would be:

By default, every signature is instantiated when it is declared, to detect errors as early as possible. However, signature instantiation is strictly only necessary when a signature is used as a functor parameter signature or in an opaque (:>) signature constraint.

A signature should have only one specification of a given value or constructor name. A common way that multiple constructor specifications for a name can occur is if a constructor is specified explicitly, and also implicitly through an included signature.

An exception name is declared multiple times in a single exception declaration.

Note that it is ok if the same exception name is declared in different exception declarations, as in the following.

When declaring several functions in a single val rec declaration, the names of the functions must be distinct.

When declaring several functions in a single fun declaration, the names of the functions must be distinct.

The label names in a record expression or pattern must be distinct.

Only one specification for a given name in a given name space is allowed in signatures. Values and constructors (including exception constructors) are in one name space; types, structures, and functors are disjoint name spaces. So x cannot be specified twice as a value or constructor, but it can be specified as a value, as a type, as a structure, and as a functor in the same signature.

Multiple specifications for a functor name occur in a signature, with one of the later ones introduced via an include spec. If the included functor spec comes first, you get error [19] instead.

Multiple specifications for a structure name occur in a signature, with one of the later ones introduced via an include spec. If the included structure spec comes first, you get error [19] instead.

Multiple specifications for a type name occur in a signature, with one of the later ones introduced via an include spec. If the included structure spec comes first, you get error [19] instead.

A type name is defined twice in a single simultaneous type declaration (i.e. type declarations separated by and. If the simultaneous declaration is split into separate declarations, there is no error.

A type name is defined multiple times in a datatype declaration (including possibly in the withtype part.

A type variable name is repeated in a type parameter list, when defining an n-ary type or datatype constructor, or explicitly binding types in a value declaration.

Multiple specifications for a value name occur in a signature, with one of the later ones introduced via an include spec. If the included structure spec comes first, you get error [19] instead. It does not matter whether the multiple value specifications give the same type or not.

A variable may only occur once in a pattern (or in the sequence of argument patterns of a curried function declaration.

A type variable used in a type constraint within a value expression or declaration must be generalized at the appropriate point (determined either explicitly or implicitly). If the type variable cannot be generalized at that point because of the value restriction, this error message results.

The type of the right hand side of the each rule in an exception handler must agree with the type of the base expression that the handler is attached to, because the value returned by the entire handle expression is either that of the base expression or the value returned by one of the handler rules.

An infix identifier cannot be the first identifier in an expression, unless it is preceded by the op keyword.

An expression cannot end with an infix identifier. Perhaps there is a missing op keyword.

This one is obvious. When defining new infix operators, you have to fit them into the existing precedence ranking, which is limited to ten levels, from 0 to 9, with higher numbers giving stronger precedence. See the Top Level Environment chapter of the Basis documentation for the precedences of the predefined infix operators.

In a context where an exception constructor identifier was expected, a dataconstructor identifier was found instead.

In a context where an exception constructor identifier was expected, a value variable was found instead.

In the rules following the handler keyword, the type of the patterns on the left hand side the rule must be exn. In the example below, the first error message is caused by a mismatch with an implicit default rule that handles exceptions not handled by the explicit rules of the handler.

In a datatype replication specification in a signature, type parameters were found on the left hand side of the specification.

The value variable in front of the as keyword can have a type constraint, but only one. This error also occurs in other circumstances, as illustrated by the second example.

In a function declaration, the left hand side between the keyword fun and the equal sign must be a well-formed applicative term, and the operator (i.e. the function part of the top-level application) of this term must be a simple identifier. If the application has an infix operator, it must be parenthesized (unless followed immediately by a type constraint or the equal sign); otherwise it may not be parenthesized.

Two types involved in a type sharing constraint have different arities.

This error occurs when type constructors with incompatible equality properties are equated by sharing constraints. When this happens, the signature is not consistent, and could not be successfully matched.

A function symbol declared to be an infix symbol is used in a function declaration used to declare nonfix functions.

The correct definition is:

The first term following keyword fun in a function declaration is a parenthesized application, implying an infix application, but the middle subterm is not an infix symbol.

In a val rec declaration, the if the identifier being declared (on the left hand side of the declaration) is an infix symbol, it must be preceeded by the op keyword.

The function Compiler.PPTable.install_pp installs a user-defined pretty printer function (the second argument) for a generative (i.e. datatype or abstype) designated by the first argument, which must be a nonempty list of strings that can be interpreted as a symbolic path (longTyCon) naming a datatype or abstract type in the current environment. This function should only be called at top level.

The function Compiler.PPTable.install_pp installs a user-defined pretty printer function (the second argument) for a generative (i.e. datatype or abstype) designated by the first argument, which must be a nonempty list of strings that can be interpreted as a symbolic path (longTyCon) naming a datatype or abstype in the current environment. This function should only be called at top level.

Integer literal in program is too large. Default integers are represented using 31 bits, and range from ~1073741824 to 1073741823, or from:

Insufficient patterns in clause to match against all the possible inputs. This is an error if the flag Compiler.Control.MC.matchNonExhaustiveError is set to true (the default is false), otherwise it is a warning if Compiler.Control.MC.matchNonExhaustiveWarn is set to true. If neither of these flags is true, then the compiler does not complain about nonexhaustive matches.

A pattern is provided that is covered by some earlier pattern. If the compiler flag Compiler.Control.MC.matchRedundantError is set to false (the default is true), only a warning message is given. If Compiler.Control.MC.matchRedundantWarn is also false (the default is true), no message is generated.

A pattern is provided that is covered by some earlier pattern, and the set of patterns do not cover all the possible inputs. Whether this message is generated, and its severity (Error or Warning), are controlled by the compiler flags

Example:

The where clauses of a signature expression must not bind (specify) the same type constructor name multiple times.

or even:

The value applied to an argument in a pattern is not a constructor.

Same error as [58]. This particular error occurs when the applied value has a name that can be reported.

A structure participating in a structure sharing specification was not declared in the current signature.

A type participating in a type sharing specification was not declared in the current signature.

A function (operator) is applied to a value (operand) with a type different than the type expected by the function.

The value used in operator position is not a function.

In a pattern that uses <it>or-ed</tt> subpatterns (via |), the type of all the subpatterns must agree.

A word literal used in a pattern is larger than the largest representable word.

An overloaded variable is being instantiated at a type for which it has no definition. Typical overloaded variables include numerical operations, overloaded over the numerical types (int, word, etc.)

In a fun declaration, each clause, or rule, separated by | (vertical bar symbol), has to have the same type (both in the type accepted by the clauses, and the type returned by the clauses).

In an "as"-pattern pat as pat, where the pattern to the left of the "as" is a simple variable, the variable must not be wrapped in parentheses.

In a pattern, the type of the pattern and the constaint type of the pattern must agree.

In a declaration val pat = exp, the type of pat must match the type of exp.

In a declaration val pat = exp, the type of pat must match the type of exp.

In an "as"-pattern pat as pat, the first pattern must be a simple variable, not a more complex pattern using tuples or data constructors.

In an as-pattern `pat as pat, the first pattern must be a simple variable, not a compound pattern constructed with tuples or data constructors.

When a signature contains a sharing constraint between two structure-specifications, each of which is specified using a where clause, the compiler is unable to calculate whether the structures are compatible. This is a bug in the compiler and will be fixed in a future version.

A real literal must have an exponent in the proper range for the floating-point representation of the target machine. At present all SML/NJ target machines use IEEE double-precision floating point, so real literals must be in the range ~1.79769313486e308 to 1.79769313486e308.

At present, a bug in the compiler raises an exception instead of printing the appropriate error message. [CHECK!]

An identifier bound as a data constructor cannot be rebound as a variable in a pattern.

In a multi-clause pattern match, if one of the later patterns can only match cases that are covered by earlier patterns, then the later pattern is redundant and can never be matched. In SML '97 it is an error to have useless (redundant) patterns.

The where clauses of a signature expression must not bind the same structure-specification to different structures.

The declaration

that binds the name id1 to the existing datatype id2, requires that id2 must be a datatype, and not an ordinary type.

The specification

that binds the name id1 to the existing datatype id2, requires that id2 must be a datatype, and not an ordinary type.

The body of (each clause of) a function must have the type specified in the function-result type constraint (if it is present).

A structure cannot share with one of its components.

Functors in SML/NJ may be higher-order, so that the functor F in the example below returns (as its result) another functor, which in turn returns a structure. The result of applying F to an argument cannot, therefore, be bound to a structure name.

This message is produced if the parser finds a syntax error and is unable to correct the problem using its built-in error correction heuristics (deletion, insertion, or replacement of tokens). Example:

Note: Error correction in the parser relies on lookahead. Different amounts of lookahead are used depending on whether input is taken from the interactive toplevel or from a source file. Therefore, error messages for the same program can vary depending on circumstances. (See also the note on error [78].)

This message indicates that the error-correcting parser attempted to rectify a syntax error by deleting (ignoring) some input token(s).

For example, let’s assume that file delete.sml contains the following code:

Compiling this file produces:

Note: Error correction in the parser relies on lookahead. Different amounts of lookahead are used depending on whether input is taken from the interactive toplevel or from a source file. Therefore, error messages for the same program can vary depending on circumstances. (See also the note for error 78..)

This error message, like the previous one, is generated by SML/NJ’s error-correcting parser. It indicates that the parser was able to correct a syntactic error by inserting an additional token.

For example, let’s assume that file insert.sml contains the following code:

Compiling this file produces:

Note: Error correction in the parser relies on lookahead. Since the interactive parser cannot use lookahead, it is likely that its syntax error messages differ from those that are generated when compiling files. For example, typing the contents of insert.sml directly into the interactive toplevel produces:

The parser found a syntax error and has attempted to fix the problem by replacing some token(s) by some other token(s).

For example, let’s assume that file replace.sml contains the following code:

Compiling this file produces:

Note: Error correction in the parser relies on lookahead. Different amounts of lookahead are used depending on whether input is taken from the interactive toplevel or from a source file. Therefore, error messages for the same program can vary depending on circumstances. (See also the note for error 78.)

The arity of a type constructor differs between the definition inside a structure and its declaration in the corresponding signature constraint.

Example:

This message indicates that the signature constraint for a given structure requires some type to be a datatype but the structure defines it as different type (i.e., not a datatype).

Example:

This error message is issued when the definition for some type inside a structure does not permit equality while the corresponding signature constraint for the structure specifies that type as an eqtype.

Example:

Names that are defined using val rec must refer to function values. Therefore, their types must be function types.

Example:

This error message occurs when a declaration has the form

and the types ty1 and ty2 disagree.

A type constructor was used with the wrong number of type arguments.

Example:

This message indicates that different occurences of the same type variable have inconsistent equality properties. In practice this means that the same name of a type variable was used both with one apostrophe and with two apostrophes. (Note that this would have been ok if the two occurences are clearly separated by scope.)

Example:

But:

Exception declarations in signatures cannot contain type variables.

Example:

Exception definitions at top level cannot contain type variables.

Example:

The right-hand sides of the rules in a match must agree in type. Matches occur both in case- and in fn-expressions.

Examples:

This error message is related to SML/NJ’s higher-order module extension to Standard ML. The constraint on a functor declaration in some signature uses an undefined functor signature name.

Example:

The name of the functor being used is not defined.

Example:

A where specification refers to a structure inside a signature that was not declared there.

Example:

But:

A where type specification refers to a type inside a signature that was not declared there.

Example:

But:

A signature name is used but it has not been defined; for instance S in the following example:

A structure name is used but it has not been defined; for instance B in the following example:

A type constructor name is used but it has not been defined, for instance t in the following example:

A type variable occurs on the right hand side of a type or datatype declaration, without having been bound as a formal parameter on the left hand side.

A value variable or constructor is used without having been defined or bound as a formal parameter.

When a flexible record pattern (one containing …​) is used, the context must provide enough type information to determine what all the fields are (though not necessarily their types).

If more than one field occurs in the flexible record pattern, then a different variant of this error message is generated. See error [100].

The pattern in a pattern match was a flexible record. The pattern omitted some of the record’s members and summarized their existence using ellipses ("…​"). But in the given context there was not enough information for the type checker to be able to infer the missing field names.

A value component of a structure has a different type than that specified in a signature that the structure is matched against.

SML/NJ supports or-patterns, where a single rule can have several patterns separated with the | symbol. The component patterns of an or-pattern are required to have exactly the same variables with the same types.

Here the component patterns are nil and x::_, and the variable x doesn’t occur in the first pattern.

A symbolic path (longid) of length greater than 1 occurring in a pattern must designate a data constructor.

In a vector expression of the form #[exp1,exp2,…​], all the vector element expressions must be of the same type.

In a vector pattern of the form #[pat<sub>1</sub>,pat<sub>2</sub>_,…​], all the vector element patterns must be of the same type.

SML/NJ does not allow multiple definitions of a structure in a signature (one through a definitional spec, another through a where clause).

The arity implied by a where type definition must agree with the arity in type specification that it applies to.

SML/NJ does not allow multiple definitions of a type in a signature (one through a definitional spec, another through a where type clause).

One can’t attach a withtype clause to a datatype replication declaration or specification.

Word constants (by default Word31.word) are limited to values less than 0w2147483648 (0wx80000000). Similarly for word literals of type Word32.word (bound 0w4294967296) and Word8.word (bound 0w256).

Insufficient patterns in clause to match against all the possible inputs. This is an warning if the flag Compiler.Control.MC.matchNonExhaustiveError is set to false (the default), Compiler.Control.MC.matchNonExhaustiveWarn is set to true. If neither of these flags is true, then the compiler does not complain about nonexhaustive matches.

A pattern is provided that is covered by some earlier pattern. This is a warning if the compiler flag Compiler.Control.MC.matchRedundantError is set to false (default is true) and Compiler.Control.MC.matchRedundantWarn is true (the default).

A pattern is provided that is covered by some earlier pattern, and the set of patterns do not cover all the possible inputs. Whether this message is generated, and its severity (Error or Warning), are controlled by the compiler flags

If the first two are set to false and the latter two are set to true, then this warning is generated.

If an infix expression like

involves two infix operators id1 and id2 of the same precedence but opposite associativity, the SML '97 Definition states that the expression is illegal. But SML/NJ only issues this warning message and associates the two operators to the left.

This warning is given for a top level value declaration whose type has free type variables that cannot be generalized because of the value restriction.

In this example, the right hand side of the declaration of x has type 'X list, where 'X is a free type variable. This type variable cannot be generalized to form a polymorphic type for x because the right hand expression is expansive (a function call in this case). So the compiler eliminates the free type variable 'X be inventing a new dummy type named X1 and instantiates 'X to X1. Since X1 won’t match any other type, there is little one can do with x now (one could take its lenght (0), but one cannot cons any values onto x).