The Erlang Rationale - The problem with ‘if’

Sigh. If was added as an almost “on the spur of the moment” hack. We knew how to compile guards and thought it might be useful in the case where you don’t have a value to match against. As Erlang has pattern matching we found that a “pure” if is used less than in many other languages, we never used it much ourselves and therefore didn’t really worry much about it. This is not really that strange as in many languages if is used in way which resembles very trivial pattern matching. For example in C:

if ((x = get_some_value()) != 0) {
    do stuff with x
else {
    do some other stuff
}

Also I don’t really have a problem using case when I want to do a conditional, but then again I am so used to it I don't think about it.

There have been repeated suggestions and discussions of either extending if to allow user defined boolean functions or adding a new construct. The problem with extending if is that the tests would no longer be guard tests and would handle differently for exceptions. A guard test silently just fails while a normal expression generates an error, which would make the change incompatible. We actually made cond a reserved word but never got around to adding it to the language.

The Erlang Rationale - Characters and strings

This is one non-terminating discussion we had.

There have been many suggestions whether to have a proper type character data type or to leave them as integers. While adding a new type would not have been difficult we could not quite agree as to whether we should do it. If so which encoding should we use, stay with ASCII or go to ISO-8859-1 (Latin1) or UNICODE? If we changed to UNICODE should we also allow that in atoms as well? In the end we decided not to add a character type but make sure we could handle Latin1 in the libraries. As our primary application area was not handling text we felt that this was sufficient.

Very early on we decided that strings were lists. This was partly environment as many of the languages we were using, such as Prolog, use lists and partly practical as lists are a very powerful data type.

Using a general data type like lists and having characters is seldom as problem as you usually know what if you are processing a list which is a string or if it is something else. It is only within generic functions like printing or the shell where you can have problems with such a general data type.

The Erlang Rationale

A while back I released the Erlang Rationale which is an attempt to explain why things look like they do in Erlang and our thinking behind many of the properties and features of the language. There is also some descriptions of part of the system which today seem to lack description, for example the i/o system and groups. The Rationale mainly deals with the core parts of the language and the older parts of the libraries and not OTP.

It can be found here The Erlang Rationale

The rationale is not finished and I am adding to it and expanding/improving what is already there. When there has been a significant enough change I will release a new version. However, someone suggested I could release new bits as they come and get comments and suggestions. This seems like a good idea and i will try it.