<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Forget the comment below. After talking to a friend, I at last
    understood why this is ok.<br>
    <br>
    In the expression #{}#{}, the first #{} is the record creation, and
    the 2nd #{} is record copying, so in Erlang, the same syntax is used
    for 2 separate things.<br>
    <br>
    For example in Ocaml, you use {X with ..}<br>
    <br>
    Thanks for the help. Yes, this is not a bug.<br>
    <br>
    /mattias<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 09/11/2014 14:27, Mattias Waldau
      wrote:<br>
    </div>
    <blockquote cite="mid:545F6BB0.7080604@outlook.com" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      Thank you Loic and Roland for the explanations, I really
      appreciate it.<br>
      <br>
      The trick to understand why this is and should be ok is that #{}
      is n operator and then it makes sense. Then, there is another
      question why #{} is an operator.<br>
      <br>
      This is what the Erlang reference manual says about record
      creation, it doesn't mention #rec{}#rec{}<br>
      <br>
      So, until you explained, I just thought is was a parser bug.<br>
      <br>
      /mattias<br>
      <br>
      <h3><a moz-do-not-send="true" name="id83431">10.2  Creating
          Records</a></h3>
      <p>The following expression creates a new <span class="code">Name</span>
        record where the value of each field <span class="code">FieldI</span>
        is the value of evaluating the corresponding expression <span
          class="code">ExprI</span>:</p>
      <div class="example">
        <pre>#Name{Field1=Expr1,...,FieldK=ExprK}</pre>
      </div>
      <p>The fields may be in any order, not necessarily the same order
        as in the record definition, and fields can be omitted. Omitted
        fields will get their respective default value instead.</p>
      <p>If several fields should be assigned the same value, the
        following construction can be used:</p>
      <div class="example">
        <pre>#Name{Field1=Expr1,...,FieldK=ExprK, _=ExprL}</pre>
      </div>
      <p>Omitted fields will then get the value of evaluating <span
          class="code">ExprL</span> instead of their default values.
        This feature was added in Erlang 5.1/OTP R8 and is primarily
        intended to be used to create patterns for ETS and Mnesia match
        functions. Example:</p>
      <div class="example">
        <pre>-record(person, {name, phone, address}).

...

lookup(Name, Tab) ->
    ets:match_object(Tab, #person{name=Name, _='_'}).</pre>
      </div>
      <br>
      <br>
      /mattias<br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 09/11/2014 14:09, Loïc Hoguin
        wrote:at<br>
      </div>
      <blockquote cite="mid:545F678C.2070101@ninenines.eu" type="cite">
        <pre wrap="">There are already warnings on otherwise correct syntax. Syntax being 
correct is why they are warnings and not errors. +warn_export_vars and 
+warn_shadow_vars are the most obvious examples.

I also want to note in addition to everything I mentioned that if such a 
warning is introduced, it needs to apply to both records and maps, as 
they both suffer from the same syntactic fragility.

On 11/09/2014 03:02 PM, Roland Karlsson wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Hi Mattias and Loïc.

That #rec{}#rec{} is correct syntax is a result of how operators work.
Making it not correct syntax needs a special treatment of this case.
Which should be weird. Even more weird if it would be correct syntax in
"advanced macros" only.

Having a warning is another issue, warnings are based on heuristics
and opinions.

  Loïc - have you seen a warning if you e.g. write A*B+C  ?
This expression (in principle) takes A*B, creating an unnamed
variable. This unnamed variable is then added with C. Have you
seen any warnings that this unnamed variable is unused?
The same goes for #rec{}#rec{}. The first #rec{} creates an
unnamed record of type rec. The second #rec{} modifies
the unnamed record. You might not like the record syntax, and find
the #rec{}#rec{} unreadable - but it is very clear what it does.
BTW - the bit syntax and list comprehensions are even more hairy.

Now, I am not a part of the OTP group or developing Erlang syntax, so
it feels a bit awkward to defend it and be forced to come with
motivations and proofs for being right.

So - this is my last post on this subject.


/Roland




On Sun, 9 Nov 2014 13:23:59 +0100
Mattias Waldau <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:mattias.waldau@outlook.com"><mattias.waldau@outlook.com></a> wrote:

</pre>
          <blockquote type="cite">
            <pre wrap="">Hi All,

I think the discussion went overboard. I made a small typo, forgetting a single comma in a static list.

I know realize that

#rec{}#rec{}

is correct syntax, and I do not understand why it should be.

Why not just say that it isn't ok? Who needs this syntax, except a advanced macro?

/mattias
</pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>