[erlang-questions] Type Server

[Tim Watson]

Hi Stavros,

Ok sorry for not stating my aims so clearly. I am looking at various ways to formalise my API declarations and make dynamic binding to implementations cleaner than having code that does `Mod = orddict, ...'. So for example, to go back to the recent discussions about having a unified API for dict. Instead of 

Mod = orddict,
%% some more code...
Mod:fetch(.....)

I would like to be able to bind to an implementation once, and then after that use the generic module/api in my code:

true = dictionary:is_key(a, dict:from_list([{a, 1}])),
true = dictionary:is_key(a, orddict:from_list([{a, 1}])),
true = dictionary:is_key(a, gb_trees:from_orddict(orddict:from_list([{a, 1}]))).


So I was thinking about various ways to bind these, both at compile time and at runtime based on the conversation about Clojure's 'prototypes'. My general thought is that an implementation of the 'prototype' behaviour defined by the 'dictionary' module will basically be resolved based on the type(s) of the 1..* arguments the various behaviour callback functions are bound over. So if you've defined is_key like so:

-spec is_key(term(), dictionary:instance(dictionary:unbound_type_parameter())) -> boolean(). 

then you will create many instances, one for dict, one for orddict, one for gb_trees, etc. Where the module 'natively' implements the interface, there's little work to do other than 'stating' (or registering somehow) that you consider it an implementation/instance of the prototype - forgive me I don't have a better term for this. For gb_trees, you'd basically write an implementation for each of the prototype's functions that need 'rewiring', such that you'd get

-module(gb_trees_dictionary).
-implements(dictionary, gb_trees:gb_tree()).

-spec is_key(term(), dictionary:instance(gb_trees:gb_tree())) -> boolean().
is_key(K, D) -> 
    gb_trees:is_defined(K, D).


At compile time (or at runtime, possibly though beam code rewriting), I want to use the type specs for the various -implements modules (which could equally be declared anonymously using funs) to resolve the callee. Currently, there's very little to help me work with type specs. I can pull them out of the abstract code, but they're pretty 'low level' structures and AFAIK aren't documented anywhere. Now I'm simply assuming that there is loads of useful code in PropEr and Dialyzer that 'understands' these spec related data structures and was hoping I could make use of it, rather than learn my way around by fumbling in the dark. 

Hope that makes sense of how I'm trying to save myself a bit of time.

Cheers,

Tim

On 1 Mar 2012, at 21:03, Stavros Aronis wrote:

> Hi Tim!
> 
> I am not sure what you mean by a "type server", as Dialyzer does not really have a "component" that I could imagine being separated and labeled so. Dialyzer has the ability to store the specs and exported types in the PLT and from there use them to increase the precision of the analysis it performs.
> 
> What do you mean by "working with types"?
> 
> Regards,
> Stavros
> 
> On Thursday, March 1, 2012 4:43:33 PM UTC+1, Tim Watson wrote:
> Hi all,
> Both PropEr and Dialyzer appear to have a 'type server' that provides functions for working with type specs. What are the chances of this being available as a separate unit? There is currently very little support for working with types, as the previous post about lack of support in erl_syntax pointed out. It would be nice to see type specs being better supported.
> 
> Cheers,
> 
> Tim
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120301/a45c0fc6/attachment.htm>