[erlang-questions] is there "return" in Erlang.

[Ulf Wiger]

My point was that you can design the interface as if the function were
pure, even if it only returns the same "handle" each time.

For example, the ets API *could* have been designed much like the 
dict API: i.e. insert(T, Obj) -> T1, even if in the initial version(s), 
T1 == T. In this case, a caller would be expected to treat the function 
as if it were pure, and later versions could in fact take advantage of this.
This would not have meant that the insert/2 function would be noticeably 
slower.

While this may seem silly, it establishes a form of low-water mark, where
you clearly show the *intention* of keeping functions pure, even though
you may not always succeed. What you end up doing is re-programming 
yourself to think functional-by-default rather than imperative-by-default.

BR,
Ulf W

On 28 Feb 2011, at 16:36, Masklinn wrote:

> On 2011-02-28, at 15:46 , Ulf Wiger wrote:
>> On 28 Feb 2011, at 14:15, Jesper Louis Andersen wrote:
>> 
>>> The problem here is that doSomeThing(a); is done for its side-effect
>>> only. The only possible side-effect in Erlang is that it communicates
>>> with other processes
>> 
>> Well, there are other ways - all of which could be modelled using processes,
>> but in fact aren't (updating ets tables or the process dictionary, for example),
>> but I agree with your point, and want to emphasise it.
>> 
>> One thing that will grow in importance as you learn to appreciate the differences
>> between pure and impure code, is that code like this - which can *only* be useful
>> through side-effects - has a toxic effect on your code structure.
>> 
> In this precise case though, pure-but-extremely-expensive functions would probably have a similar effect (though not completely unrecoverable from, as opposed to impure functions).

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com