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

[Richard O'Keefe]

On 3/05/2012, at 10:39 PM, Tim McNamara wrote:
> 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.

This is not a problem at all for frames that are created by patterns
that the compiler can see, only for dynamically created frames.  And
there is an EEP showing in sufficient detail how we can fix *that*
problem once and for all.  The frames proposal presupposes that's
been done.

> I disapprove of the tilde though. The association with approximate is
> too strong for me to overlook.

This is a classic "what is good for everybody is what *I* am used to"
argument.  For a lot of people reading this, "~" is not associated with
approximation at all, but with regular expression matching.

> 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"}

Because {a:f(), b:g()} is already legal Erlang syntax for
a tuple with two function calls to compute its elements.

> 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?

Actually, no.  {foo:bar(Ugh)} is 100% leval JavaScript.
s/JSON/JavasScript in the version I just put up.

The whole point here is that foo:bar(Ugh) is a legal Erlang function
call.  We don't want the same sequence of tokens *also* meaning
"bind field foo to value of bar(Ugh)".

I'm painfully aware of the multilanguage programmer issue.
The last time I counted, I'd used over 200 programming languages
and could remember more than I wanted to about each of them.
Just today I wrote

g: Integer * Integer -> Integer

in a Haskell Program, where I should have written

g :: Integer -> Integer -> Integer

I'd used ML syntax...

I get far too confused by R code doing f(x=y=g()) where the
first = means "bind argument by name" and the
second = means "assign to variable" to be happy about
two different meanings for = in Erlang.
At least using "~" means (a) ***NOT*** innovating, other
people have used ~ for this purposebefore; and (b) *NOT*
using tokens ambiguously.