Quantcast

Is it a compiler bug?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Is it a compiler bug?

Minin Maxim-2

Hello,

 

i'm confused about a very simple module like this:

-----------------------------------------------------------------------

-module(sample).

 

-record (a, {field1}).

 

-export([bug/0]).

 

bug() ->

                [

                #a{field1 = 1} %% COMMA IS MISSING

                #a{field1 = 2},

                #a{field1 = 3}

                ].

-----------------------------------------------------------------------

 

Why can it be compiled?

 

Erlang/OTP 19 [erts-8.3] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]

 

Eshell V8.3  (abort with ^G)

1> c("sample.erl").

{ok,sample}

2> sample:bug().

[{a,2},{a,3}]

 

And eshell do it to:

 

3> rr(sample).

[a]

4> [#a{field1 = 1} #a{field1 = 2}, #a{field1 = 3}].

[#a{field1 = 2},#a{field1 = 3}]

5>

 

Do I understand something wrong or is it a compiler bug?

 

Thanks

Maxim


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it a compiler bug?

Stanislaw Klekot
On Thu, Apr 13, 2017 at 01:27:40PM +0000, Minin Maxim wrote:

> i'm confused about a very simple module like this:
> -----------------------------------------------------------------------
> -module(sample).
>
> -record (a, {field1}).
>
> -export([bug/0]).
>
> bug() ->
>                 [
>                 #a{field1 = 1} %% COMMA IS MISSING
>                 #a{field1 = 2},
>                 #a{field1 = 3}
>                 ].
> -----------------------------------------------------------------------
>
> Why can it be compiled?
[...]
> 2> sample:bug().
> [{a,2},{a,3}]

Apparently the compiler takes the first #a{} record as value X, and then
replaces in X field1. Let's complicate your example a little:

#v+
-module(sample).

-record (a, {field1, field2}).

-export([bug/0]).

bug() ->
                [
                #a{field1 = 1, field2 = "foof"} %% COMMA IS MISSING
                #a{field1 = 2},
                #a{field1 = 3}
                ].
#v-

Note that with the missing comma you'll get a list of {a,1,"foof"},
{a,2,undefined}, and {a,3,undefined}, and with missing comma you'll get
list of {a,2,"foof"}, {a,3,undefined}.

Or a different view on your code: "#a{field1 = 1} #a{field1 = 2}" can be
read as "(#a{field1 = 1})#a{field1 = 2}", or in two steps:
"X = #a{field1 = 1}, X#a{field1 = 2}".

--
Stanislaw Klekot
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it a compiler bug?

Robert Raschke
In reply to this post by Minin Maxim-2
This is because the first record constructor returns as its value the record and the seemingly second constructor then functions as a record modification. 

It is parsed as (#a{field1 = 1})#a{field1 = 2}

Cheers, 
Robby

On 13 Apr 2017 15:27, "Minin Maxim" <[hidden email]> wrote:

Hello,

 

i'm confused about a very simple module like this:

-----------------------------------------------------------------------

-module(sample).

 

-record (a, {field1}).

 

-export([bug/0]).

 

bug() ->

                [

                #a{field1 = 1} %% COMMA IS MISSING

                #a{field1 = 2},

                #a{field1 = 3}

                ].

-----------------------------------------------------------------------

 

Why can it be compiled?

 

Erlang/OTP 19 [erts-8.3] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]

 

Eshell V8.3  (abort with ^G)

1> c("sample.erl").

{ok,sample}

2> sample:bug().

[{a,2},{a,3}]

 

And eshell do it to:

 

3> rr(sample).

[a]

4> [#a{field1 = 1} #a{field1 = 2}, #a{field1 = 3}].

[#a{field1 = 2},#a{field1 = 3}]

5>

 

Do I understand something wrong or is it a compiler bug?

 

Thanks

Maxim


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it a compiler bug?

Minin Maxim-2

I'm so stupid today J

Thanks guys (Robert & Stanislaw)

Cheers

Maxim

 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it a compiler bug?

Jesper Louis Andersen-2
No, it is not stupidity in any way.

People hit this now and again. It makes sense to solve the problem this way. I remember we considered the alternative, which is to reject the notion, but this requires some special-handling in the compiler and isn't clear-cut either.

In short, regarding this as an invalid expression is to a certain extent possible, and certainly desirable. But we run into subtle problems when we want to reject it too, which is what complicates matters.

I think it is healthy to challenge certain design decisions in Erlang, especially because dynamically typed languages tend to have corner cases in their semantics which are hard to handle in general.

On Thu, Apr 13, 2017 at 4:04 PM Minin Maxim <[hidden email]> wrote:

I'm so stupid today J

Thanks guys (Robert & Stanislaw)

Cheers

Maxim

 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it a compiler bug?

Dmytro Lytovchenko
I can see how enforcing parentheses in map()map() syntax can be useful.
A compiler warning would be awesome here. Also this is a nice thing for Elvis style checker to do, but when it comes to running Elvis, your program should already be correct — so that is too late.

In variable()map() syntax there is no confusion so that is fine.

2017-04-13 16:14 GMT+02:00 Jesper Louis Andersen <[hidden email]>:
No, it is not stupidity in any way.

People hit this now and again. It makes sense to solve the problem this way. I remember we considered the alternative, which is to reject the notion, but this requires some special-handling in the compiler and isn't clear-cut either.

In short, regarding this as an invalid expression is to a certain extent possible, and certainly desirable. But we run into subtle problems when we want to reject it too, which is what complicates matters.

I think it is healthy to challenge certain design decisions in Erlang, especially because dynamically typed languages tend to have corner cases in their semantics which are hard to handle in general.

On Thu, Apr 13, 2017 at 4:04 PM Minin Maxim <[hidden email]> wrote:

I'm so stupid today J

Thanks guys (Robert & Stanislaw)

Cheers

Maxim

 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it a compiler bug?

Robert Virding
IIRC originally parentheses were required around the first was required which would have caught this case. The requirement was then removed, but I don't know why. Perhaps to save the extra 2 chars. :-)


On 13 April 2017 at 16:43, Dmytro Lytovchenko <[hidden email]> wrote:
I can see how enforcing parentheses in map()map() syntax can be useful.
A compiler warning would be awesome here. Also this is a nice thing for Elvis style checker to do, but when it comes to running Elvis, your program should already be correct — so that is too late.

In variable()map() syntax there is no confusion so that is fine.

2017-04-13 16:14 GMT+02:00 Jesper Louis Andersen <[hidden email]>:
No, it is not stupidity in any way.

People hit this now and again. It makes sense to solve the problem this way. I remember we considered the alternative, which is to reject the notion, but this requires some special-handling in the compiler and isn't clear-cut either.

In short, regarding this as an invalid expression is to a certain extent possible, and certainly desirable. But we run into subtle problems when we want to reject it too, which is what complicates matters.

I think it is healthy to challenge certain design decisions in Erlang, especially because dynamically typed languages tend to have corner cases in their semantics which are hard to handle in general.

On Thu, Apr 13, 2017 at 4:04 PM Minin Maxim <[hidden email]> wrote:

I'm so stupid today J

Thanks guys (Robert & Stanislaw)

Cheers

Maxim

 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

答复: Is it a compiler bug?

赵 汉

I still don’t get the sense , What is the need for such weird appending use?

 

发送自 Windows 10 邮件应用

 

发件人: [hidden email]
发送时间: 2017414 8:15
收件人: [hidden email]
抄送: [hidden email]; [hidden email]
主题: Re: [erlang-questions] Is it a compiler bug?

 

IIRC originally parentheses were required around the first was required which would have caught this case. The requirement was then removed, but I don't know why. Perhaps to save the extra 2 chars. :-)

 

On 13 April 2017 at 16:43, Dmytro Lytovchenko <[hidden email]> wrote:

I can see how enforcing parentheses in map()map() syntax can be useful.

A compiler warning would be awesome here. Also this is a nice thing for Elvis style checker to do, but when it comes to running Elvis, your program should already be correct ― so that is too late.

 

In variable()map() syntax there is no confusion so that is fine.

 

2017-04-13 16:14 GMT+02:00 Jesper Louis Andersen <[hidden email]>:

No, it is not stupidity in any way.

 

People hit this now and again. It makes sense to solve the problem this way. I remember we considered the alternative, which is to reject the notion, but this requires some special-handling in the compiler and isn't clear-cut either.

 

In short, regarding this as an invalid expression is to a certain extent possible, and certainly desirable. But we run into subtle problems when we want to reject it too, which is what complicates matters.

 

I think it is healthy to challenge certain design decisions in Erlang, especially because dynamically typed languages tend to have corner cases in their semantics which are hard to handle in general.

 

On Thu, Apr 13, 2017 at 4:04 PM Minin Maxim <[hidden email]> wrote:

I'm so stupid today J

Thanks guys (Robert & Stanislaw)

Cheers

Maxim

 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

 

 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 答复: Is it a compiler bug?

Robert Virding
There is no *need* of it as such it just what the syntax allows. I think we should require the parentheses again and make the current usage a syntax error.

Robert


On 14 April 2017 at 04:24, 赵 汉 <[hidden email]> wrote:

I still don’t get the sense , What is the need for such weird appending use?

 

发送自 Windows 10 邮件应用

 

发件人: [hidden email]
发送时间: 2017414 8:15
收件人: [hidden email]
抄送: [hidden email]; [hidden email]
主题: Re: [erlang-questions] Is it a compiler bug?

 

IIRC originally parentheses were required around the first was required which would have caught this case. The requirement was then removed, but I don't know why. Perhaps to save the extra 2 chars. :-)

 

On 13 April 2017 at 16:43, Dmytro Lytovchenko <[hidden email]> wrote:

I can see how enforcing parentheses in map()map() syntax can be useful.

A compiler warning would be awesome here. Also this is a nice thing for Elvis style checker to do, but when it comes to running Elvis, your program should already be correct — so that is too late.

 

In variable()map() syntax there is no confusion so that is fine.

 

2017-04-13 16:14 GMT+02:00 Jesper Louis Andersen <[hidden email]>:

No, it is not stupidity in any way.

 

People hit this now and again. It makes sense to solve the problem this way. I remember we considered the alternative, which is to reject the notion, but this requires some special-handling in the compiler and isn't clear-cut either.

 

In short, regarding this as an invalid expression is to a certain extent possible, and certainly desirable. But we run into subtle problems when we want to reject it too, which is what complicates matters.

 

I think it is healthy to challenge certain design decisions in Erlang, especially because dynamically typed languages tend to have corner cases in their semantics which are hard to handle in general.

 

On Thu, Apr 13, 2017 at 4:04 PM Minin Maxim <[hidden email]> wrote:

I'm so stupid today J

Thanks guys (Robert & Stanislaw)

Cheers

Maxim

 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

 

 



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...