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

Loïc Hoguin essen@REDACTED
Sun Nov 9 12:45:57 CET 2014


On 11/09/2014 01:19 PM, Roland Karlsson wrote:
> I think you are mixing two things here.

I was clarifying my position as I was not sure you understood I wanted 
an optional warning (doesn't affect you if you don't enable it, so why 
be against it?) as opposed to one enabled by default.

> Generally Erlang do not warn you if you have underscore
> variables or anonymous terms (in expressions) that are
> later not used. So - the warning Mattias wanted do break
> common rules in the Erlang compilator.

If these are the rules then where are they written? From what I know 
warnings were added to prevent people from writing "bad" code (quoted 
because it goes from preventing potential bugs to subjective reasons). 
There is no rule that would prevent adding a warning that prevents 
potential bugs.

> The general #rec{}#rec{} warning is a bit more complicated.
> Just writing it is maybe a bit strange and maybe a warning
> might be in place. But - the macro usage I gave is quite legit I
> think and not so horrible at all. And ... I do not know if a warning
> that depends on it being a macro or not is a clever idea.

The macro usage you gave is legal but not wise and quite uncommon to say 
the least. Regardless of any weird legal usage there may be, adding an 
*optional* warning will not change anything for people who write their 
code this way as the warning needs to be enabled explicitly. On the 
other hand it is immensely useful for everyone else.

