<div dir="ltr">I forgot to mention this is on 17.3 and 17.4 (note the queue:queue/1 type in the sample modules).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 December 2014 at 15:32, James Fish <span dir="ltr"><<a href="mailto:james@fishcakez.com" target="_blank">james@fishcakez.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi all,<br><br></div>I am never one to doubt that dialyzer is correct, and I am wrong. In this case I am perplexed by the warning generated with nested parametrised types. For example if a module defines the type:<br><br></div>-type myqueue(Item) :: {myqueue, queue:queue({integer(), Item})}.<br><br></div>And another module wishes to use myqueue/1:<br><br></div>-spec in(integer(), myqueue(integer()) -> myqueue(integer()).<br><br></div>Dialyzer will warn that success typing has the second argument and result of the form {myqueue, queue:queue({integer(), any()})}. What is the subtlety that I am missing?<br><br></div><div>You can find two sample modules attached. One module with a parametrised queue and another with a parametrised "parametrised" queue using the first module. Dialyzer has alot of fun with the second module. If queue:queue() was not opaque no warnings are generated and if myqueue:myqueue() is not opaque an extra warning is generated.<br></div><div><br></div>Thank you,<br><br>James<br><div><br><br></div></div>
</blockquote></div></div>