The Oslo Modeling Language: An Introduction to "M"

This chapter is from the book 

1.2 Types

Expressions give us a great way to write down how to calculate values based on other values. Often, we want to write down how to categorize values for the purposes of validation or allocation. In M, we categorize values using types.

An M type describes a collection of acceptable or conformant values. We use types to constrain which values may appear in a particular context (for example, an operand, a storage location).

With a few notable exceptions, M allows types to be used as collections. For example, we can use the in operator to test whether a value conforms to a given type. The following expressions are true:

1 in Number
"Hello, world" in Text

Note that the names of the built-in types are available directly in the M language. We can introduce new names for types using type declarations. For example, this type declaration introduces the type name My Text as a synonym for the Text simple type:

type [My Text] : Text;

With this type name now available, we can write the following:

"Hello, world" in [My Text]

Note that the name of the type [My Text] contains spaces and is subject to the same escaping rules as the member names in entities.

While it is moderately useful to introduce your own names for an existing type, it’s far more useful to apply a predicate to the underlying type:

type SmallText : Text where value.Count < 7;

In this example, we’ve constrained the universe of possible Text values to those in which the value contains less than seven characters. That means that the following holds true:

"Terse" in SmallText
!("Verbose" in SmallText)

Type declarations compose:

type TinyText : SmallText where value.Count < 6;

The preceding is equivalent to the following:

type TinyText : Text where value.Count < 6;

It’s important to note that the name of the type exists so an M declaration or expression can refer to it. We can assign any number of names to the same type (for example, Text where value.Count < 7) and a given value either conforms to all of them or to none of them. For example, consider this example:

type A : Number where value < 100;
type B : Number where value < 100;

Given these two type definitions, both of the following expressions will evaluate to true:

1 in A
1 in B

If we introduce the following third type:

type C : Number where value > 0;

we can also state this:

1 in C

In M, types are sets of values, and it is possible to define a new type by explicitly enumerating those values:

type PrimaryColors { "Red", "Blue", "Yellow" }

This is how an enumeration is defined in M. Any type in M is a collection of values. For example, the types Logical and Integer8 defined next could be defined as the collections:

{ true, false }
{-128, -127, ..., -1, 0, 1, ..., 127}

A general principle of M is that a given value may conform to any number of types. This is a departure from the way many object-based systems work, in which a value is bound to a specific type at initialization-time and is a member of the finite set of subtypes that were specified when the type was defined.

One last type-related operation bears discussion—the type ascription operator “:”. The type ascription operator asserts that a given value conforms to a specific type.

In general, when we see values in expressions, M has some notion of the expected type of that value based on the declared result type for the operator or function being applied. For example, the result of the logical and operator “&&” is declared to be conformant with type Logical.

It is occasionally useful (or even required) to apply additional constraints to a given value—typically to use that value in another context that has differing requirements.

For example, consider the following simple type definition:

type SuperPositive : Number where value > 5;

And let’s now assume that there’s a function named CalcIt that is declared to accept a value of type SuperPositive as an operand. We’d like M to allow expressions like this:

CalcIt(20)
CalcIt(42 + 99)

and prohibit expressions like this:

CalcIt(-1)
CalcIt(4)

In fact, M does exactly what we want for these four examples. This is because these expressions express their operands in terms of simple built-in operators over constants. All of the information needed to determine the validity of the expressions is readily and cheaply available the moment the M source text for the expression is encountered.

However, if the expression draws upon dynamic sources of data or user-defined functions, we must use the type ascription operator to assert that a value will conform to a given type.

To understand how the type ascription operator works with values, let’s assume that there is a second function, GetVowelCount, that is declared to accept an operand of type Text and return a value of type Number that indicates the number of vowels in the operand.

Since we can’t know based on the declaration of GetVowelCount whether its results will be greater than five or not, the following expression is not a legal M expression:

CalcIt( GetVowelCount(someTextVariable) )

Because GetVowelCount’s declared result type Number includes values that do not conform to the declared operand type of CalcIt, which is SuperPositive, M assumes that this expression was written in error and will refuse to even attempt to evaluate the expression.

When we rewrite this expression to the following legal expression using the type ascription operator:

CalcIt( GetVowelCount(someTextVariable) : SuperPositive )

