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

[Jeff Rogers]

Robert Virding wrote:

>> Could a parse transform recognize the case where the value A ! B is not
>> discarded and change those cases into some kind of synchronous call?  So
>> that
>>
>> A = spawn(...),
>> A ! whatever,
>> ok.
>>
>> is a async call but
>>
>> A = spawn(...),
>> B = A ! whatever,
>> B.
>>
>> is a synchronous call.  The return value of ! is normally just the value
>> that was sent, which doesn't seem very useful.  The only places where it
>> would not be immediately evident if the return value is ignored is when
>> a function or Fun evaluates to a send.  Even so, ! normally looks like
>> an imperative operator more than a functional one so this seems to make
>> it more functional (but also lazy in some respects, which is
>> anti-erlang/soft-rt)
> 
> 
> That would result in forcing people to write some really weird code. I could
> never for example just end a function with a normal async send as that would
> be interpreted as sync  send.

I think the opposite would be true - since the compiler (or rather, 
parse transformer) can only see the immediate surroundings it can make 
no assumption about other scopes; since it would be new semantics the 
safe assumption would always be that the old semantics are the default. 
  So you would not be able to end your function with a synchronous send 
because it would be interpreted as async;  you would need to jump 
through a hoop to send with a sync call.

 From my very limited understanding of how the AST works, it would need 
a very simple transform like
{match,Ln,L0,{op,SLn,'!',L1,R1}} -> 
{match,Ln,L0,{call,SLn,{atom,SLn,sync_send},[L1,R1]}}
to change  "A = B ! C" into "A = sync_send(B,C)" and that wouldn't touch 
any other syntax.

> Generally the idea of having the semantics of something change depending on
> what comes after seems a little off.

It would be what comes before it, not after it.  I would agree that 
radically changing the semantics of the expression based on external 
surrounding syntax is odd at best, but I think it could be useful and 
not terribly confusing (other than the issues that have already been 
raised about how to specify the behavior of the synchronous call) .

-J