[erlang-questions] Type Server

[Tim Watson]

I just found this on line 3179 of erl_types

%% Abstract records. Used for comparing contracts.
%% 

-spec t_abstract_records(erl_type(), dict()) -> erl_type().

And a bit later on....

%% Map over types. Depth first. Used by the contract checker. ?list is


This sounds like almost 'exactly' what I'm after as a standalone thing. The contract checker is presumably looking at the compatibility of function type signatures. That's what I want to do - preferably without making a pigs ear of it by trying to write it myself.

Cheers,

Tim

On 2 Mar 2012, at 00:25, Tim Watson wrote:

> And what I'm really after figuring out, is whether dialyzer_codeserver is a useful interface to the type information. After poking around a little bit, it looks like Richard C's erl_types module is the API that I'm looking for. That appears to be part of hipe, which isn't always present in a release, so I'm not sure if I should be relying on it. 
> 
> On 1 Mar 2012, at 22:03, Tim Watson wrote:
> 
>> On 1 Mar 2012, at 21:53, Tim Watson wrote:
>>> 
>>> 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. 
>>> 
>> 
>> Concrete example of this would be, how can I determine if a type is a generalisation/specialisation of another type? For example the relationship between list(term()) and list(atom()) or between tuple(term(), term()) and tuple(atom(), term()) where the type restriction is either narrowing or widening. I am fully aware there is no 'sub-typing' and that's not what I'm trying to do - I'm interested in using the type spec to identify, from a compatibility perspective, how the dispatch should work, so that I can rewrite either the caller or the callee to make the dispatch work properly - I'd prefer the latter, but that requires a bit more support from the -implements collaborator around identifying whether an arbitrary term is of a suitable type.
>> 
> 

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