[erlang-questions] Parse-transforming !! to a function call
Sat Aug 25 02:22:17 CEST 2007
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
>> A = spawn(...),
>> A ! whatever,
>> is a async call but
>> A = spawn(...),
>> B = A ! whatever,
>> 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
> 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
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) .
More information about the erlang-questions