<div style="text-align: left;"><font face="sans-serif" size="2">Hi Olivier,</font></div><div style="text-align: left;"><font face="sans-serif" size="2"><br></font></div><div style="text-align: left;"><font face="sans-serif" size="2">Some answers to your questions:</font></div><div style="text-align: left;"><font face="sans-serif" size="2"><br></font></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><font size="2"><font face="sans-serif">        -
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?</font>
<br></font></blockquote><div><font size="2"><br></font></div><div><font size="2">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).</font></div><div><font size="2"> </font></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><font size="2">
<font face="sans-serif">        -
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?</font></font></blockquote><div><font size="2"><br></font></div><div><font size="2">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!</font></div><div><font size="2"> </font></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><font size="2"><font face="sans-serif">        -
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?</font>
<br></font></blockquote><div><font size="2"><br></font></div><div><font size="2">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).</font></div><div><font size="2"><br></font></div><div><font size="2">Kostis might have more to add or have a different opinion on these. I hope these points were helpful nevertheless!</font></div><div><font size="2"><br></font></div><div><font size="2">Regards,</font></div><div><font size="2">Stavros Aronis</font></div>