On 30 April 2012 16:39, José Valim <jose.va...@gmail.com> wrote:

On 1/05/2012, at 5:13 AM, Max Lapshin wrote:

        JSON            Erlang
        null            null
        false           false
        true            true
        numbers         numbers, but JSON has no integers
        strings         binaries
        arrays          lists or tuples
        dictionaries    frames

The implied mapping takes JSON {id: 4135, title: "title2"}
to <{id ~ 4135, title ~ <<"title2">>}>.

The bounded size of the Erlang atom table is a vulnerability
but there is an EEP to address that; that in itself is a much
more urgent issue than frames.

function({type : <<"article">>, title : Title, id : Id} = Object) ->
   Object{id : make_permalink(Id, Title)}.

or

  Article = {id : 523, title : proplists:get_value(<<"title">>, Params)}

On 1/05/2012, at 3:38 PM, Max Lapshin wrote:

The frames proposal has always made it very clear why we cannot
copy JSON syntax.

{}      is already an empty TUPLE,
        it cannot also be an empty 'dictionary'.
        We cannot reasonably use unadorned curly
        braces for frames.

{a:f()} already means a tuple whose one element
        is the value of a call to the f() function
        in module a.  We *CANNOT* even unreasonably
        use a colon in maplets; it is just not going
        to work.

Have a lollipop.

"Ancient" always trumps "unworkable."

Max again: "Nowadays such syntax <{key ~ value>} look like inventing
bicycle with square wheels."

Bzzt. Analogy fail. Whatever a bicycle with square wheels might *look* like

   http://3.bp.blogspot.com/_uhH7HeUdvmw/TB7l0F7aGCI/AAAAAAAAACU/lx6z8b6...

we can agree that such a bicycle couldn't work -- well, except perhaps
in a special environment

  http://www.math.hmc.edu/funfacts/figures/10001.2-3-8.1.gif

in which square wheels are actually ideal.

