[erlang-questions] Module language for Dialyzer?

[Siraaj Khandkar]

There are similarities, but they're different levels of abstraction. 
Behaviours require one to satisfy an interface, but behaviours are just 
one use of interfaces. The best analogue to Erlang behaviour is probably 
the ML functor, where a general module is parametrized by a specific module.

I don't think I need to convince anyone that verified [1] contracts 
between software components is an extremely helpful thing (and Dialyzer 
helps quite a bit). The new thing that I am asking about is 
composability of generic interfaces - I want interfaces that live 
independently of implementations. So just like you have a library of 
modules and functions that you may choose from to assemble just the 
module/function that you want, I'd like to be able to define a library 
of interfaces that I may use to assemble just the _type_ of module I 
need. Besides composability, this would be a big win for achieving 
uniformity within a large system (the thing I'm mainly after).

Don't stop at just thinking about interfaces as a collection of function 
specs, the biggest win of interfaces is abstraction of types. An 
interface defines an opaque type and the operations allowed on that 
type, so as long as you adhere to the interface and do not violate the 
opaqueness of the type - you can easily swap concrete implementations of 
that abstract type.

Let's take a concrete example: a dictionary type. stdlib offers several 
alternatives for a key-value data structure, while conceptually each can 
be thought of as a dictionary, they all expose a completely different 
interface. There's already been talk about unifying their interfaces, so 
wouldn't it be nice to define a uniform "dict" interface and just say:

gb_trees.erl
     -module(gb_trees).
     -implements([dict]).
     ...
dict.erl
     -module(dict).
     -implements([dict]).
     ...
orddict.erl
     -module(orddict).
     -implements([dict]).
     ...

... instead of having to check manually weather the exposed interfaces 
are compatible?

Furthermore, a module can claim to implement several interfaces (note 
the stringable example from my first email).


[1]: I use the term loosely.

On 10/04/2013 01:21 AM, Pierre Fenoll wrote:
> A module spec can be useful to throw compile-time warnings when implementing generic handlers.
> (A generic handler being a collection of functions calling specific functions from another module.)
>
> Though, a "module signature" already exists (-callback used in pair with -behavior), currently there is no way to check if the other module implements the required functions.
> I think it would be a great addition.
>
>> On 4 oct. 2013, at 03:48, Siraaj Khandkar <siraaj@REDACTED> wrote:
>>
>> What are the theoretical problems (if any) with an idea of extending Dialyzer with a module language to express composable interfaces in the spirit of SML?
>>
>> Something along the line of:
>>
>> dict.esig:
>>     -signature(dict) ::
>>     sig
>>         -type t(K, V) :: opaque().
>>         -fun new() -> t(K, V).
>>         -fun add(t(K, V), K, V) -> t(K, V).
>>         -fun find(t(K, V), K) -> none | {some, V}.
>>         ...
>>     end.
>>
>> stringable.esig:
>>     -signature(stringable) ::
>>     sig
>>         -type t() :: opaque().
>>         -fun to_string(t()) -> string().
>>         -fun of_string(string()) -> t().
>>         ...
>>     end.
>>
>> my_serializable_dict.erl:
>>     -module(my_serializable_dict).
>>     -implements([dict, stringable]).
>>     ...
>>
>>
>> Syntax is not the point of this, so don't get hung-up on it for the purpose of this question - I'm making it up as I type :)