<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 2:10 AM, Vlatko Basic <span dir="ltr"><<a href="mailto:vlatko.basic@gmail.com" target="_blank">vlatko.basic@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 bgcolor="#FFFFFF" text="#000000">
    I think I understand now why compiler calls it rigid and not
    "flexible" or whatever.<br>
    It is because the call site defines the parameter type, and when
    that parameter comes to function, its type is already rigidly
    determined. We just do not know its type. So the type is rigidly
    unknown, and not flexible.</div></blockquote></div><br></div><div class="gmail_extra">Counterexample:<br><br></div><div class="gmail_extra">id2 :: a -> a<br></div><div class="gmail_extra">id2 = id . id<br></div><div class="gmail_extra">

<br></div><div class="gmail_extra">You're getting closer, but if you think of it from the viewpoint of the programmer who wrote the compiler (the same one who's wording all these error messages), it becomes really clear.<br>

<br></div><div class="gmail_extra">What you've basically got before you is an algorithm to check the validity of types.<br><br>So whereas the thing in question (whatever's denoted by 'a') is called a type 'variable', it doesn't 'vary' in (I'm guessing) the OO way. <br>

<br>When checking the types in your function, 'a' is fixed, i.e. made rigid, by what's known as a 'universal quantification'. So when you code up the type checking algorithm, you'd see a crystal-clear similarity to treating 'a' as if it were a monotype like Bool or String.<br>

<br>When checking the types in _uses_ of your function (say, something similar to 'id True') _that's_ when 'a' varies, i.e. in the sense that each use may fix 'a' to something different.<br><br>

</div><div class="gmail_extra">Overall, I think you're doing really well for someone groping with Haskell general and its type system in particular. The lingo can be misleading.<br><br></div><div class="gmail_extra">
Personally, I think a lot can be made to fill the gap between trial-and-discovery and reading notationally-heavy formal texts like conf papers and textbooks (Pierce's TAPL).<br>
</div><div class="gmail_extra"><br clear="all"><div>-- Kim-Ee</div>
</div></div>