[erlang-questions] Dialyzer and ets:fun2ms

[Kostis Sagonas]

On 06/21/2012 07:27 PM, Anthony Molinaro wrote:
> I came across this same issue yesterday, anyone from the dialyzer team want
> to comment on a better way to deal with records in matchspecs?

Currently, there is really good way to deal with this problem....

(However note that the problem appears *only* if you type records.)


In my opinion, whoever added match specs in the language clearly was not 
thinking straight. They overloaded some random terms, namely the atoms 
'_', '$1', '$2', ... which, although admittedly quite uncommon, are 
perfectly valid Erlang atoms that applications can freely use if they 
want to to mean something completely different than they do in 
matchspecs.  Sooner or later, this was bound to surface as a problem...

Nowhere else in the language is there specified that these atoms cannot 
be used by applications as regular atoms.  Consequently, dialyzer does 
not (and will not!) treat them specially.  In my opinion, there should 
be a DSL for matchspecs that does not clash with the rest of the Erlang 
language.

In the meantime, the best "solution" I see to this problem is to define 
the following type:

   -type matchspec_atom() :: '_' | '$1' | ... | '$42'.

and use it in whatever record field names are used in matchspecs in your 
code. I.e.:

-record(myrecord, {field = 0 :: integer() | matchspec_atom(),
                    roses = red :: 'red' | 'blue' | matchspec_atom()}).

Hope this helps,

Kostis


> On Tue, May 22, 2012 at 01:39:10PM -0700, Geoff Cant wrote:
>> Hi all, I have hit this problem with my code and dialyzer a few times now and wonder what everyone else does to avoid it.
>>
>> I have record definitions with type specifications as follows:
>>
>>> -module(rec_example).
>>>
>>> -export([find_by_colour/1]).
>>>
>>> -include_lib("stdlib/include/ms_transform.hrl").
>>>
>>> -record(myrecord, {field = 0 :: integer(),
>>>                     roses = red :: 'red' | 'blue'}).
>>>
>>
>> I then add some functions that use ets matchspecs or a fun2ms transform and have to fill in fields with dummy values as required by the API (e.g. '_' and '$1'):
>>
>>> find_by_colour(Colour) when is_atom(Colour) ->
>>>      ets:lookup(myrecords, ets:fun2ms(fun (#myrecord{roses=C})
>>>                                             when C =:= Colour ->
>>>                                               object()
>>>                                       end)).
>>
>>
>> Dialyzer complains that this function can't succeed:
>>
>>> rec_example.erl:10: Function find_by_colour/1 has no local return
>>> rec_example.erl:11: Record construction #myrecord{field::'_',roses::'$1'} violates the declared type of field field::integer() and roses::'blue' | 'red'
>>
>>
>>
>> To me this seems like reasonable code to want to write, but dialyzer hates it. The two (terrible) solutions I've found to avoid the dialyzer warnings are to add the dummy values to the record type spec:
>>
>>> -record(myrecord, {field = 0 :: integer() | '_',
>>>                     roses = red :: 'red' | 'blue' | '$1'}).
>>
>>
>> Or to hide the record construction from dialyzer by constructing the matchspec using functions. First run fun2ms manually to get:
>>
>>> [{#myrecord{field = '_',roses = '$1'},
>>>    [{'=:=','$1',Colour}],
>>>    ['$_']}]
>>
>>
>> Which still complains, so you then do something far worse:
>>
>>> [{list_to_tuple([myrecord, '_', '$1']),
>>>    [{'=:=','$1',Colour}],
>>>    ['$_']}]
>>
>>
>> Clearly none of these options are good - what's a better way to have record type specs and matchspecs and no dialyzer warnings? Or is there something I'm missing that replaces my use of matchspecs and avoids the problem?
>>
>>
>> Cheers,
>> --
>> Geoff Cant
>>
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>