[erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given.

[Mattias Waldau]

Forget the comment below. After talking to a friend, I at last 
understood why this is ok.

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.

For example in Ocaml, you use {X with ..}

Thanks for the help. Yes, this is not a bug.

/mattias


On 09/11/2014 14:27, Mattias Waldau wrote:
> Thank you Loic and Roland for the explanations, I really appreciate it.
>
> 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.
>
> This is what the Erlang reference manual says about record creation, 
> it doesn't mention #rec{}#rec{}
>
> So, until you explained, I just thought is was a parser bug.
>
> /mattias
>
>
>       10.2  Creating Records
>
> The following expression creates a new Name record where the value of 
> each field FieldI is the value of evaluating the corresponding 
> expression ExprI:
>
> #Name{Field1=Expr1,...,FieldK=ExprK}
>
> 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.
>
> If several fields should be assigned the same value, the following 
> construction can be used:
>
> #Name{Field1=Expr1,...,FieldK=ExprK, _=ExprL}
>
> Omitted fields will then get the value of evaluating ExprL 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:
>
> -record(person, {name, phone, address}).
>
> ...
>
> lookup(Name, Tab) ->
>      ets:match_object(Tab, #person{name=Name, _='_'}).
>
>
> /mattias
>
>
> On 09/11/2014 14:09, Loïc Hoguin wrote:at
>> 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:
>>> 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<mattias.waldau@REDACTED>  wrote:
>>>
>>>> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20141109/7848f9d5/attachment.htm>