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

[Tim McNamara]

On 3 May 2012 16:22, Richard O'Keefe <ok@REDACTED> wrote:
> There is a new version of
> http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf

Thank you for this impressive piece of work. Here are some notes that
I made that may be of use to people who are intimidated by the size of
the article. (Please correct errors!)

 - Frames are a distinct type. That is, they are not syntactic sugar
over tuples and/or lists
 - They are not declared. They
 - They have no default value
 - Only atoms may be keys
 - No frame identifier, e.g. impossible to label a frame as "person"
which represents people

I've only been able to make it through the first 8 sections in any detail.

The only thing that genuinely worries is relying on atoms as keys. I
think this would mean that frames could not be used to deserialise
untrustworthy strings. That is, programmers could expose themselves to
having their atom table overrun.

I disapprove of the tilde though. The association with approximate is
too strong for me to overlook. The argument of overloading the equals
sign is noted. However, when I am programming, I don't see the equals
sign as equality. When I see it, it represents an association, usually
from right to left on the page.

However, I'm wary of bikeshedding over the syntax. However, I don't
see why the Erlang grammar can not support the Python syntax (I'm not
calling this JSON, because JSON requires double quoted keys).

  {a: "0", b: "1"}

The comment was made earlier that it's useful to use different syntax
for different conceptual things. However, I think that this syntax is
sufficiently different from a tuple to be distinguished, while looking
unified. We are referring to lots of data which has been unified
together into a single frame.

I would also make the point that there are very few single-language
programmers. Context switching is not free for humans either. It would
be great to be able to translate between JS/Python/other and Erlang
with as few hurdles as possible. Using familiar syntax for a fairly
similar task seems very useful to me.

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.

    If, following JSON, you use colon for maplets, your comprehension comes
    to a juddering halt while you try to 
gure out if this is a maplet or a
    remote function call. BAD!

JSON is just a serialisation format. It is not JavaScript. JavaScript
would require you something closer to: foo["bar"] = Ugh. Is that what
you intended?

I think this is a strong argument, but I am not persuaded by it:

    Erlang uses curly braces for sequences, not sets. It would be
    very confusing for people if {a ~ 1, b ~ 2} = {b  ~ 2, a ~ 1}
but {{a, 1}, {b, 2}} !=
    {{b, 2}, {a, 1}}.

I think that this would certainly be considered a trip for new Erlang
programmers. However, this risk is warranted.