Re: [BUG] Table constructor not equivalent to left-to-right assignment (Was: Testing for a sequence ...)

[Robert Virding <robert.virding@...>]

A little of the rationale behind Erlang.

One goal was to design a language for building fault-tolerant systems. In our view you will *always* get errors so the you need to be able to detect/contain/recover from errors. Parts of the system can/will crash and will be restarted but the system as a whole must survive. Came from our telecom environment, you can lose calls but the switch must not go down. This meant that errors and error-handling primitives are a part of the language. We embrace errors! :-)

In that respect there was never any desire to "tolerate" errors, instead signal the error and let the system handle it and recover. So Erlang is very strict about generating errors. For all of the basic data-types and operations on them if you do an illegal operation generate an error. It is a functional language so everything is an expression and returns a value. So control structures have no default values and you are forced to handle every option. Everywhere. Sometimes a bit tedious but it means you know what will occur.

The same with most of the basic libraries. In most cases bad inputs generate an error, though in functions will return values indicating if it went well or not. It depends on the functions. So, for example, when accessing a dictionary the 'find' functions returns a value or an error return indicating there was no value, while 'fetch' returns the value or generates an error if there is no value. Returning an "error" value is not the same as signalling an error.

So the basic principle is that either it works as it should or it crashes, and if/when it crashes there will be an environment around this will will catch/contain/recover from the error. It also means that most code never handles errors, you program for the good case.

Sorry for the outlay, but this is just to try and explain why Erlang is as it is wrt to errors.

So there has never been a discussion about signalling errors or trying to keep going. There are very few "undefined behaviours" in the language and in the basic libraries, at least that I can think of straight off. We even define the evaluation order in expressions. You can look at the code and you know what is going to happen and what will be returned. At least if you understand all the semantics. :-) I can see that here we are expecting a list, then I know that either we have a list here or we will get an error.

I don't think it adds very much extra code to the Erlang VM, everything is there for processing errors anyway. Internally you either return a "legal" value or something which indicates an error return. Again there is no discussion about this.

This is why I have difficulties in grasping some things in Lua which are undefined and that you can't always see that you have done something illegal. It is entirely foreign to my way of thinking. And, IMAO, detrimental to writing good code. :-)

I hope this answers your question.

Robert


----- Original Message -----
> Just curious; when designing Erlang, did you remove all the
> 'undefined
> behaviors' with error checking code? And if so do you have any idea
> how
> much this added to Erlangs VM code base?
> 
> Thijs