[erlang-bugs] More compiler errors

[Kostis Sagonas]

On 02/28/2014 02:05 PM, Ulf Norell wrote:
> I ran some more quickcheck tests and found a few more bugs. These are
> all tested on R17-rc1:

I am obviously only speaking for myself here, but I think there is a 
fine line on what is "reasonable" to expect from a compiler (and thus 
what can be classified as a bug) and what is not.  IMO, the Erlang 
compiler has every right to refuse to compile code that is arguably 
weird, to say the least.

For example, the first two programs I would not expect any sensible 
programmer to write, and IMO these Erlang programs should be burned in 
hell. (No sensible programmer would write erlang:'andalso' and I would 
definitely do not want to have to read code that looks like that.) If 
you simply change the calls from being remote calls to being operators 
(e.g. write "true andalso true" for the first one -- similarly for the 
second, although this one actually has a type error and should perhaps 
not be compiled anyway), the BEAM compiler happily accepts them.

> -module(bug1).
> f() when erlang:'andalso'(true, true) ->
>    ok.
>
> -module(bug2).
> f(X) when erlang:'and'(bad, X) ->
>    ok.


The third program is the only one that I would classify as a bug here.

> -module(bug3).
> f(Rec, Tag) ->
>    erlang:is_record(Rec, Tag, 1) orelse error.

The problem exists even without the erlang: part. This should be fixed.


As to this last program, IMO it's non-sensical:

> -module(bug4).
> f(_) ->
>    (fun f/1)().

The compiler has every right to throw up upon seeing code like this. Why 
wouldn't it? ;)

Kostis