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

["Thijs Schreijer" <thijs@...>]

> -----Original Message-----
> From: Robert Virding [mailto:robert.virding@erlang-solutions.com]
> Sent: maandag 23 april 2012 19:10
> To: thijs@thijsschreijer.nl; Lua mailing list
> Subject: Re: [BUG] Table constructor not equivalent to left-to-right
> assignment (Was: Testing for a sequence ...)
> 
> 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.


It does. So it all boils down to different design principles/goals.


> 
> 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