<br><br><div class="gmail_quote">2012/5/1 Juan Jose Comellas <span dir="ltr"><<a href="mailto:juanjo@comellas.org" target="_blank">juanjo@comellas.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And what about borrowing the syntax that Anton Lavrik used for erlson [1]? That syntax looks similar to the one used for records and is much easier to read/write.<div><br></div><div>[1] <a href="https://github.com/alavrik/erlson" target="_blank">https://github.com/alavrik/erlson</a></div>
</blockquote><div><br></div><div>Syntax is more than just finding which characters our parser can identify, like in the frames proposals where ~ is our separator. When I read <{ k ~ value | Is }>  it says cons "k is like a value" to Is. *brr*</div>
<div><br></div><div>At first I didn't like the syntax at all, but after playing around with it for a couple of hours it kind of grows on you. #{ } vs <{ }>, the second one only uses a single character more. I think we could live with that one. I still don't like ~ .. and I definitely don't like lollipops.</div>
<div><br></div><div>Lavriks syntax proposal is very clean and seems like an obvious fit to the current Erlang syntax. However, if I read #{ k = value }, and I know how R#{k = value } works, it feels like the two should have some sort of connection. They would't have one. It is entirely possible we are fooling ourselves with a similar syntax and would be better off with a completely different syntax.</div>
<div><br></div><div>Syntax is perhaps the most fun to discuss since it is our interface. It is important to get it right since it hard to change it once implemented. But, It is of minor concern to me.</div><div><br></div>
<div>What guarantees should we leave? The underlying implementation of a Hashmap has enormous consequences on the guarantees we can promise. Speed, memory consumption and functionality are all trade offs. From a memory / speed perspective I really like a HAMT-implementation. Very compact, simple garbage collector, persistent and all around nice properties (except ordering). Doing something more fancy complicates the gc which is not unsolvable but irritating.</div>
<div><br></div><div>Richard, is the "beam"-implementation for frames around to look at? </div><div><br></div><div>// Björn-Egil</div></div>