Erlang for the little ones. Chapter 4: Type System

Good Monday, Habr! We continue to study Erlang for the smallest.

In the last chapter, we figured out the syntax of functions. In this chapter, we will introduce you to the language type system.

Dynamic strong typing

If you read past chapters, you most likely noticed that we did not specify the types of variables and the values ​​returned by functions anywhere. Also, we did not specify the data type when comparing with the sample. For example, a tuple {A, B}can take a value {someAtom, 100}, {100.0, "Some string"}etc.

If the data cannot be matched with the specified pattern, an error will be generated. This will happen immediately at the time the code is executed. This is because Erlang is a dynamically typed language. The compiler cannot catch all errors at the compilation stage. Therefore, many errors are generated during program execution.

Why doesn't Erlang have static typing? A lot of copies were broken in the debate about which typing is better: static or dynamic. Each has its pros and cons. One of the main disadvantages of dynamic typing is the inability to search for errors associated with types at the compilation stage. Because of this, such errors occur in runtime and the program crashes, which reduces the overall reliability of the software product. But Erlang solves this problem in a different, more efficient way.

Erlang ideology: "If it breaks, let it break." The language has tools to isolate and correctly handle all errors that may occur. This makes Erlang programs very resilient. A classic example of the survivability of programs on Erlang, which is given is the Ericsson AXD 301 ATM switch software. This product has more than a million lines of code and an uptime of 99.9999999%. Impressive.

In general, Erlang does not seek to avoid mistakes. He offers to handle them correctly.

Erlang also refers to strongly typed languages . This means that type casts need to be done explicitly. If we use incompatible data types in one expression, we get an error:

1> 10 - "5".
** exception error: bad argument in an arithmetic expression
    in operator  -/2
        called as 10 - "5"

Type conversion

Erlang uses the functions of the standard library (located in the module Erlang) to convert types . The names of these functions are formed as follows: <исходный_тип>_to_<небходимый_тип>. Here is a complete list of such features:

• atom_to_binary / 2
• atom_to_list / 1
• binary_to_atom / 2
• binary_to_existing_atom2
• binary_to_list / 1
• bitstring_to_list / 1
• binary_to_term / 1
• float_to_list / 1
• fun_to_list / 1
• integer_to_list / 1
• integer_to_list / 2
• iolist_to_binary / 1
• iolist_to_atom / 1
• list_to_atom / 1
• list_to_binary / 1
• list_to_bitstring / 1
• list_to_existing_atom / 1
• list_to_float / 1
• list_to_integer / 2
• list_to_pid / 1
• list_to_tuple / 1
• pid_to_list / 1
• port_to_list / 1
• ref_to_list / 1
• term_to_binary / 1
• term_to_binary / 2
• tuple_to_list / 1

And an example of their use:

1> erlang:integer_to_list(123).
"123"
2> erlang:atom_to_list(false).
"false"
3> erlang:iolist_to_atom(123).
** exception error: bad argument
    in function  iolist_to_atom/1
        called as iolist_to_atom(123)
```

Type checking

Most data types in Erlang can be distinguished visually. Lists are enclosed in square brackets, tuples in curly braces, and strings in double quotation marks, etc. This provides the simplest type checking. For example, a pattern for matching [x|xs]can only be matched with a list. Otherwise, the operation will fail.

But such elementary checks are not enough. Often you need to check what type this or that variable belongs to. To do this, Erlang has a number of functions that take one argument (sometimes more) and if its type is as expected, return trueotherwise false. These functions can be used in security expressions and the type they check is clear from their name.

• is_atom / 1
• is_binary / 1
• is_bitstring / 1
• is_boolean / 1
• is_builtin / 3
• is_float / 1
• is_function / 1
• is_function / 2
• is_integer / 1
• is_list / 1
• is_number / 1
• is_pid / 1
• is_port / 1
• is_record / 2
• is_record / 3
• is_reference / 1
• is_tuple / 1

An interesting point: in Erlang there is no function that would return the type of the passed variable (in similarity type_of()). And at first glance this may seem strange, because one universal function is more convenient than a bunch of narrowly targeted ones. The answer to this question lies in the ideology of the language: the program should do only what is explicitly described. Everything else should result in an error . This approach will be discussed in more detail in the chapter on error handling.

These data types can be combined with lists and tuples to create more flexible and universal types.

To be completely honest, we need to mention that Erlang has the ability to explicitly specify types. This functionality will be highlighted a whole chapter, so here they will not talk about it.

Conclusion

This time it turned out briefly and in the case. The theme is simple, but it needs to be highlighted.
Any comments and additions are waiting in the comments. Errors and typos, please inform in PM.