<div dir="ltr">i have slightly different approach: <div><br></div><div>i don't want any new syntax right now so i'm marking side effecting construct in erlang </div><div>for example: put/2, and send ( ! ) i consider side effecting so they go in seed list [{M:F:Arity}] <br>then i go and try to infer which functions in OTP sources are pure or not and put that information in DB<br>and then i can consult DB for projects that use OTP stdlib and such, update DB with these and go up</div><div><br></div><div>it is bottom up approach but it shows promise. I am aware that BIFs nad NIFs are problem right now </div><div>and -pure declarations could help there a lot! <br><br>also it would be extremely nice to have a way to declare and classify side effects, i'm also looking into that </div><div>but at this time have no concrete solutions  </div></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></div>