[erlang-questions] Missing compile warning

Erik Søe Sørensen eriksoe@REDACTED
Mon Mar 3 21:19:30 CET 2014


As for including guards, it is not possible to warn about all cases where a
clause cannot be matched.

Consider:
f (X, Y, Z) when X*X*X+Y*Y*Y==Z*Z*Z, is_integer(X), is_integer(Y),
is_integer(Z), X>0, Y>0, Z>0 ->
... you get the picture. :)

Linear patterns would be doable.
Non-linear patterns perhaps too, but probably less straightforward.
Den 03/03/2014 18.16 skrev "Vlad Dumitrescu" <vladdu55@REDACTED>:

> On Mon, Mar 3, 2014 at 5:49 PM, Björn Gustavsson <bjorn@REDACTED> wrote:
>
>> > On Fri, Feb 28, 2014 at 7:54 PM, tom kelly <ttom.kelly@REDACTED>
>> wrote:
>> >>
>> >> -module(no_warn).
>> >> -compile(export_all).
>> >>
>> >> -record(my_rec,{field1, field2}).
>> >>
>> >> my_function1(#my_rec{field1 = {tag, _}, field2 = f2}) -> 1;
>> >> my_function1(#my_rec{field1 = {tag, 1}, field2 = f2}) -> 2; % line 7
>> >> my_function1(_) -> 3.
>> >>
>> >> my_function2(#my_rec{field1 = {tag, _}}) -> 1;
>> >> my_function2(#my_rec{field1 = {tag, 1}}) -> 2; % line11
>> >> my_function2(_) -> 3.
>>
>> It is perhaps a documentation bug.
>>
>> Some warnings can be trusted 100 per cent.
>> For example, if there are no warnigs for unused variables
>> there are no unused variables.
>>
>> The absence of warnings for clauses that
>> don't match does *not* mean that that all clauses
>> can be matched. It merely means that
>> the compiler (during optimisation and
>> pattern matching compilation) did not find
>> any clauses that obviously would not be
>> reached.
>>
>>
> Hi,
>
> I'm not sure if I can agree with this. Non-matchable clauses should in my
> opinion be marked as errors, because they expose a logical flaw (usually a
> misordering of the clauses), and in this case I would have them be 100%
> accurate.
>
> Given clauses without guards like f(A)->ok; f(B)->ok. then I think we
> should get a warning/error if B is the same as or more specific than A.
> This probably applies when there are guards too. If that's the case, it
> shouldn't be too difficult to implement.
>
> What am I missing? Is it difficult just because it is done after some
> optimization passes that might mess things up? Or is there some other issue?
>
> best regards,
> Vlad
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140303/33299c33/attachment.htm>


More information about the erlang-questions mailing list