On 25/08/07, <b class="gmail_sendername">Jeff Rogers</b> <<a href="mailto:dvrsn@diphi.com">dvrsn@diphi.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Robert Virding wrote:<br><br>>> Could a parse transform recognize the case where the value A ! B is not<br>>> discarded and change those cases into some kind of synchronous call?  So<br>>> that<br>>>
<br>>> A = spawn(...),<br>>> A ! whatever,<br>>> ok.<br>>><br>>> is a async call but<br>>><br>>> A = spawn(...),<br>>> B = A ! whatever,<br>>> B.<br>>><br>>> is a synchronous call.  The return value of ! is normally just the value
<br>>> that was sent, which doesn't seem very useful.  The only places where it<br>>> would not be immediately evident if the return value is ignored is when<br>>> a function or Fun evaluates to a send.  Even so, ! normally looks like
<br>>> an imperative operator more than a functional one so this seems to make<br>>> it more functional (but also lazy in some respects, which is<br>>> anti-erlang/soft-rt)<br>><br>><br>> That would result in forcing people to write some really weird code. I could
<br>> never for example just end a function with a normal async send as that would<br>> be interpreted as sync  send.<br><br>I think the opposite would be true - since the compiler (or rather,<br>parse transformer) can only see the immediate surroundings it can make
<br>no assumption about other scopes; since it would be new semantics the<br>safe assumption would always be that the old semantics are the default.<br>  So you would not be able to end your function with a synchronous send
<br>because it would be interpreted as async;  you would need to jump<br>through a hoop to send with a sync call.<br><br> From my very limited understanding of how the AST works, it would need<br>a very simple transform like
<br>{match,Ln,L0,{op,SLn,'!',L1,R1}} -><br>{match,Ln,L0,{call,SLn,{atom,SLn,sync_send},[L1,R1]}}<br>to change  "A = B ! C" into "A = sync_send(B,C)" and that wouldn't touch<br>any other syntax.
</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Generally the idea of having the semantics of something change depending on
<br>> what comes after seems a little off.<br><br>It would be what comes before it, not after it.  I would agree that<br>radically changing the semantics of the expression based on external<br>surrounding syntax is odd at best, but I think it could be useful and
<br>not terribly confusing (other than the issues that have already been<br>raised about how to specify the behavior of the synchronous call) .</blockquote><div><br>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 :
<br><br>    A ! Msg<br><br>and<br><br>    B = A ! Msg<br><br>being different would be a first in the language and I personally think completely horrendous. <br>Also the semantic difference between sending an async message and doing a sync rpc is VERY large. 
<br>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.<br>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?
<br>Also there are people who use the return value of a send, not just as a side-effect. They won't be happy.<br><br>Robert<br><br></div></div>