we are telling M that we have enough understanding of the GetVowelCount function to know that we’ll always get a value that conforms to the type SuperPositive. In short, we’re telling M we know what we’re doing.

But what if we don’t? What if we misjudged how the GetVowelCount function works and a particular evaluation results in a negative number? Because the CalcIt function was declared to accept only values that conform to SuperPositive, the system will ensure that all values passed to it are greater than five. To ensure this constraint is never violated, the system may need to inject a dynamic constraint test that has a potential to fail when evaluated. This failure will not occur when the M source text is first processed (as was the case with CalcIt(-1))—rather it will occur when the expression is actually evaluated.

Here’s the general principle at play.

M implementations will typically attempt to report any constraint violations before the first expression is evaluated. This is called static enforcement, and implementations will manifest this much like a syntax error. However, as we’ve seen, some constraints can only be enforced against live data and, therefore, require dynamic enforcement.

In general, the M philosophy is to make it easy for users to write down their intention and put the burden on the M implementation to “make it work.” However, to allow a particular M program to be used in diverse environments, a fully featured M implementation should be configurable to reject M program that rely on dynamic enforcement for correctness to reduce the performance and operational costs of dynamic constraint violations.

1.2.1 Collection Types

M defines a type constructor for specifying collection types. The collection type constructor restricts the type and count of elements a collection may contain. All collection types are restrictions over the intrinsic type Collection, which all collection values conform to:

{ } in Collection
{ 1, false } in Collection
! ("Hello" in Collection)

The last example is interesting, in that it illustrates that the collection types do not overlap with the simple types. There is no value that conforms to both a collection type and a simple type.

A collection type constructor specifies both the type of element and the acceptable element count. The element count is typically specified using one of the three operators:

T* - zero or more Ts
T+ - one or more Ts
T#m..n - between m and n Ts

The collection type constructors can either use operators or be written longhand as a constraint over the intrinsic type Collection:

type SomeNumbers : Number+;
type TwoToFourNumbers : Number#2..4;
type ThreeNumbers : Number#3;
type FourOrMoreNumbers : Number#4..;

These types describe the same sets of values as these longhand definitions:

type SomeNumbers : Collection where value.Count >= 1
                                    && item in Number;
type TwoToFourNumbers : Collection where value.Count >= 2
                                    && value.Count <= 4
                                    && item in Number;
type ThreeNumbers : Collection where value.Count == 3
                                    && item in Number;
type FourOrMoreNumbers : Collection where value.Count >= 4
                                    && item in Number;

In the case that value itself is a collection, an additional variable item is introduced into scope. The item variable ranges over the elements of value (which must be a collection). Clauses that use item must hold for every element of value.

Independent of which form is used to declare the types, we can now assert the following hold:

!({ } in TwoToFourNumbers)
!({ "One", "Two", "Three" } in TwoToFourNumbers)
{ 1, 2, 3 } in TwoToFourNumbers
{ 1, 2, 3 } in ThreeNumbers
{ 1, 2, 3, 4, 5 } in FourOrMoreNumbers

The collection type constructors compose with the where operator, allowing the following type check to succeed:

{ 1, 2 } in (Number where value < 3)*
  where value.Count % 2 == 0

Note that the where inside the parentheses applies to elements of the collection, and the where outside the parentheses operator applies to the collection itself.

1.2.2 Nullable Types

We have seen many useful values: 42, "Hello", {1,2,3}. The distinguished value null serves as a placeholder for some other value that is not known. A type with null in the value space is called a nullable type. The value null can be added to the value space of a type with an explicit union of the type and a collection containing null or using the postfix operator ?. The following expressions are true:

! (null in Integer)
null in Integer?
null in (Integer | { null } )

The ?? operator converts between a null value and known value:

null ?? 1 == 1
3 ?? 1 == 3

Arithmetic operations on a null operand return null:

1 + null == null
null * 3 == null

Logical operators, conditional, and constraints require non-nullable operands.

1.2.3 Entity Types

Just as we can use the collection type constructors to specify what kinds of collections are valid in a given context, we can do the same for entities using entity types.

An entity type declares the expected members for a set of entity values. The members of an entity type can be declared either as fields or as computed values. The value of a field is stored; a computed value is evaluated. All entity types are restrictions over the Entity type.

