[erlang-questions] Process scope variable

[Richard A. O'Keefe]

On 18/02/2015, at 6:08 am, Imants Cekusins <imantc@REDACTED> wrote:

>> you're missing the distinction between messages and arguments -- they are not the same thing.
> 
> I used the word "message" in a misleading way. I did not mean
> "message" as erlang message sent to another process. simply alleged to
> "message" (a "tweet" if you prefer) passed from person A to person B
> intended for person C, from function to function in this case, an arg
> passed to fun z() like this:
> 
> a()->
> S = #state{},
> b(S).
> 
> b(S)->
> c(S).
> 
> ...
> 
> z(S)->
> Z = S#state.some_var.
> 
> an arg S passed to another fun X, which fun X may or may not use,
> simply pass it to the next fun and so on.
> 
> this state passing clutters the code and makes refactoring difficult.
> I prefer to only pass the args the fun actually needs. If some other
> fun down the line needs the state, let it get it directly.

Many years ago I had occasion to compare a Lisp program using global
variables and its Prolog analogue passing around a tuple.  Oddly
enough, the Prolog version was faster.

The central problem with the process dictionary is that if you are
* writing a library module, you cannot use it, because you do not
  know what keys your caller might be using
* using a library module, you cannoy use it, because you do not
  know what keys your library might be using.
Dolphin Smalltalk, possibly the most visually attractive Smalltalk
I've ever seen, has some way to attach properties to any object.  I
never bothered to learn how to use it because I didn't fancy never
knowing what might already be in use.

One way to reduce but not eliminate exposure to this problem is to
use module_name.variable_name keys.

Speaking of Smalltalk, I have my own Smalltalk to C compiler.  At
the moment, something like
    x times: y raisedToInteger: z
turns into
    t3 = k_times_raisedToInteger(l1/*x*/, l2/*y*/, l3/*z*/);
but I'm thinking about changing it to
    t3 = k_times_raisedToInteger(CONTEXT, l1/*x*/, l2/*y*/, l3/*z*/);
with the context parameter being a pointer to per-thread data, just
passed around and around, because I am fed up with the portability
and efficiency problems caused by using per-thread data in C.

That is, I want to move AWAY from the model you like.

This will make no difference whatever to my Smalltalk code, except
(I hope) to make it faster and to make a bit more of it thread-safe.
And that's the way to go in Erlang.

If you want a feature like this, write a preprocessor.  Then the
source code *won't* be cluttered and refactoring *won't* be a problem
and you don't have to wait until the community sorts out an effective
design.