<br><br><div class="gmail_quote">On Tue, Mar 24, 2009 at 6:02 PM, Peter Verswyvelen <span dir="ltr">&lt;<a href="mailto:bugfact@gmail.com">bugfact@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote">2009/3/24 Brandon S. Allbery KF8NH <span dir="ltr">&lt;<a href="mailto:allbery@ece.cmu.edu" target="_blank">allbery@ece.cmu.edu</a>&gt;</span><div class="im"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div style=""><div><div><div>That&#39;s my understanding, F++ types don&#39;t require any runtime lookups so inference can&#39;t surprise you.  </div></div></div></div></blockquote><div><br>
</div></div><div>It uses .NET interfaces for that, but the F# expert book mentions they would like to have type classes in a future version of the language.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div style=""><div><div><div>in Haskell can do unexpected things:  F++ has parenthesized function arguments, so it will catch too few/too many arguments directly, but Haskell&#39;s uncurried function call notation almost guarantees strange errors in those cases even if you have everything explicitly typed.</div>

</div></div></div></blockquote><div><br></div></div><div>Not really, F# has both curried and uncurried forms, just like Haskell.</div><div><br></div><div>It is true that F# encourages automatic generalization without type signatures. You never need to give one, even for exported modules.</div>

<div><br></div><div>But the lack of type classes has its price. E.g.</div><div><br></div><div>add x y = x + y</div><div><br></div><div>What is the type of add in F#?</div><div><br></div><div>Well, that depends on the first usage of this function... Give it Ints and it becomes add :: Int -&gt; Int -&gt; Int, and you can&#39;t use it on Doubles any more. Very confusing, since you can use the overloaded (+) on any type. These are current limitations of the language.</div>

<div><br></div><div>At least that what I understood from it...</div><div><br></div></div>
</blockquote></div><br>What you say is partially true.  For example, if delcared as you typed it, a rule similar to the monomorphism restriction (from what I understand of the monomorphism restriction) applies.  If it&#39;s never used, x and y are of type int, and if they are used, x and y pick up the type of whatever you call it with.  So doubles if you invoke it with 3.0 and 4.0, ints if you invoke it with 3 and 4, and an error if you invoke it once with doulbes and once with ints.   <br>
<br>The F# answer to this is to &quot;inline&quot; the function.  For example:<br><br>let inline add (x:&#39;a) (y:&#39;a) : &#39;a = x+y<br><br>let result1 = add 3 4<br>let result2 = add 3.0 4.0<br><br>Hover over this declaration of add to get its type and you see &quot;add : &#39;a -&gt; &#39;a -&gt; &#39;a (requires member (+))<br>
<br>Here, result1 is an int and result2 is a double.  I haven&#39;t heard this from straight from the developers, but I suspect inlining is necessary due to the .NET Framework&#39;s support for reflection.  Consider, for example, what would happen if you tried to obtain the method add via reflection and there was code for exactly 1 add method present in the binary.  The code would have no reasonable way to behave.  By inlining, I believe it inserts multiple definitions of hte function into the code, similar to what you get when you instantiate a C++ template.  <br>
<br>Anyway, a bit off topic, but at the very least I&#39;m starting to understand why it&#39;s ok in F# but not really so much in Haskell.  The issue of documenting the function I think is kind of a non issue actually, because if it were really just for the purposes of documentation you could just comment out the the type signature so that it&#39;s still visible but not interpreted by the compiler.  In F# though the documentation is even less of an issue since you get automatic mouse-hover type definitions.  The same thing applies to the issue of detecting type errors.  It&#39;s pretty easy to find them when all the type inference mismatches are underlined for you on the fly.  But in Haskell it seems the problem of finding type errors is made more difficult not only by the lack of a helpful syntax underliner, but also by the typeclasses, which make the errors even more far removed from what you would expect.  Not to mention the performance penalties associated with making something too generic, which I didn&#39;t think of originally.  <br>