Here is the simplest entity type:

type MyEntity : Language.Entity;

The type MyEntity does not declare any fields. In M, entity types are open in that entity values that conform to the type may contain fields whose names are not declared in the type. That means that the following type test:

{ X = 100, Y = 200 } in MyEntity

will evaluate to true, as the MyEntity type says nothing about fields named X and Y.

Most entity types contain one or more field declarations. At a minimum, a field declaration states the name of the expected field:

type Point { X; Y; }

This type definition describes the set of entities that contain at least fields named X and Y irrespective of the values of those fields. That means that the following type tests will all evaluate to true:

{ X = 100, Y = 200 } in Point

// more fields than expected OK
{ X = 100, Y = 200, Z = 300 } in Point

// not enough fields – not OK
! ({ X = 100 } in Point)

{ X = true, Y = "Hello, world" } in Point

The last example demonstrates that the Point type does not constrain the values of the X and Y fields—any value is allowed. We can write a new type that constrains the values of X and Y to numeric values:

type NumericPoint {
  X : Number;
  Y : Number where value > 0;
}

Note that we’re using type ascription syntax to assert that the value of the X and Y fields must conform to the type Number. With this in place, the following expressions all evaluate to true:

{ X = 100, Y = 200 } in NumericPoint
{ X = 100, Y = 200, Z = 300 } in NumericPoint
! ({ X = true, Y = "Hello, world" } in NumericPoint)
! ({ X = 0, Y = 0 } in NumericPoint)

As we saw in the discussion of simple types, the name of the type exists only so that M declarations and expressions can refer to it. That is why both of the following type tests succeed:

{ X = 100, Y = 200 } in NumericPoint
{ X = 100, Y = 200 } in Point

even though the definitions of NumericPoint and Point are independent.

1.2.4 Declaring Fields

Fields are named units of storage that hold values. M allows you to initialize the value of a field as part of an entity initializer. However, M does not specify any mechanism for changing the value of a field once it is initialized. In M, we assume that any changes to field values happen outside the scope of M.

A field declaration can indicate that there is a default value for the field. Field declarations that have a default value do not require conformant entities to have a corresponding field specified. (We sometimes call such field declarations optional fields.) For example, consider this type definition:

type Point3d {
  X : Number;
  Y : Number;
  Z = -1 : Number; // default value of negative one
}

Because the Z field has a default value, the following type test will succeed:

{ X = 100, Y = 200 } in Point3d

Moreover, if we apply a type ascription operator to the value:

({ X = 100, Y = 200 } : Point3d)

we can now access the Z field like this:

({ X = 100, Y = 200 } : Point3d).Z

This expression will yield the value -1.

If a field declaration does not have a corresponding default value, conformant entities must specify a value for that field. Default values are typically written down using the explicit syntax shown for the Z field of Point3d. If the type of a field is either nullable or a zero-to-many collection, then there is an implicit default value for the declaring field of null for optional and {} for the collection.

For example, consider this type:

type PointND {
  X : Number;
  Y : Number;
  Z : Number?;        // Z is optional
  BeyondZ : Number*;  // BeyondZ is optional too
}

Again, the following type test will succeed:

{ X = 100, Y = 200 } in PointND

and ascribing the PointND to the value will allow us to get these defaults:

({ X = 100, Y = 200 } : PointND).Z == null
({ X = 100, Y = 200 } : PointND).BeyondZ == { }

The choice of using a nullable type versus an explicit default value to model optional fields typically comes down to style.

1.2.5 Declaring Computed Values

Calculated values are named expressions whose values are computed rather than stored. Here’s an example of a type that declares a computed value, IsHigh:

type PointPlus {
  X : Number;

  Y : Number;

// a computed value

  IsHigh() : Logical { Y > 0 }

}

Note that unlike field declarations which end in a semicolon, computed value declarations end with the expression surrounded by braces.

Like field declarations, a computed value declaration may omit the type ascription, as this example does:

type PointPlus {
  X : Number;
  Y : Number;
// a computed value with no type ascription
  InMagicQuadrant() { IsHigh && X > 0 }
  IsHigh() : Logical { Y > 0 }
}

