[erlang-questions] Re: Missing features in Erlang type system and several additional question related to it
Tue Aug 31 17:45:29 CEST 2010
Sergii Boiko wrote:
>> Your arguments are very weak, but you probably know that already. In
>> Erlang it's tuples and not lists which are supposed to be used for
>> collections of items of known number.
> You've missed the point. I don't argue with anything. I've pointed
> out in the leak of type system. There is a structure in Erlang, which
> is correct. You can create it, you can use it, but can't describe it
Please realize that this is a property of all type languages.
In Erlang, one can for example write a function that creates lists whose
length is a prime number. Should the type language cater for expressing
this? Similarly, some application may need to create binaries whose
middle element is 42. How about binaries where segments in positions
which are prime numbers are integers divisible by 42? You probably see
what I mean...
No matter how expressive we make the language of types there will always
be some set of Erlang terms that one can create, can use, but cannot
It's true that the current type language does not allow you to specify
that lists are of some particular length. But I would argue that in
*Erlang* these are programs where tuples rather than lists should better
> And at the same time there is much less 'idiomatic' and 'correct'
> types like 'maybe_improper_list' and 'nonempty_maybe_improper_list' which
> you can.
There is a reason why these types exist (because they are needed in the
analysis -- the analysis for example might not be able to infer that a
list is definitely -terminated) and there is a reason why they have
such long names. One should NOT use these types unless one really knows
what she is doing.
>> If json or mochiwebjson2 or
>> whatever has limitations, then the answer to what you are trying to do
>> is most probably a call to tuple_to_list/1 away...
> It's not a question of library. It's a question of integration with
> And instead of tuple arrays is used. So we have tuple=>array=>list
> as result. And i don't wont to pay performance penalty with call to
> tuple_to_list when i can avoid it.
I do not think the type language of Erlang has to cater for performance
concerns of integration with other languages. This is of very low
priority to its design.
More information about the erlang-questions