[erlang-questions] Spec is diabolical IMHO

[Steve Davis]

Hi Michael,

I suspect that if your code is beta quality then it would be fair to say that the contract is beta quality also, right?

When you/the author get around to implementing it (if you/they ever do) then you/they may definitely find that the contract changes. I think it hubris to believe that you can predict that future without implementing it first. Meantime, this "api idea" in a spec is implicitly expected to be supported by all users - even though it is bogus. I'd say to that - just be honest about what _is_, not what you think things may be.

WRT to dialyzer -> If dialyzer can see that, then what is the purpose of the spec (given that is it provably wrong). Should not dialyzer strive to look deeper rather than requesting/requiring that highly fault-prone specs should be written for every function?

You'll perhaps also note that the comment on the example was also wrong. It stated "Currently unused", and that isn't true either - the function just doesn't do anything on a code change; But the function IS USED. *Everything* preceding the actual function is misleading.

I'm saying we should all be aware of that, and dare to consider better solutions than spec.

I would post-script the above with the following thought for those that have experienced it in other languages: The drive to clear definition of static typing leads to highly repetitive and confusing code that leads to high distraction and extremely suspect verbosity. => One of erlang's core syntax strengths is a low requirement on developer time to get an error tolerant, working system, and that aggressive approach is "saved" by coding to "let it crash".

/s


On Sep 27, 2012, at 7:43 PM, Michael Radford <mrad@REDACTED> wrote:

> At least the dialyzer won't let you get away with incorrect specs, if
> that's what you're worried about. (I find this quite irritating when I
> want to define an interface to support some future expansion that
> callers should handle, but isn't fully implemented yet!)
> 
> $ cat >> foo.erl
> -module (foo).
> -export ([foo/0]).
> -spec foo () -> {ok, any()} | {error, any()}.
> foo () -> {ok, now ()}.
> 
> $ dialyzer --src -c foo.erl
>  Checking whether the PLT /home/notroot/.dialyzer_plt is up-to-date... yes
>  Proceeding with analysis...
> foo.erl:3: The specification for foo:foo/0 states that the function
> might also return {'error',_} but the inferred return is
> {'ok',{non_neg_integer(),non_neg_integer(),non_neg_integer()}}
> done in 0m0.34s
> done (warnings were emitted)
> 
> Mike
> 
> On Thu, Sep 27, 2012 at 4:48 PM, Steve Davis
> <steven.charles.davis@REDACTED> wrote:
>> Since it's not been picked up on, I hope that everyone noticed that in the original example that I posted, even that blatantly simple spec was... wrong.
>> 
>> There is NO WAY that function could ever return {error, Reason}, and further wastes your valuable time in trying to convince you that it could.
>> 
>> /s
>> 
>> 
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions