[erlang-questions] Process scope variable

Fred Hebert mononcqc@REDACTED
Thu Feb 19 15:46:32 CET 2015


On 02/19, Imants Cekusins wrote:
> 
> it would be obvious from parse/1 signature that it does not change the
> state - another benefit.

It would be possible to do the same with:

    get(Key::atom(), #state{}) -> Value::term().

Because the state is a record that isn't returned, you know this bit to
not be modified. Similarly with:

    set(Key::atom(), Val::term(), #state{}) -> #state{}.

You know from the signature you *should* track state if you want its
updates. This lets you know, for example, that `get` could be used in a
map, but `set` would require a fold.

But it would be impossible to know that from:

    get(Key::atom(), pid()) -> Value::term().

Granted, the pid is not returned anymore than #state{}, but we know pids
to behave a bit like pointers to mutable state. This changes a few
things, doesn't it? What about this:

    set(Key::atom(), Val::term(), pid()) -> ok.

Oh, woops. Yeah then we can't know anything except that we're pretty
much guaranteed side-effects now.

The reason why parse/1's signature is clear is because you expect it to
encompass everything it does. That's specifically the reason your
state-modifying signatures will be far less useful than they could be.
Because you want some global mutable state.

The only difference between your approach and the process dictionary is
that you added the overhead of message passing to it.



More information about the erlang-questions mailing list