[erlang-questions] please never make spec required
Steve Davis
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
- source file obfuscation (yes it's harder to read a module with specs
in it)
- 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(merge/3 :: (fun((X, Y) -> bool()), [X], [Y]) -> [_]).
- specs that are wrong or get out of sync with the code (which they
will)
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-q...@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Kenneth Lundin
-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.cha...@gmail.com> 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
Zvi
Steve Davis-5 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.
>
In Erlang arguments got duplicated 4 times (edoc, spec, arguments
list/patterns and guards). Overtiem, it's guaranteed, that they will be out
of sync:
%%--------------------------------------------------------------------
%% @doc Concatenates two lists
%% @spec append(list(),list()) -> list()
%% @end
%%--------------------------------------------------------------------
-spec(append/2 :: ([T],[T]) -> [T]).
append(L1, L2) when
is_list(L1), is_list(L2)
-> L1 ++ L2.
Compare this with C++ and Doxygen (arguments specified only once, thanks for
type declarations and special doxygen syntax):
/**
* returns list, which is concatenations of two input lists
*/
template<typename T>
list<T> append( const list<T> &L1, /**< list of elements of type T
*/
const list<T> &L2) const /**< list of elements of type
T */
{
list<T> L(L1);
L.insert(L.end(), L2.begin(), L2.end());
return L;
}
Zvi
--
View this message in context: http://www.nabble.com/please-never-make-spec-required-tp22079518p22081703.html
Sent from the Erlang Questions mailing list archive at Nabble.com.
Steve Davis
As you can tell I'm not a big fan of "spec". I understand the
reasoning behind it but don't see it as the solution.
BR,
Steve
On Feb 18, 9:14 am, Kenneth Lundin <kenneth.lun...@gmail.com> wrote:
> But as said earlier, -spec's will never be mandatory
>
> /Kenneth Erlang/OTP Ericsson