[erlang-questions] Module language for Dialyzer?

[Anthony Ramine]

A module can do all that with behaviours.

Just write a dict behaviour.

Le 6 oct. 2013 à 08:08, Siraaj Khandkar a écrit :

> 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 :)
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-- 
Anthony Ramine