<div>
I've tried adding specs, and it makes no difference - Dialyzer still sees do_something/2 as a function that returns any(). </div><div><div>-- </div>Steve Strong<div>@srstrong</div><div><br>Sent with <a href="http://www.sparrowmailapp.com/?sig">Sparrow</a></div><div><br></div></div>
<p style="color: #A0A0A8;">On Tuesday, 15 November 2011 at 09:52, Anthony Ramine wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>Why don't you write specs for this exported function yourself? This way Dialyzer wouldn't have to infer too general types and it would just check whether the function code can handle its associated spec.</div><div><br></div><div>Le 15 nov. 2011 à 08:46, Steve Strong a écrit :</div><div><br></div><blockquote type="cite"><div><div>Thanks Tobias, that's very helpful. From the work I'd done so far, I had a feeling that things like lists:map/2 must have been hard-coded within Dialyzer, since that was the only explanation I could come up with as to the differing behaviour.</div><div><br></div><div>Since passing functions around like this is pretty common practice, are there any plans to improve Dialyzer's inference capabilities in this area? If not, would it be possible to have some annotation format (similar to -spec) that effectively say "in this context, I know that this function will return X" (i.e., open up access to the "hard-coded" bit where the knowledge of lists:map/2 resides)? Right now, as far as Dialyzer is concerned, I have any()'s passing all over the place, so clearly its ability to give me any useful feedback is severely limited.</div><div><br></div><div>Cheers,</div><div><br></div><div>Steve</div><div><br></div><div>-- </div><div>Steve Strong</div><div>@srstrong</div><div><br></div><div>Sent with Sparrow</div><div><br></div><div>On Tuesday, 15 November 2011 at 08:23, Tobias Lindahl wrote:</div><div><br></div><blockquote type="cite"><div><div>2011/11/14 Steve Strong <<a href="mailto:steve@srstrong.com">steve@srstrong.com</a>>:</div><blockquote type="cite"><div><div>That makes some sense, and indeed if I just export test/0 then it does work</div><div>nicely. Alas, do_something is what I really want to be exporting and if I</div><div>do so, then dialyzer stops warning me. I completely understand that in</div><div>isolation, dialyzer has to infer that do_something can return any() - I was</div><div>hoping that it would adjust that inference when in the context of the</div><div>caller, where the mapping function is constraining the return type.</div></div></blockquote><div><br></div><div>No such specializations happens for exported functions. If the</div><div>inference was stronger, we could find a type for do_something that</div><div>connected the type of the fun to the return type of the function using</div><div>type variables, but this is beyond Dialyzer. On the other hand, if the</div><div>function is not exported Dialyzer will propagate the union of the call</div><div>types, which in your case is just the single fun. That is why it finds</div><div>the specialized type in your case.</div><div><br></div><blockquote type="cite"><div><div>Again, this seems analogous to lists:map/2, which is exported and yet</div><div>dialyzer seems to do "the right thing".</div></div></blockquote><div><br></div><div>There is hard-coded information in Dialyzer about lists:map/2 and</div><div>other commonly used library functions.</div><div><br></div><div>Tobias</div><div><br></div><blockquote type="cite"><div><div>Confused :)</div><div>--</div><div>Steve Strong</div><div>@srstrong</div><div>Sent with Sparrow</div><div><br></div><div>On Monday, 14 November 2011 at 11:58, Joe Armstrong wrote:</div><div><br></div><div>Change export_all to</div><div><br></div><div>-export([test/0]).</div><div><br></div><div>Then you'll get this:</div><div><br></div><div>test.erl:8: Function test/0 has no local return</div><div>test.erl:9: The pattern {'rec2', _} can never match the type #rec1{}</div><div><br></div><div>With export_all the arguments to do_something are totally unconstrained and</div><div>can come from</div><div>any wild place - so the inferred types are too permissive.</div><div><br></div><div>With export_all typer infers the following:</div><div><br></div><blockquote type="cite"><div>typer test.erl</div></blockquote><div>%% File: "test.erl"</div><div>%% ----------------</div><div>-spec test() -> #rec2{}.</div><div>-spec do_something(_,fun((_) -> any())) -> any().</div><div>-spec map(_) -> #rec1{}.</div><div><br></div><div>The (.... any()) -> any() is because the second argument of do_something can</div><div>come from anywhere</div><div>so there are no type errors</div><div><br></div><div>But with -export([test/0]). we get this:</div><div><br></div><div>-spec test() -> none().</div><div>-spec do_something(1,fun((_) -> #rec1{})) -> #rec1{}.</div><div>-spec map(_) -> #rec1{}.</div><div><br></div><div><br></div><div>/Joe</div><div><br></div><div><br></div><div><br></div><div><br></div><div>On Mon, Nov 14, 2011 at 11:40 AM, Steve Strong <<a href="mailto:steve@srstrong.com">steve@srstrong.com</a>> wrote:</div><div><br></div><div>Hi All,</div><div>I have a question on the behaviour of Dialyzer with higher-order functions.</div><div> Consider the following trivial code:</div><div>-module(test).</div><div>-compile(export_all).</div><div>-record(rec1, {fred}).</div><div>-record(rec2, {harry}).</div><div>test() -></div><div> #rec2{} = do_something(1, fun map/1).</div><div>do_something(Num, MapFun) -></div><div> MapFun(Num).</div><div>map(_X) -></div><div> #rec1{}.</div><div>If I run Dialyzer against it, I get no errors or warnings logged, even</div><div>though it's quite apparent that it will fail. I would have expected that</div><div>Dialyzer could infer that the return type of do_something was the return</div><div>type of MapFun; within the context of do_something(), that is clearly</div><div>any(), but within the context of test() I would have thought that it could</div><div>see that do_something() is actually going to return a #rec1{} record, that</div><div>being the return type of map().</div><div>If I replace the call to MapFun with a call to map(), as in:</div><div>do_something(Num, _MapFun) -></div><div> map(Num).</div><div>Then everything works as expected - Dialyzer correctly tells me that my code</div><div>is broken. Is there anything I can do to "teach" dialyzer how to interpret</div><div>the MapFun? It works as I would like with functions such as lists:map():</div><div>-module(test).</div><div>-compile(export_all).</div><div>-record(rec1, {fred}).</div><div>-record(rec2, {harry}).</div><div>test() -></div><div> [#rec2{}] = lists:map(fun map/1, [1]).</div><div>map(_X) -></div><div> #rec1{}.</div><div>With the above, I get the expected warning. I've looked at lists.erl, and</div><div>it doesn't look to be doing anything different. It does have some -spec</div><div>directives, but adding those in my code did not appear to help.</div><div>Any hints?</div><div>Cheers,</div><div>Steve</div><div>--</div><div>Steve Strong</div><div>@srstrong</div><div>Sent with Sparrow</div><div><br></div><div>_______________________________________________</div><div>erlang-questions mailing list</div><div><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></div><div><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></div><div><br></div><div><br></div><div><br></div><div><br></div><div>_______________________________________________</div><div>erlang-questions mailing list</div><div><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></div><div><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></div></div></blockquote></div></blockquote><div><br></div><div>_______________________________________________</div><div>erlang-questions mailing list</div><div><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></div><div><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></div></div></blockquote><div><br></div><div>-- </div><div>Anthony Ramine / @nokusu</div><div>Dev:Extend — <a href="http://dev-extend.eu">http://dev-extend.eu</a>/</div><div>So as I pray, “Unlimited Erlang Works”</div></div></div></span>
</blockquote>
<div>
<br>
</div>