<br><br><div class="gmail_quote">2011/7/4 Kostis Sagonas <span dir="ltr"><<a href="mailto:kostis@cs.ntua.gr">kostis@cs.ntua.gr</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">Jesper Louis Andersen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, Jul 3, 2011 at 11:58, Michael Richter <<a href="mailto:ttmrichter@gmail.com" target="_blank">ttmrichter@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 3 July 2011 16:10, Roberto Ostinelli <<a href="mailto:roberto@widetag.com" target="_blank">roberto@widetag.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
a very stupid spec declaration question. how can you declare the specs of<br>
a function which has a single list with multiple arguments?<br>
<br>
For instance, consider this function:<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
myfun([One, Two]) -><br>
</blockquote></blockquote>
<br>
This is better since you then have a product type rather than a<br>
recursive type on lists. It is much simpler to work with from a typing<br>
perspective. Also note that you would not easily be able to type<br>
["hello", 5] in a statically typed language without resorting to<br>
either some kind of type tagging, polymorphic variants or existential<br>
types.<br>
<br>
My advice would be to alter the structure of the function such that it<br>
is easier to type. It tends to be safer from a programming perspective<br>
as well.<br>
</blockquote>
<br></div></div>
Both Jesper and Michael have given very good advice on this topic, but for the record, I guess, let me add my two cents here.<br>
<br>
First of all, as others have mentioned, when grouping together a fixed number of items, tuples rather than lists should better be used. Not only does this make sense from a typing perspective, but for more than one item tuples are also more memory efficient and thus slightly faster. For example [One, Two] needs 4 words while {One, Two} needs 3.<br>

<br>
Coming back to the original question, it's pretty clear that what the type language does it to make a abstraction over all terms (which belong to some type) and thus cannot possibly express all programmer intentions accurately. For example, it is currently not possible to declare lists with a certain number of elements, partly due to the fact that the type language has decided to make [T] an alias for list(T). Even if this constraint was lifted (e.g. [T] stood for a one element list for items of type T, [T1,T2] for a two element list of items of type T1 and T2, etc.) the type language would not be able to express all programmer intentions (e.g. lists of an even number of elements, lists whose length is a prime number, lists where the middle element is 42, etc.). This is fundamental limitation of all type languages: no matter how expressive they become, there are things that cannot (conveniently) be expressed in them.<br>
<font color="#888888">
<br>
Kostis<br>
</font></blockquote></div><br>Jesper and Michael,<br><br>thank you for your feedback on this. I am aware of the necessity of using tuples in this condition instead of lists. However, I was using a library whose callback function is getting arguments as list.<br>
<br>Kostis, thank you for clarifying this.<br><br>Cheers,<br><br>r.<br>