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.

Gogol på Roma Teatern

Igår var vi på Roma Teatern på Gotland och såg på Revisorn av Gogol. Det var en riktigt bra uppsättning och väl värt att se. Jag kan rekomendera att ni går och ser den om ni är på Gotland under sommaren.

Det enda tråkiga var att få reda på hur lite bidrag Roma teatern får jämfört med t.ex. riktsteatrar och olika "fria" teatergrupper. Tydligen att göra bra uppsättningar år efter år som folk uppskattar är inte något som prioriteras av stat och kommun.

"Optimerad laddning"

Jag har en Sony Ericsson K610i som för det mesta tycks fungera bra (fast ibland tror jag att den stänger av sig själv). Det som förundrar mig är att när man laddar den så säger den "Optimerad laddning". Då undrar jag förstås om den även klarar av "Ooptimerad laddning" och vad i så fall är skillnaden. Eller är det bara någon marketroid som har en tänkt lite mer än vad han/hon borde?

Virding's First Rule of Programming

After reading the blogs about how good Erlang's concurrency model is and how we just just made a super implementation of it in XXX I have been led to formulate Virding's First Rule of Programming:

Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.

With all respect to Greenspun.