Programming Language - Modern Types

Background

In my previous post I concluded that both Object Oriented and Function programming should be adopted in EK9.

In fact all instances of types in EK9 will be Objects, there will be no primitive types at all. This solves the 'Autoboxing' issues and requirements of mapping primitive values to Objects and vice versa. But means the compiler will have to work harder to produce efficient machine code.

This decision to use only Objects does have one profound effect however, unlike a primitive variable (that always has to have a value); EK9 will allow variables to be unset. This means that the Object is of a specific type but can have no meaningful value. This removes the need for NaN with floating points, it also means it possible to avoid the concept of null to some extent (but not quite 100%). It means that a Boolean can be true, false and unset/unknown.

The Types

The question now is what types to provide as part of the language and why?

Simple Types

Obviously it will be necessary to provide:

• Boolean
• Character
• String
• Integer
• Float

More complex types will also be required for any sort of meaningful processing, such as:

• Date
• Time
• DateTime

But when you think about dates and times there is also the obvious type of Duration that should also be provided. After all if EK9 is to provide operators developers will want to do 'operations' on dates and times with Durations.

So EK9 will include:

• Duration

More Sophisticated Types

If EK9 is to include the String type then it is almost essential to support regular expressions. While these can be complex, they are familiar to many developers and are really a modern essential component.

So EK9 will include:

• RegEx

While dates and times are reasonably modern concepts, Money is also widely used! It has a number of very specific and intricate processing issues associated with it. These mainly focus around varying decimals places, precision and rounding.

It should not be possible to add $100 to £100 for example. While both variables are of a Money type; they are not actually compatible without conversion to the same currency.

As EK9 is strongly typed then it must enforce this on:

• Money

The same sort of logic can be applied to Colour (Color) and Dimension. In particular Dimensions in different units are not compatible without conversion (you would not want to crash a space ship by accidentally mixing imperial and metric units would you?).

EK9 will include both:

• Colour
• Dimension

EK9 should include the concept of a Locale so that numbers, financial amounts, dates, times and money can all be formatted correctly based on a selected locale.

The EK9 built in types go beyond what most languages supply as built-in. But really most modern development needs some or all of these types.

Collection Types

Most programming languages need to provide specific types that can act as collections or containers for zero or more instances of a particular type.

EK9 will provide:

• Optional
• List
• Dict (Dictionary/Map)
• PriorityQueue

These will be Generic types that can be parameterised with another type or types. A List of Money or Optional of Dimension for example. But importantly as EK9 is strongly typed; a List of Integer is a fully different type to a List of Float (unlike Java there is no type erasure). But note it will not provide arrays.

Standard API Types

These built in types are really utility types, many of which provide some type of interface into the underlying operating system.

EK9 will include:

• Stdin, Stdout, Stderr
• FileSystem, TextFile
• EnvVars (environment variables)
• OS (Operating System)
• Signals

Networking APIs

Networking is a key capability for many programming language and EK9 will provide:

• UDP
• TCP
• HTTP

Conclusion

These are a minimal set of types a modern language could provide. Note these are not low level types. Byte and arrays are missing from EK9, only time will tell if low level Byte types should be included.

It could be argued that some of these types could/should have been provided via API's. But in terms of a basic starting point; these types should provide enough to get the language going.

Integer and Float will be 64bit values, there will be no other short, unsigned, long, 'long long' types.

The next blog will discuss flow control and exception/error conditions.