[erlang-questions] Dialyzer and numeric range values

[zxq9]

On 2017年11月01日 水曜日 07:27:35 Fred Hebert wrote:
> On 11/01, zxq9 wrote:
> >What is going on here? Is this a new thing with R20's Dialyzer, or have 
> >I just never noticed these multi-byte leaps in value range resolution?
> 
> You never noticed it. Dialyzer kind of keeps the right to expand ranges 
> arbitrarily. You can see in the source code that anything set of types 
> above 12 gets merged into one:
> https://github.com/erlang/otp/blob/fe1df7fc6bf050cb6c9bbd99eb9393c426b62f67/lib/hipe/cerl/erl_types.erl#L1997-L2011
> 
> The same kind of stuff also happens with atoms or even types in general 
> (https://github.com/erlang/otp/blob/fe1df7fc6bf050cb6c9bbd99eb9393c426b62f67/lib/hipe/cerl/erl_types.erl#L4860-L4866) 
> which can be merged into the any() type.
> 
> It's frankly a bit of a bummer but I figure it's something Dialyzer does 
> to be less memory-hungry, at the cost of accuracy.

Hah! Wow. That's a pretty darn steep range curve on numerics!

Incidentally, also one of the only apt uses of an `if` I've seen in a while.

I've stayed away from Dialyzer internals for a reason (I get sort of obsessed about such things) but I wonder if it wouldn't be possible to establish numeric ranges as test ranges instead of enumerations?

It seems like this is the case, actually, but obviously I am missing something if they can't set ?int_range(X, Y) directly and must instead only ever set either ?int_range(1, ?MAX_BYTE) or ?int_range(1, ?MAX_CHAR).
https://github.com/erlang/otp/blob/fe1df7fc6bf050cb6c9bbd99eb9393c426b62f67/lib/hipe/cerl/erl_types.erl#L342

The only place this approach seems to hold is called t_from_range_unsafe/2.
https://github.com/erlang/otp/blob/fe1df7fc6bf050cb6c9bbd99eb9393c426b62f67/lib/hipe/cerl/erl_types.erl#L2018
I assume "unsafe" for a reason, though the expected tests actually do exist.
https://github.com/erlang/otp/blob/fe1df7fc6bf050cb6c9bbd99eb9393c426b62f67/lib/hipe/cerl/erl_types.erl#L2101

Hm. So I'm just puzzled at the reasoning behind the need to enumerate ranges, and then the presence code that doesn't need ranges to be enumerated. Even more to the point, why not a list of arbitrary ranges? Too slow? Hard to imagine speed is the primary concern. Perhaps simply some work that never quite got polished off because, well, Dialyzer is already super useful in 90% of cases?

Anyway, thanks for pointing that out. Quite interesting.

-Craig