[erlang-questions] *current* value?

David King <>
Wed Oct 17 23:38:31 CEST 2007

> In Erlang, the best example I know at this time is self() - which  
> returns the "current" process ID.  i.e., the returned values of self 
> () changes as it's called within different processes.
> I'm trying to see if there are ways to write functions similar to  
> the context dependent effect of self().  I'm not looking for global  
> variables; context dependent functions such as self() is fine.

Ah, I see. The process dictionary (when used in a read-only fashion,  
as you described earlier) is probably what you're looking for, then.  
That's how mnesia keeps track of your transactions in a construct  
like this:

   mnesia:transaction(fun() ->
                        end), ...

While you don't *specify* anything like current_transaction(),  
mnesia:write() implicitly refers to it, and it sets/gets it in the  
process dictionary. You could write a current_transaction() or  
something that would read it back out of the process dictionary. You  
could also design something like




Then you're passing your "current transaction" around rather than  
carrying it implicitly. I think that's cleaner. But if you wanted it  
to be implicit, you could use the process dictionary for it like  
mnesia does.

> Some of other examples I can think on top of my head are:
> In Java, an example is the Thread.currentThread(), which returns  
> the current thread.
> OOP uses this or self as an implicit keyword to retrieve the  
> current object.
> In PLT Scheme, there is a facility called parameters, that can be  
> bound for a particular block of code to be a particular value  
> (parameters are retrieved like function calls rather than a naked  
> variable).
> In Lisp - special variables can also be bound by context.
> Basically - one can bind the value by a particular context (I think  
> in Erlang process is the basic unit for a context).  The main use  
> is to reduce the # of parameters that needs to be explicitly passed  
> in, which obviously makes the function impure (although can be more  
> practical).
> Let me know if this explains it better, thanks.
> yc

More information about the erlang-questions mailing list