Each of these examples assume the usage of --strict mode in Typescript
Can be implemented using “Custom Types” https://guide.elm-lang.org/types/custom_types.html
type Size = Small | Medium | Large
size = MediumA custom type where none of the variants have any attached data is essentially an enum.
You'll get an error if you make a typo:
size = SamllI cannot find a `Samll` constructor:
19| size = Samll
^^^^^
These names seem close though:
Small
False
LT
Large
You wouldn't get a compiler error if you just used a String.
Can be implemented with either:
https://www.typescriptlang.org/docs/handbook/enums.html
enum Size {
Small,
Medium,
Large,
}
const size = Size.Medium;https://www.typescriptlang.org/docs/handbook/advanced-types.html
type Size = "small" | "medium" | "large"
const size = "medium"There are lots of different names for these things in different programming languages. Naming things must be really hard. These things are like enums, but each variant can have data of any type attached to it.
Now called a "Custom Type". Was called a “Union Type” prior to Elm 0.19. https://guide.elm-lang.org/types/custom_types.html
A example showing that custom type variants can either have no data attached (Anonymous), data of the same type as another variant (Regular and Visitor), or data of a different type (Autogenerated):
type User =
Anonymous
| Regular String
| Vistor String
| Autogenerated Int
user = Visitor "HAL 9000"
Called "Discriminated Union Types"
type User = Regular | Visitor | Anonymous | Autogenerated;
interface Anonymouse {
kind: "regular";
}
interface Regular {
kind: "regular";
name: string;
}
interface Visitor {
kind: "visitor";
name: string;
}
interface Autogenerated {
kind: "visitor";
name: number;
}
const user = { kind: “visitor”, name: “HAL 9000” }Both the Elm and and Typescript compilers can check whether you've handled every possible case of an enum or union type.
Exhaustiveness checking in Elm is opt-out
type User =
Regular String
| Visitor String
sayHello user =
case user of
Regular name ->
"hello " ++ name
sayHello (Visitor "hal")The compiler will not allow this. You must handle every possible case. The compiler will throw this error:
This `case` does not have branches for all possibilities:
25|> case user of
26|> Regular name ->
27|> "hello " ++ name
Missing possibilities include:
Visitor _
I would have to crash if I saw one of those. Add branches for them!
You opt out and cheat the compiler by providing a catch all case. The Seinfeld version:
sayHello user =
case user of
Regular name ->
"hello " ++ name
_ ->
"hello you"
sayHello (Visitor "Hal")
-- returns "hello you"
Exhaustiveness checking in Typescript is opt-in
The following code will not throw any compiler errors, but this function
can unexpedectly return null at runtime, which would likely result
in a runtime error somewhere.
function sayHello(user: User) {
switch (user.kind) {
case "regular":
return "hello" + user.name;
}
}
sayHello({ kind: "visitor", name: "Hal"}) // this will return nullIf you provide a default switch case and assert that this branch will not be reached, the compiler will provide a compile-time error.
function sayHello(user: User) {
switch (user.kind) {
case "regular":
return "hello" + user.name;
default:
return assertNever(user.kind);
}
}
sayHello({ kind: "vistor", name: "Hal"})
function assertNever(x: never): never {
throw new Error("Unexpected object: " + x);
}The following Typescrip error will be provided:
Argument of type '"visitor"' is not assignable to parameter of type 'never'.
Note that you can also use if else statements instead of a switch statement, but you’ll need to remove the unreachable case once you have fulfilled each option, or you’ll get a compiler error. So, for that reason, switch statements are preferable if you want exhaustiveness checking - which you do ;)
Sometimes you might want a type that can be one of a set of primitive types, such as a number or a string.
type Height = String | IntThis is invalid and will not compile.
If you want to do this you'd need to (somewhat awkardly) tag each option:
type Height =
HeightString String
| HeightInt Int
height = HeightString "150"
-- or
height = HeightInt 150type Height = number | string;
height = 150;
//or
height = "150"
In elm, an object with a fixed set of fields is called a "Record" (known as a "product type" in some circles). It's similar to a C struct, a Ruby struct or a Python dataclass - it's basically like an OO Class that has no methods. This is quite different from a hashmap or dictionary - if you want something that can have new fields added at runtime, you want a Dict.
type alias Record =
{ username : String
, fullName : String
}a User must have a name, an age and nothing else:
hal : User
hal = { username = "Hal" }
-- Compilation error: needs the `fullName` fieldhal : User
hal = { username = "hal", fullName = "HAL 9000" }
-- Compiles!hal : User
hal = { username = "hal", fullName = "HAL 9000", sentient = True }
-- Compilation error: you can't add random extra fieldsinterface User {
username: string;
fullName: string;
}Just like Elm records, you'll get a compiler error if you omit or add any fields.
const hal:User = { username: "hal", fullName: "HAL 9000", sentient: True }
// type checker error!
In Elm, an extensible record is less strict than record: it must have certain fields, but it can also have arbitrary additional fields.
type alias Named = { r | name : String }
sayHello : Named r -> String
sayHello thing =
"hello " ++ thing.name
sayHello { name: "Hal 9000", sentient: True } -- compiles!True to its name, you can extend other records:
type alias User = Named { id : Int }This is equivalent to
type alias User = { name : String, id : Int }interface Named {
name: string;
[propName: string]: any; // this indicates that any other property is allowed
}You can reuse other interfaces with the extends keyword:
interface User extends Named {
id : string;
}Linked List (slightly off topic: Elm also has Arrays which are indexable)
toppings : List String
toppings = [ "pineapple", "mozarella", "tomato" ]
Array
const toppings:string[] = [ "pineapple", "mozarella", "tomato" ]
// or
const toppings:Array<string> = [ "pineapple", "mozarella", "tomato" ]
Certain functions only make sense when applied to a specific type. For example, a sum function that adds together every number in a list, only makes sense for a list of numbers (it does not make sense to sum a list of strings).
sum : List String -> Int
sum =
List.foldl (+) 0 -- this won't compile because you can't add two strings.On the other hand, certain functions can be applied to a wide variety of data types. For example, a list reverse function. It would be a waste of time to re-implement it for every specific type of contained element.
reverseListOfInts : List Int -> List Int
reverseListOfInts xs =
foldl (::) []
reverseListOfStrings : List String -> List String
reverseListOfStrings xs =
foldl (::) []
reverseListOfUsers : List User -> List User
reverseListOfUsers xs =
foldl (::) []
// This is getting really tedious! The implementation is identical for every type of element!So, rather than declaring a specific type as the element contained in the list, a type variable can be used:
reverse : List thingo -> List thingo
reverse items =
foldl (::) []The type variable thingo can be applied to any type such as Int or String. This means that this reverse function can be applied to a list of any type. Important note: this does not mean that the list can contain anything such as ["a", 4.5, 10], it still means that all items in the list must be the same type, but the function can take a list of any type. You can use any name you want for the variable, such as a (this is what's conventionally used)
Whereas in Elm type variables are lower case letters like a, type variables in Typescript are uppercase letters surrounded by angle brackets like <Thingo> (but <T> is the convention for a single type variable)
function reverse(items: Array<Thingo>): Array<Thingo> {
... implemention details :D
}just the one type variable (Elm's core Maybe type is an example of this)
type Maybe a =
Just a
| Nothingmultiple type variables (Elm's core Result type is an example of this)
type Result error value =
Error error
| Value valueWhat the Elm examples would like like in Typescript
?????Tony Hoare invented null references and now refers to them as his “billion dollar mistake”.
Both Typescript and Elm have ways of asking the compiler enforce that a dreaded null pointer exception will not happen at runtime.
Nulls simply do not not exist in Elm, and not with a different name such a nil or none. It's impossible to get a null/nil/none pointer exception in Elm.
However, you might want to represent the absence of a value. This can be achieved with our friend the Custom Type:
type Maybe a
= Just a
| Nothing
This is the exact implementation of the Maybe type in Elm which comes in the standard library and is automatically imported (no need to import Basics.Maybe in every file that you use it)
type alias Parent = Maybe String
jesusBiologicalDad : Maybe String
jesusBiologicalDad = Nothing
jesusMum : Maybe String
jesusMum = Just "mary"
Not that for the "success" case, you can't do for example jesusMum = "mary". This is because custom types need a tag for each option. In the Nothing case, Nothing is a tag with no data attached (more technically a "data constructor" with no arguments). Just is a tag with the "success" value attached.
Similarly, Typescript will forbid assigning a value to null unless you have explicitly allowed it in the type definition. Because typescript
const x: number;
x = 1; // this is good
x = null; // compiler error
const x: number | null; // use a union type to allow either a number or null
x = 1; // this is good
x = null; // this is also OK!Note that unlike in Elm, you don't need to "tag" the success value with a strange name like "Just" because Typescript allows "untagged unions".
Work in progress
A summary is that purity is 100% enforced in Elm - all side effects must be specified in type annotations & you cannot mutate data that's passed into a function. Typescript cannot guarantee the absence of side effects and has some level of support for checking that you haven't mutated arguements.
I forked and made some edits, and also switched to
undefinedinstead ofnullfor the "null" section, as you kinda have to go out of your way to get a "null" (which is basically Elm'sUnitor()) in JavaScript.