[erlang-questions] please never make spec required

[Kenneth Lundin]

-spec will always be optional we have no intention of making them mandatory.

-spec is a formal specification of a functions signature and this is
very useful for public API's.
We will also use the information from -spec for the API documentation
where we today use an informal
syntax or edoc which already has something very similar to '-spec'.
Edoc will soon support and use the '-spec' syntax.

The consistency between what's in the -spec and the code can be
checked so they will not
get out of sync with the code.

See more embedded comments below.

On Wed, Feb 18, 2009 at 3:03 PM, Steve Davis
<steven.charles.davis@REDACTED> wrote:
> Please, please *never* make spec a required part of Erlang.
>
> How can a spec be justified when a spec can be both longer and harder
> to read than the code. e.g.: from lists...
> -spec(append/2 :: ([T],[T]) -> [T]).
> append(L1, L2) -> L1 ++ L2.
>
> ...much like java generics which tried to make types compile-time
> safe, this is well-meaning BS in my book. I confidently predict that
> the cost(s) of spec will be far, far greater than the reward(s)...
>
> Major concerns for me are:
> - code bloat
Why?
It is also possible to have all -spec's in one block, they need not be
in front of each function.
> - source file obfuscation (yes it's harder to read a module with specs
> in it)
How can it be harder?
If you understand the code without reading the -spec what's the problem?
> - having to find and look up a type() to understand something
> - specs that include dynamic elements i.e. funs (yes, that's *code*,
> people, and they will need debugging) e.g. again from lists:
-spec's does not contain dynamic elements (i.e not code)
>       -spec(merge/3 :: (fun((X, Y) -> bool()), [X], [Y]) -> [_]).
The -spec above means that the merge function takes 3 arguments where
the first argument is a fun which should take
2 arguments and return a boolean (i.e. true or false).
> - specs that are wrong or get out of sync with the code (which they
> will)
Since the compiler and dyalyzer can check the consistency of -specs
they need not get out of sync.

I see the specs as a big improvement since they provide a formal
syntax for the function signatures which is any way
needed for any documented public API. The formal syntax makes it
possible to build tools which give added value.

But as said earlier, -spec's will never be mandatory


/Kenneth Erlang/OTP Ericsson
>
> Really, hold your hand on your heart, and tell me how...
> -spec(foldl/3 :: (fun((T, _) -> _), _, [T]) -> _).
> ...helps anyone at all?
>
> Well, that's my 2c -- do as you see fit, but please, please, never
> make me do this!
>
> /s
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>