<div dir="ltr"><div>> -pure([f/1, g/0, h/3]).<br></div><div><br></div><div>So, you declare f/1 is pure, but how do you really know it is pure? Meaning it should be a way to prove f/1 is pure, at least with some tool like dialyzer.</div><img src="https://mltrk.io/pixel/DEigk3DuVHWzLEAB09Z1?rid=DEigk3DuVHWzLEAB09Z1" width="1" height="1" border="0"></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 28, 2017 at 10:27 AM, zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2017年09月28日 木曜日 10:01:12 you wrote:<br>
> > I really wish Dialyzer accepted (and checked) explicit declarations of<br>
> purity.<br>
><br>
> i could not agree more<br>
> that would be useful feature and amazing time saver!<br>
><br>
> I am currently working on a toll that creates DB of function properties,<br>
> and motivation was exactly finding non pure functions in any given<br>
> project.<br>
<br>
</span>I've messed around with this a bit and, not liking syntaxtic additions<br>
(for the most part), I've played around a little with this idea. The one<br>
I've come up with that allows building a checkable graph is what I'm doing<br>
already:<br>
<br>
-pure([f/1, g/0, h/3]).<br>
<br>
So that works just like an -export attribute and when the compiler rolls<br>
over it you actually get a nice list in module_info:<br>
<br>
1> zuuid:module_info(attributes).<br>
[{vsn,[<wbr>161185231735429547750212483364<wbr>357911358]},<br>
 {author,"Craig Everett <<a href="mailto:zxq9@zxq9.com">zxq9@zxq9.com</a>>"},<br>
 {behavior,[application]},<br>
 {pure,[{v3,1},<br>
        {v3,2},<br>
        {v3_hash,2},<br>
        {v5,1},<br>
        {v5,2},<br>
        {v5_hash,2},<br>
        {read_uuid,1},<br>
        {read_uuid_string,1},<br>
        {read_mac,1},<br>
        {read_mac_string,1},<br>
        {string,1},<br>
        {string,2},<br>
        {binary,1},<br>
        {binary,2},<br>
        {strhexs_to_uuid,1},<br>
        {strhexs_to_mac,1},<br>
        {strhexs_to_integers,1},<br>
        {bins_to_strhexs,1},<br>
        {binary_to_strhex,1}]}]<br>
<br>
Quite easy to build a graph around this sort of data. And it comes only at<br>
the cost of actually including a -pure declaration.<br>
<br>
The problem, of course, is actually making a -pure declaration and keeping<br>
it in sync with the module code over time -- and that this is invisible to<br>
Dialyzer right now.<br>
<br>
That said, if no unsafe calls or actions are taken in a function Dialyzer<br>
could infer which functions are pure and help generate such a list. Even<br>
better, of course would be if it knew the difference and examined each<br>
function to build the graph of pureness automatically...<br>
<br>
But I digress.<br>
<br>
Save the (maybe not easy) task of making Dialyzer able to infer purity<br>
(and this is impossible anyway when Dialyzer hits a wall of ambiguity<br>
such as a call to M:F(A) or apply(M, F, A) -- which are pretty important!),<br>
it would even nicer if we had a pure function spec declaration form.<br>
<br>
-pure f() -> term().<br>
<br>
And just leave the original<br>
<br>
-spec f() -> {ok, Value :: term()} | {error, Reason :: term()}.<br>
<br>
form alone.<br>
<br>
That shouldn't break any old code, and leave a safe path to updating the<br>
stdlib and internals of existing projects... without anything significant<br>
changing until people are ready for it.<br>
<br>
And no new syntax.<br>
<br>
Where a new bit of syntax may be nice is if, for example, a way to declare<br>
*what* side effects a function has or might have. I haven't any good idea<br>
how to go about that because I've never thought of it or seen a system that<br>
declares categories of side-effects... but its an interesting idea that<br>
might help make "unit testing" of modules that have side effects actually<br>
mean something (for once) and move it closer to the usefulness of actual<br>
user testing (which is amazing at finding the boneheaded, easy to fix,<br>
90% of bugs that are concrete and repeatable that unit tests are for some<br>
reason consistently blind to).<br>
<div class="HOEnZb"><div class="h5"><br>
-Craig<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">With best regards,<div>     Roman Galeev,</div><div>     +420 702 817 968</div></div></div>
</div>