[erlang-questions] Type specs expressivity

[Stavros Aronis]

Hi Olivier,

Some answers to your questions:

        - we can define immediate constants and even ranges for integer 
> values (ex: '-spec f() -> 42.' or  '-spec f() -> 0..42.'), but apparently we 
> cannot do the same for floats? Is there any particular reason for that 
> (besides the lack of meaning of exact comparisons for floating-point 
> numbers), or maybe it is a planned enhancement? 
>

I am not aware of any specific reason behind that decision, apart from 
perhaps it being one step further from the functionality that was initially 
desired. To simply be able to write such a spec would be trivial, but to 
actually have tools like Dialyzer infer float values or ranges might be not 
that easy (or even significantly useful).
 

>         - it is a still more minor point, but we are using a hashtable type 
> in pure Erlang, which is implemented as a tuple containing buckets. The 
> number of elements of the tuple is determined at run-time (depending on a 
> targeted ideal load factor, based on the expected number of elements to be 
> stored in the hashtable). We can define a type for bucket(), but for the 
> hashtable is there any way of expressing a more precise declaration than 
>  '-opaque hashtable() :: tuple()', i.e. to tell that even if we do not know 
> the size of the tuple, we know it will contain bucket() instances at each 
> position?


Same as before, a type language can be extended to accommodate whatever your 
heart wishes. This one is rather simpler I guess and I have noted it down as 
a possible extension (it is also a matter of pride... PropEr has such 
loose_tuples(), Dialyzer should have them too!). Parametrical types in 
general are not currently fully integrated in the tool (apart from lists) 
but might become so in the near future!
 

>         - what is the recommended way of handling functions that may or may 
> not throw exceptions? If otherwise returning a type T, should we use T | 
> none() or T | no_return() as return type, or should we consider that type 
> specs focus on actual return types under normal circumstances, and that 
> exceptions are in "another dimension"? I suppose it is the latter option, 
> but then one could imagine that type specs for functions could be enriched 
> with exception specifications, for example to check whether a catch clause 
> has any chance of being triggered at all? 
>

Adding none() or no_return() in a regular union of types might be useful 
from a documentation point of view, but is currently silently ignored by 
Dialyzer (if you read some of the publications about it's type system, 
namely success typings, you will understand why). Still, I wouldn't advice 
against writing such specs, as such kind of analysis might become available 
in the future (from Dialyzer or a completely different tool).

Kostis might have more to add or have a different opinion on these. I hope 
these points were helpful nevertheless!

Regards,
Stavros Aronis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110909/f580ed7b/attachment.htm>