<br><br><div class="gmail_quote">On Tue, May 24, 2011 at 4:38 AM, Richard Carlsson <span dir="ltr"><<a href="mailto:carlsson.richard@gmail.com">carlsson.richard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 05/23/2011 09:37 PM, Ryan Zezeski wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Richard, I think specifying it as [property()] makes more sense because<br>
[any()] is just a list, and at that point why are you using a proplist?<br>
</blockquote>
<br></div>
The main use of the proplists module is to allow humans to specify a list of options to a function, in a readable way. The idea, when I wrote it, was that if a program wants to allow other things in its option list - for example, a naked integer might make sense in some cases - it should still be able to use the proplists module for most of its normal options, so the proplists functions should not crash on unexpected elements. As long as this is allowed, Dialyzer should not complain about arbitrary lists as input.<br>

<br>
On the other hand, if you constrain the input type to [property()], it's fairly simple to work around the Dialyzer warning by doing an initial pass over the list and convert the naked values to valid properties, e.g., mapping integers to {some_tag, N}, before you pass the list to the proplists module.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  Said another way, if the type was [any()] then I don't really see much<br>
of a benefit of typing it at all.<br>
</blockquote>
<br></div>
Knowing that it must be a (proper) list is obviously better than not knowing anything at all.<br><font color="#888888">
<br>
   /Richard<br>
</font></blockquote></div><br><div>Richard, yes, having an alias is better than nothing at all.  I spoke too quickly there.</div><div><br></div><div>I guess everywhere I've seen proplists used it's as a map.  If it's type is really just an alias for 'list()' then a function that returns 'proplist()' could return a string and that seems counterintuitive to me.  My main use of proplists was actually as a slightly more succinct option to lists:keyfind, so take that as you may.  I could use the dict module (and I have plenty of times before) but it's pretty print form is horrible/impossible to read.</div>
<div><br></div><div>Regardless, I think adding a proplist() type is a good step and we seem to all agree there.  If you want to change the type to be an alias of list() then that's fine, it would actually be more correct given what proplists documentation says.  But, personally, I'd prefer it to be more restrictive.</div>
<div><br></div><div>-Ryan</div>