[erlang-questions] Re: Missing features in Erlang type system and several additional question related to it

[Kostis Sagonas]

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
> precisely.

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 
describe precisely.

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 
be used.


<aside>

> 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.

</aside>

>> 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
> other
> languages. In Ruby, JavaScript and many others there are no tuples.
> And instead of tuple arrays is used. So we have tuple=>array=>list
> conversion
> 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.

Best,
Kostis