<br><br><div class="gmail_quote">2009/3/24 Brandon S. Allbery KF8NH <span dir="ltr"><<a href="mailto:allbery@ece.cmu.edu">allbery@ece.cmu.edu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div class="im"><div><div>That's my understanding, F++ types don't require any runtime lookups so inference can't surprise you. </div></div></div></div></blockquote><div><br>
</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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div class="im"><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'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>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 -> Int -> Int, and you can'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>