If there's any parallel to the ideal-square-wheel special environment,
here, it's existing Erlang syntax, which is so weird and annoying that
even some ardent fans of the language can't refrain from open
criticism. Richard is looking for what would be the "smoothest ride"
given what can't be changed. I think he's made the best of some
not-very-satisfactory choices. And it's not like he and I exactly
agree on syntax issues (but let's not go there again. Ever.)

Richard: "Have a lollipop."

Curmudgeon points for that one.

This proposal is almost 10 years old. Is it really so radical that we
couldn't have it in beta within three months?

-michael turner

So until the atom limitation is fixed, we would be better on handling JSONs
as a dict or something else.

-michael turner

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?

- similar syntax indicates similar semantics
- different syntax indicates different semantics

…or something to that effect. Most importantly, I definitely agree that borrowing a syntax just because it's well-established, is a very bad idea if your intention is to give it different semantics from what one would expect.

BR,
Ulf W

On 1/05/2012, at 7:37 PM, José Valim wrote:

        '#{' [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.

On 2/05/2012, at 2:28 AM, Max Bourinov wrote:

(1) If it ain't broke, don't fix it.
    Records are NOT going to go away.

    There's an analogy from Fortran.  Fortran 66 had so-called
    'Hollerith literals', where you would write e.g., 4HFRED
    to get a string "FRED".  That's right, the length as a
    decimal integer, the letter capital H, and then that many
    characters.  With the advent of proper character data in
    Fortran 77, Hollerith literals were not needed any more.
    They had always been clumsy and error-prone.  But they
    stayed.  I can't remember if they were still there in
    Fortran 90 or not, but by Fortran 95 they were gone.
    Well, I just tried a Hollerith literal in a tiny program
    and while the Fortran 95 compiler *complained*, the
    program *worked*.

    The Erlang community isn't quite _that_ committed to
    backwards compatibility, but it's not too far off...

(2) Frames are almost drop-in replacements for records.
    The major exception is default initial values for fields,
    which have problems anyway.

Years ago I wrote a paper 'Delenda est preprocessor'.
Abstract patterns and frames are all part of a long-time
project to make the preprocessor unnecessary.

But, sigh, it will probably never go away.

On 2/05/2012, at 3:48 AM, Juan Jose Comellas wrote:

The frames proposal explains why using '=' in maplets is a bad idea.
Basically, it is HARDER to read because it makes '=' locally ambiguous.
You go searching through a file and hit the line

        foo = bar(),

and you have NO IDEA whether this is a maplet or a matching.  BAD!

As for #{...} vs <{...}>, it's in one way harder to write
(to get <{, press SHIFT with left hand, and then < and { are close
for two-fingered right hand typing; the same is true of }>,
but #{ requires me to hold down the shift key with my left hand
AND press the # key with my left hand at the same time, and while
there is a shift key on the right, { requires the use of the right
hand).  Brackets really ought to be mirror symmetric, but I could
live with #{...}.

There's a section in the proposal titled
"The Colour of the paint on the Ark."
        why do we find it easier to argue about the colour
        of the paint on the Ark than to climb aboard?
That is the section that provides the reasons for the syntax.

Now Jan Burse and I have been arguing with each other about frames,
but actually, that was a *lot* more useful, because he focussed on
semantics.

But here's the most important thing, which appears in the next draft
of the frames proposal:

        This would have been a workable syntax for frames
        before erlson used it.  Now, it is important that the syntax
        should be distinct from erlson syntax, so that frames can be
        added to Erlang without breaking erlson.  There is also an
        important pragmatic difference between frames and erlson.
        Frames are new built in data type with a good deal of thought
        put into making them economical in memory and time.
        ``At runtime,  Erlson dictionaries are represented as a list
        of {Name, Value} tuples ordered by Name.  This way, each Erlson
        dictionary is a valid proplist  and orddict in terms of the
        correspond[ing] stdlib  modules.''  
        An entry in an Erlson dictionary thus takes 4 words for the
        {Name,Value} tuple plus 2 words for the list cell pointing to
        it, or 6 words compared with a frame's 1 or 2.
        It therefore matters which one you are using: a programmer
        needs to be able to tell at a glance whether an expression
        deals with a frame or with an erlson dictionary.

That is, we shouldn't copy Erlson syntax, BECAUSE Erlson IS ALREADY
USING IT and we must not break Erlson.

So in my case at least it's not only 1 key less, it's also a lot simpler
to type.

It's also a lot simpler to type = instead of ALT GR ~, regardless of
other considerations.

However, since the problem with <{...}> appears to be due to the use of
the curly braces, surely this must make tuples and records already 'insanely
difficult'.

As for the difficulty of typing ~, code is READ more often than it is WRITTEN,
so the readability advantage much outweighs the typing disadvantage.

Modern text editors have abbreviation features which mean that you *should* be
able to set your text editor up so that
        (,      expands to <{}> with the cursor in the middle
        =,      expands to  ~   with the cursor after it
so that typing "<{a ~ 1, b ~ 2}>" requires the keystrokes
        "(,a=,1, b=,2<fwd><fwd>"

It took me five minutes to write this code for my home-brew text editor:

void comma(void) {
    if (argvalue != implicit) {    
        putin();      
    } else
    switch (fetch(here)) {
        case ')':                  /* For Erlang expressions */
        case ']':                  /* For Erlang lists */
            here++;
            break;
        case '}':                  /* For Erlang tuples and frames */
        case '>':               /* For Erlang binaries */
            here += fetch(here+1) == '>' ? 2 : 1;
            break;
        default:
            switch (fprev(here)) {
                case '(':                  /* For Erlang frames */
                    delete(NORM, here-1);  
                    strinsert(1, 4, "<{}>");
                    here -= 2;
                    break;
                case '[':                  /* For Erlang tuples */
                    delete(NORM, here-1);  
                    strinsert(1, 2, "{}");
                    here--;
                    break;
                case ':':                  /* For Erlang records */
                    delete(NORM, here-1);
                    insert(1, '#');
                    break;
                case '=':                  /* For Erlang frames */
                    delete(NORM, here-1);
                    strinsert(1, 3, " ~ ");
                    break;
                case ' ':  
                    here--;
                    insert(-1, ',');
                    here++;
                    break;
                default:
                    putin();
            }
    }

To me, the benefits of using Erlson syntax for a native implementation
of name-value dictionaries in Erlang outweigh the broken compatibility
with Erlson runtime data representation.

One of the reasons why I created Erlson was to prove that it is
possible to have a nice syntax for Erlang dictionaries that fits with
the language (*). While Erlson syntax is similar to records, it is
still different enough to avoid confusion and it is compatible with
the rest of Erlang's syntax.

So, for those who actually consider implementing a native dictionary
data type in Erlang and using Erlson syntax for that, please feel free
to break Erlson.

Anton

The flow analysis happens mostly implicit by having turned the
relation semantics of Prolog into a functional semantics. With
the sad result that one way to implement relation semantics in
Erlang is via continuation.

I was more concerned with usage and complexity. Your frames have
been invented many many times. I remember also some proposals
that retain the relational character, so that a pattern <{k1~v1,
k2~vn|F}> with a tail frame would become a first class citizen
of the language. These are then not called frames but rather
feature structures.

I guess one way to implement real feature structures in a logic
programming language would be to extend the unification so
that it works on feature terms with tail features. Feature
structures are very fashion in certain attribute grammar
formalism. Besides unification there can be further operations
between feature structures.

The simple syntax there for feature structures is [k1:v1,
k2:vn|F]. And it seems to be rather the rule than the exception
that a feature structure is open. This stems from the relation
ship of feature structures to equations, so the following
equations

       G:k1 === v1,
       G:k2 === v2

would correspond to the following feature structure relation:

       G===[k1:v1,k2:v2|_]

The (===)/2 in the two equations can be viewed as a
declarative combined setter/getter. So setter/getter
are by no way alien to logic programming and it is not
mandatory to go with a feature structure on the
surface of a language.

What seems to be a problem in the grammar domain is that
then practically highly recursive feature structures are
used. But some compilation techniques are able to flatten
them straight the way to records and removing all open
parts that are never closed. So that a feature
structure (*):

       [head:[cat:[n:A,v:B|_],agr:[per:C,num:D|_],
                           case:E,nform:F|_],bar:G|_]

Turns into:

        dag0(A,B,C,D,F,G)

In certain circumstances it can be also benefitial to turn
open parts into record positions. Maybe the grammar application
domain can provide further ideas for representing and optimizing
frame terms in Erlang, and vice versa. Most probably the
referenced paper below is already hopelessly outdated, and
people do even more clever things today. But anyway.

(*)
Compiling Feature Structures into Terms:
an Empirical Study in Prolog (1993)
by Andreas Schöter , Buccleuch Place
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.24.8407

Sincerely,

jw

Sincerely,

Jon Watte