[erlang-questions] Parse-transforming !! to a function call

Jeff Rogers dvrsn@REDACTED
Mon Aug 27 00:13:04 CEST 2007

Robert Virding wrote:

> The problem is not whether it is difficult to do in the compiler but 
> rather if we want to do it. Having the semantics of :
>     A ! Msg
> and
>     B = A ! Msg
> being different would be a first in the language and I personally think 
> completely horrendous.

I'm not suggesting this as a change to the language - that would require 
*far* more thought than a 2-minute brainstorm.  I was pondering the idea 
as a parse-transform only, so that the programmer chooses when to use it 
with a compiler directive.  This thread started with a discussion about 
how bad it was to need a different compiler to accept a new piece of 
syntax and I had a thought about how to do it with the same compiler.

> Also the semantic difference between sending an async message and doing 
> a sync rpc is VERY large.

No argument here.  I'm not saying it wouldn't be different.  I am saying 
it might be useful in some cases.

> Also if you were to add one end of a sync message passing then you 
> should also add the other end as well, both receiving the message and 
> returning the reply.

I could see some benefit to this too, but since in most cases you would 
want to actually do something before sending the reply a compact 
representation is tough to come up with.  The potentially useful part 
would be having the response operator implicitly know what process to 
send the message to.  So for example, where the sync-send hides  "A ! 
{self(),B}" behind a simeple "A ! B", the sync receive hides "receive 
{Pid,Msg} -> Pid ! Fun(Msg)" behind "receive! Msg -> Fun" or something 
like that.

> If instead it was defined to translate into a certain function call 
> which you yourself then had to provide then that would also be a first, 
> and I honestly don't see the benefit of it. Why not just write the 
> function call yourself?

It's syntactic sugar, that's all, just like "A ! B" is syntactic sugar 
for "erlang:send(A,B)".

> Also there are people who use the return value of a send, not just as a 
> side-effect. They won't be happy.

I can't claim alot of experience here, but it seems odd to use the 
return value since it's essentially an identity.  The return value of
"A ! B" is B, never anything else.  The people who wouldn't be happy 
about it could just not use the parse-transform module in their code.


More information about the erlang-questions mailing list