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

Mattias Waldau mattias.waldau@REDACTED
Sun Nov 9 14:27:12 CET 2014


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:
> 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/7b92a9ce/attachment.htm>


More information about the erlang-bugs mailing list