[erlang-questions] type specification

Zoltan Lajos Kis <>
Sat Jul 3 09:55:25 CEST 2010


On 7/3/2010 9:21 AM, Kostis Sagonas wrote:
> Zoltan Lajos Kis wrote:
>>
>> Could you explain how the new export_type attribute relates to the 
>> opaque attribute?
>
> Declaring a type as opaque means that you want to keep the structure 
> private to the defining module (which of course can manipulate the 
> structure of such terms) and prevent other modules from doing 
> operations to such a term that depends on its structure; dialyzer will 
> warn you about such uses. Because the defining module can always 
> manipulate the structure of such terms, it does not make sense to 
> declare a type as opaque in some module and have it module-local 
> (i.e., not exported).
>
> Thus, an opaque type should always be exported.
>
>> In R14A it seems that if I define an opaque type (without exporting 
>> it), and try to use it in another module, dialyzer emits an unknown 
>> type warning.
>
> Yes, this is expected. You can not use remote types (types defined in 
> some other module) that are not exported by the defining module.
>
>> If I export the type the warning is not emitted, but the type is not 
>> treated as opaque anymore...
>
> Either I do not understand what you mean here, or I doubt this.  A 
> small code example with the behavior you observe will help here 
> (perhaps off list, if it is too big).
>
> Kostis

Shouldn't I be warned that b:f breaks the opaqueness of a:my_type() with 
the modules below?

Zoltan.
--------------------------------------------
-module(a).
-compile(export_all).

-opaque( my_type() :: {atom(), atom()} ).

-export_type([my_type/0]).

-spec( f(my_type()) -> atom() ).
f({A,_B}) -> A.
---------------------------------------------
-module(b).
-compile(export_all).

-spec( f(a:my_type()) -> atom() ).
f({A,_B}) -> A.
---------------------------------------------



More information about the erlang-questions mailing list