<div dir="ltr">Wouldn't the implementation hiding feature of the <i>newtype </i>idiom be broken, if field selectors were not first class functions? For instance, the following code (taken shamelessly from Ch. 10 of <i>Real World Haskell</i>):<div>
<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="courier new, monospace" size="1">module Parse (</font></div></div><div><div><font face="courier new, monospace" size="1"> runParser</font></div>
</div><div><div><font face="courier new, monospace" size="1">) where</font></div></div><div><div><font face="courier new, monospace" size="1"><br></font></div></div><div><div><font face="courier new, monospace" size="1">data ParseState = ParseState {</font></div>
</div><div><div><font face="courier new, monospace" size="1"> string :: String</font></div></div><div><div><font face="courier new, monospace" size="1">} deriving (Show)</font></div></div><div><div><font face="courier new, monospace" size="1"><br>
</font></div></div><div><div><font face="courier new, monospace" size="1">newtype Parser a = Parser {</font></div></div><div><div><font face="courier new, monospace" size="1"> runParser :: ParseState -> Either String (a, ParseState)</font></div>
</div><div><div><font face="courier new, monospace" size="1">}</font></div></div></blockquote><div><br></div><div>has the attractive feature of hiding the internal implementation of the <i>ParseState </i>and <i>Parser </i>types from the user, preventing him from, for instance, pattern matching on either and thus writing code, which may break when we change the implementation. I believe this is only possible, because the <i>runParser </i>accessor is exportable as a first class function.</div>
<div><br></div></div>