> /Roland
>
>
>
>
> On Sun, 09 Nov 2014 12:49:41 +0200
> Loïc Hoguin <essen@REDACTED> wrote:
>
>>
>>
>> On 11/09/2014 12:40 PM, Roland Karlsson wrote:
>>>
>>> On Sat, 8 Nov 2014 09:02:08 +0100
>>> Mattias Waldau <mattias.waldau@REDACTED> wrote:
>>>
>>>> Yes, I can agree that
>>>>
>>>> #rec{a=2}#rec{b=3}
>>>>
>>>> is a matter of opinion. However, I completely fail to understand how
>>>>
>>>> #rec{a=2}#rec{a=3}
>>>>
>>>> can be a matter of opinion, since data in the code is LOST.
>>>
>>> Data is not lost.
>>> The code creates a record rec with the field a being 2.
>>> Then the code creates a copy of that record where the field now is 3.
>>> The first record is instance not used though. But, as it has no name
>>> that usually do not give a warning in Erlang, just like unused variables
>>> with underscore names do not give a warning.
>>>
>>> But ... I can see why it might maybe be a warning there.
>>> It IS a matter of opinion though IMHO.
>>
>> When I said it needs a warning earlier in the thread, I meant one you can set optionally, similar to +warn_export_all. Regardless of the contents of the record. You have to program in a very specific way to be annoyed by that kind of warning though.
>>
>>> You have to be aware of the following code though.
>>>
>>> (?MY_DEF_REC)#rec{a=3}
>>>
>>> Lets say the macro MY_DEF_REC creates a record rec with some
>>> special default values. Lets say that one of the fields you have a
>>> special default value for is a. Do you want a warning?
>>
>> And that would be one such way... though my heart would skip a beat seeing code like this.
>>
>> Most people simply do not write code that ends up as #rec{...}#rec{...}, and could very much benefit from a warning that avoids this error. Others can simply choose not to enable it.
>>
>>> /Roland
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> There should be a warning. My sample below shows how catastropic the missing "," can be.
>>>>
>>>> /mattias
>>>>
>>>> On 07/11/2014 13:22, Roland Karlsson wrote:
>>>>> Maybe we shall not discuss this for ever :)
>>>>> It is a matter of opinion after all.
>>>>>
>>>>> But - it is the same IMHO. It is a matter of operators and the need
>>>>> to set paranthesis when the precedents and right/left association is
>>>>> not obvious.
>>>>>
>>>>> The rec example can be written thus
>>>>>
>>>>> (#rec{a=2})#rec{b=3}
>>>>>
>>>>> Then everything is clear.
>>>>>
>>>>>
>>>>> /Roland
>>>>>
>>>>>
>>>>>
>>>>>> I'm not sure how that relates. This expression can be reasonably written
>>>>>> on purpose. The same cannot be said for #rec{a=2}#rec{b=3}.
>>>>>>
>>>>>> On 11/07/2014 02:01 PM, Roland Karlsson wrote:
>>>>>>> If there is a warning there, then all expressions including operators,
>>>>>>> e.g. arithmetic, should have warnings. How about 10 + 1 rem 3 + 7. ?
>>>>>>> Do you know the precedence of + and rem ? What is the result?
>>>>>>>
>>>>>>> /Roland
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Warnings are ordinary Erlang code which is prone to errors.
>>>>>>>>
>>>>>>>> On 11/07/2014 01:46 PM, Roland Karlsson wrote:
>>>>>>>>> No warning is needed methinks. It is just ordinary Erlang code.
>>>>>>>>> It is equal to.
>>>>>>>>>
>>>>>>>>>> REC1 = #rec{b=3}.
>>>>>>>>>> REC2 = REC1#rec{a=2}.
>>>>>>>>> Nothing strange at all.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /Roland
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> It is legal but there probably should be a warning for this
>>>>>>>>>> particular
>>>>>>>>>> case. I cannot think of a valid reason to do #rec{a=2}#rec{b=3} when
>>>>>>>>>> you
>>>>>>>>>> can just do #rec{a=2, b=3}.
>>>>>>>>>>
>>>>>>>>>> On 11/07/2014 10:09 AM, Vlad Dumitrescu wrote:
>>>>>>>>>>> Hi Mattias,
>>>>>>>>>>>
>>>>>>>>>>> This isn't a bug. The expression #rec{a=2}#rec{b=3} is legal, and is
>>>>>>>>>>> the
>>>>>>>>>>> same thing as (#rec{a=2})#rec{b=3} or #rec{a=2,b=3}. If the keys
>>>>>>>>>>> overlap, then the last one "wins".
>>>>>>>>>>>
>>>>>>>>>>> best regards,
>>>>>>>>>>> Vlad
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Nov 6, 2014 at 9:21 AM, Mattias Waldau
>>>>>>>>>>> <mattias.waldau@REDACTED <mailto:mattias.waldau@REDACTED>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>          This is the program
>>>>>>>>>>>
>>>>>>>>>>>          -module('missing-comma-not-detected').
>>>>>>>>>>>
>>>>>>>>>>>          -export([data/1]).
>>>>>>>>>>>
>>>>>>>>>>>          -compile(export_all).
>>>>>>>>>>>
>>>>>>>>>>>          -record(shcnode, {
>>>>>>>>>>>                 nodename :: any(),
>>>>>>>>>>>                 y_axis :: number(),
>>>>>>>>>>>                 children :: [any()],
>>>>>>>>>>>                 article_number :: number(),
>>>>>>>>>>>                 attribute_condition :: string()}).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>          data(1) ->
>>>>>>>>>>>               [
>>>>>>>>>>>                #shcnode{nodename = start, y_axis = 0, children =
>>>>>>>>>>> [d1285]},
>>>>>>>>>>>                #shcnode{nodename = d1285, y_axis = 295, children =
>>>>>>>>>>> [1939,
>>>>>>>>>>> 1940]}
>>>>>>>>>>>                #shcnode{nodename = 1940, y_axis = 525, children =
>>>>>>>>>>> [bm3203],
>>>>>>>>>>>          article_number = 14432861},
>>>>>>>>>>>                #shcnode{nodename = 1939, y_axis = 530, children =
>>>>>>>>>>> [bm3203],
>>>>>>>>>>>          article_number = 14432860},
>>>>>>>>>>>                #shcnode{nodename = bm3203, y_axis = 915, children = []}
>>>>>>>>>>>               ].
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>          Note the missing "," after  [1939, 1940]}
>>>>>>>>>>>
>>>>>>>>>>>          Only 4 rows are detected
>>>>>>>>>>>
>>>>>>>>>>>          length('missing-comma-not-detected':data(1)).
>>>>>>>>>>>          4
>>>>>>>>>>>
>>>>>>>>>>>          ---
>>>>>>>>>>>
>>>>>>>>>>>          If I add the comma, I get
>>>>>>>>>>>
>>>>>>>>>>>          length('missing-comma-not-detected':data(1)).
>>>>>>>>>>>          5
>>>>>>>>>>>
>>>>>>>>>>>          ----
>>>>>>>>>>>
>>>>>>>>>>>          I am using Erlang 17.3 on ubuntu.
>>>>>>>>>>>
>>>>>>>>>>>          erlang:system_info(otp_release).
>>>>>>>>>>>          "17"
>>>>>>>>>>>
>>>>>>>>>>>          36> |erl -V
>>>>>>>>>>>          Eshell V6.2  (abort with ^G)
>>>>>>>>>>>          1> |
>>>>>>>>>>>
>>>>>>>>>>>          ---
>>>>>>>>>>>
>>>>>>>>>>>          Thanks,
>>>>>>>>>>>
>>>>>>>>>>>          Mattias
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>          _______________________________________________
>>>>>>>>>>>          erlang-bugs mailing list
>>>>>>>>>>>          erlang-bugs@REDACTED <mailto:erlang-bugs@REDACTED>
>>>>>>>>>>>          http://erlang.org/mailman/listinfo/erlang-bugs
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> erlang-bugs mailing list
>>>>>>>>>>> erlang-bugs@REDACTED
>>>>>>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Loïc Hoguin
>>>>>>>>>> http://ninenines.eu
>>>>>>>>>> _______________________________________________
>>>>>>>>>> erlang-bugs mailing list
>>>>>>>>>> erlang-bugs@REDACTED
>>>>>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Loïc Hoguin
>>>>>>>> http://ninenines.eu
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Loïc Hoguin
>>>>>> http://ninenines.eu
>>>>>> _______________________________________________
>>>>>> erlang-bugs mailing list
>>>>>> erlang-bugs@REDACTED
>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> erlang-bugs mailing list
>>>> erlang-bugs@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>>
>>
>> -- Loïc Hoguin
>> http://ninenines.eu
>

-- 
Loïc Hoguin
http://ninenines.eu



More information about the erlang-bugs mailing list