[erlang-questions] Frames proposal

[Björn-Egil Dahlberg]

2012/5/1 Juan Jose Comellas <juanjo@REDACTED>

> 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.
>
> [1] https://github.com/alavrik/erlson
>

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*

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.

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.

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.

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.

Richard, is the "beam"-implementation for frames around to look at?

// Björn-Egil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120501/a97cc281/attachment.htm>