[erlang-questions] Frames proposal

[Richard O'Keefe]

On 1/05/2012, at 7:37 PM, José Valim wrote:
> I have read the proposal completely and I think everything is well explained and defined. Even though I am not a huge fan of the syntax, I think it fits Erlang well. One option that I haven't seen considered is still using curly brackets as delimiters and use `{~}` to specify an empty frame. This would make the common case (a frame with at least one element) easier on the eyes by sacrificing a bit the not so common case (empty frame). But again, we are in good hands with whatever the Erlang and OTP team decide.

The relevant concept here is *uniformity*: are all cases of a construct
generated by the *same* rule(s)?  {a~1, b~2}, {a~1}, and {~} are *not*
generated by the same rule.  The bare ~ in {~} has no counterpart in the
others.  As I understand it, Joe Armstrong's current proposed syntax is

	'#{' [maplet {, maplet}...] '}'

so you would have #{a~1, b~2}, #{a~1}, and #{} (using ~ for maplets
where Joe would actually use =).  I prefer symmetric fences, not least
because it helps tools to help me get my brackets to match properly.
But I could live with Joe's syntax.

I have been toying with the idea of a revision to my proposal, namely
that
	<open> <maplet> {',' <maplet>}... '|' <expression> <close>
should only be allowed to replace slots that already exist in the
base frame, and not to add new slots.  Functional support for adding
new slots would remain, but this way we would *know* that the new
frame could always share the descriptor of the old one, and it would
provide a "safety" assurance to the programmer:  if you *intend* to
write 'a copy of F except that the ~count slot is zero'
then <{ count ~ 0 | F }> would faithfully check your assumption that
F _has_ a count slot.  This is just like the way records are now, after
all.