[erlang-questions] New draft of frames proposal (was Re: Frames proposal)

[Tim Watson]

On 03/05/2012 11:50, José Valim wrote:
>
>     I don't understand this example [p16]
>
>        foo:bar(Ugh),
>
>     How is this ambiguous? Are you trying to set the bar element from the
>     foo frame? Your next line is unclear.
>
>
> It is ambiguous because:
>
>     { foo:bar(Ugh) }
>
> Could be a tuple with one element which is the result of foo:bar(Ugh) or
> a frame with key foo and value bar(Ugh) (according to your proposal).
> There is also the "ambiguity" in {}. Is it an empty frame or an empty 
> tuple?
>
> <{ foo: bar(Ugh) }> could work because there would be no ambiguity for
> the compiler, but it would be still ambiguous for humans (damn you, 
> humans).
> I would shrug if I read a code like <{ foo:bar(Ugh) }> that actually means
> <{ foo: bar(Ugh) }>.

I'm not sure that I would (shrug) at it - #{ foo->bar, baz->2 } seems 
much less ambiguous to me, and whilst I recognise that #{ 1 -> 2 } 
appears a bit odd, I would've thought that it's fairly obvious what it's 
doing. There is no clash with module:function syntax, no clash with 
#record_name{} syntax and no chance of accidental matching taking place 
AFAICT. And as the author of erlson mentioned, there is no real problem 
with trouncing erlson's #{...} syntax as erlson users will immediately 
migrate to frames.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120503/de093a57/attachment.htm>