[erlang-questions] A sender() BIF?

[Dave Smith]

I don't believe the VM tracks the origin of messages, so adding this
BIF would likely necessitate a bunch of changes within the VM to do
the proper accounting. What's more, the distributed Erlang subsystem
(and protocol) would (probably) need to be changed to support this
implicit parameter. I'm not sure how one would would deal with older
instances of VMs that aren't including the sender; the BIF would
probably need to be able to support 'undefined' return value, which
means your code also has to do checking...blech.

Given that we have to copy the contents of a message when we send it,
including an additional parameter such as the sender on every message
seems (to me) a bit inefficient -- esp since there are plenty of
situations where you don't care about the sender. The current setup of
using convention to include the sender is simpler, more efficient and
backwards compatible.

Furthermore, even if the VM included the sender, you could only trust
that for messages from within the local node. I.e. any distributed
erlang node could fake the sender, so if you're interested in this for
security/robustness reasons, it would only be useful within a local
VM.

My $0.02.

D.

On Sun, Feb 21, 2010 at 6:20 AM, Michael Turner <leap@REDACTED> wrote:
>
> It's conventional for certain purposes to make the first term of a
> message tuple be the sender, where the receiver needs to know.
> Recently, I started wondering: why isn't the appropriate sender already
> available within each receive scope, via a BIF (or even via some special
> variable)?
>
> I haven't found any BIF like this, so far.  Nor do I see any way to
> write it as an Erlang function or macro, though I'm guessing this might
> be possible.
>
> Does the idea of sender() violate encapsulation in some meaningful way?
> As matters stand, a module just has to take it on faith that a Pid
> identified as sender in a message actually *is* the sender.  So, if
> anything, the current arrangement seems to be a source not only of code
> verbosity, but (admittedly minor) risk of error as well.
>
> -michael turner
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>