When no type is explicitly ascribed to a computed value, M will infer the type automatically based on the declared result type of the underlying expression. In this example, because the logical-and operator used in the expression was declared as returning a Logical, the InMagicQuadrant computed value also is ascribed to yield a Logical value.

The two computed values we just defined and used didn’t require any additional information to calculate their results other than the entity value itself. A computed value may optionally declare a list of named parameters whose actual values must be specified when using the computed value in an expression. Here’s an example of a computed value that requires parameters:

type PointPlus {
  X : Number;
  Y : Number;
  // a computed value that requires a parameter
  WithinBounds(radius : Number) : Logical {
    X * X + Y * Y <= radius * radius
  }
  InMagicQuadrant() { IsHigh && X > 0 }
  IsHigh() : Logical { Y > 0 }
}

To use this computed value in an expression, you must provide values for the parameters:

({ X = 100, Y = 200 } : PointPlus).WithinBounds(50)

When calculating the value of WithinBounds, M will bind the value 50 to the symbol radius—this will cause the WithinBounds computed value to evaluate to false.

It is useful to note that both computed values and default values for fields are part of the type definition, not part of the values that conform to the type. For example, consider these three type definitions:

type Point {
  X : Number;
  Y : Number;
}
type RichPoint {
  X : Number;
  Y : Number;
  Z = -1 : Number;
  IsHigh() : Logical { X < Y }
}
type WeirdPoint {
  X : Number;
  Y : Number;
  Z = 42 : Number;
  IsHigh() : Logical { false }
}

Because RichPoint and WeirdPoint have only two required fields (X and Y), we can state the following:

{ X=1, Y=2 } in RichPoint
{ X=1, Y=2 } in WeirdPoint

However, the IsHigh computed value is only available when we ascribe one of these two types to the entity value:

({ X=1, Y=2 } : RichPoint).IsHigh == true
({ X=1, Y=2 } : WeirdPoint).IsHigh == false

Because IsHigh is purely part of the type and not the value, when we chain the ascription like this:

(({ X=1, Y=2 } : RichPoint) : WeirdPoint).IsHigh == false

the outer-most ascription that determines which function is called.

A similar principle is at play with respect to how default values work. Again, the default value is part of the type, not the entity value. When we write the following expression:

({ X=1, Y=2 } : RichPoint).Z == -1

the underlying entity value still only contains two field values (1 and 2 for X and Y respectively). Where default values differ from computed values is when we chain ascriptions. Consider this expression:

(({ X=1, Y=2 } : RichPoint) : WeirdPoint).Z == -1

Because the RichPoint ascription is applied first, the resultant entity has a field named Z whose value is -1; however, there is no storage allocated for the value. (It’s part of the type’s interpretation of the value.) When we apply the WeirdPoint ascription, we’re applying it to the result of the first ascription, which does have a field named Z, so that value is used to specify the value for Z—the default value specified by WeirdPoint is not needed.

1.2.6 Constraints on Entity Types

Like all types, a constraint may be applied to an entity type using the where operator. Consider the following type definition:

type HighPoint {
  X : Number;
  Y : Number;
} where X < Y;

In this example, all values that conform to the type HighPoint are guaranteed to have an X value that is less than the Y value. That means that the following expressions:

{ X = 100, Y = 200 } in HighPoint
! ({ X = 300, Y = 200 } in HighPoint)

both evaluate to true.

Now consider the following type definitions:

type Point {
  X : Number;
  Y : Number;
}
type Visual {
  Opacity : Number;
}
type VisualPoint {
  DotSize : Number;
} where value in Point && value in Visual;

The third type, VisualPoint, names the set of entity values that have at least the numeric fields X, Y, Opacity, and DotSize.

Because it is a common desire to factor member declarations into smaller pieces that can be easily composed, M provides explicit syntax support for this. We can rewrite the VisualPoint type definition using that syntax:

type VisualPoint : Point, Visual {
  DotSize : Number;
}

To be clear, this is just shorthand for the preceding long-hand definition that used a constraint expression. Both of these definitions are equivalent to this even longer-hand definition:

type VisualPoint {
  X : Number;
  Y : Number;
  Opacity : Number;
  DotSize : Number;
}

Again, the names of the types are just ways to refer to types—the values themselves have no record of the type names used to describe them.