<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 1 Mar 2012, at 21:53, Tim Watson wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><font class="Apple-style-span" color="#000000"><br></font></div><div>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. </div><div><br></div></div></div></blockquote><br></div><div>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.</div><div><br></div></body></html>