Well, you can get part of the way there, by using a class associated type<br><br>class HasOpen a where<br>   type Open a :: *<br>   open :: a -&gt; Open a<br><br>This lets you use type inference in one direction, without requiring that every result be a member of a data family. On the other hand, type inference just became directional, like in C#. you can&#39;t use the type of Open a to infer the type a because you&#39;ve lost injectivity. <br>
<br>You&#39;d need a data type family to guarantee injectivity and determine a from the context of Open a, and that yields an ugly mess. Since each container would have to yield a distinct value type and interoperability goes out the window.<br>
<br>On the other hand, the mixture of fixed type slots and type family slots gets you a pretty good compromise. You typically know the type of the structs whose members you are asking for.<br><br>-Edward Kmett<br><br><br>
<div class="gmail_quote">On Wed, Jan 13, 2010 at 2:08 PM, John Millikin <span dir="ltr">&lt;<a href="mailto:jmillikin@gmail.com">jmillikin@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;">
The usual suggestion I see for this sort of thing is to create a<br>
typeclass for the operations you care about[1][2]. For example:<br>
<br>
-------------------------------------------------------------------------------------------<br>
class HasOpen a where<br>
  open :: a -&gt; Handle<br>
<br>
data DB<br>
data FS<br>
<br>
openDB :: DB -&gt; Handle<br>
openFS :: FS -&gt; Handle<br>
<br>
instance DB HasOpen where open = openDB<br>
instance FS HasOpen where open = openFS<br>
-------------------------------------------------------------------------------------------<br>
<br>
Of course, this doesn&#39;t allow you to have functions share the same<br>
name if they have different signatures, as in your (open :: FS -&gt;<br>
File) example. To be honest, I think the C / Haskell approach of<br>
unambiguously-identified functions is clearly superior to the C++ / C#<br>
/ Java &quot;class as namespace&quot; idiom, which has caused me no end of<br>
grief.<br>
<br>
Dynamic languages such as Python and Ruby, of course, can return<br>
anything from anywhere. This is nice in some cases, but having used<br>
both extensively I think (static typing+inference) is a better<br>
solution than dynamic typing.<br>
<div class="im"><br>
&gt; Now, in Haskell we have type inference, which is &quot;The Good Thing&quot; as<br>
&gt; it allows to &quot;validate&quot; your program at compile time. Hence, the idea<br>
&gt; coming up to my mind is that type inference actually forbids a<br>
&gt; type-directed resolution of names as in C++ or Java.<br>
&gt;<br>
&gt; Is this correct?<br>
<br>
</div>Type inference and static typing are separate; inference makes static<br>
typing usable, but static typing makes compile-type correctness<br>
verification easier. And it&#39;s not inference making your goal<br>
impossible, but the fact that Haskell (like C) does not support<br>
arbitrary overloading.<br>
<br>
[1] <a href="http://www.mail-archive.com/haskell-cafe@haskell.org/msg64844.html" target="_blank">http://www.mail-archive.com/haskell-cafe@haskell.org/msg64844.html</a><br>
[2] <a href="http://stackoverflow.com/questions/1897306/haskell-record-syntax-and-type-classes" target="_blank">http://stackoverflow.com/questions/1897306/haskell-record-syntax-and-type-classes</a><br>
<div><div></div><div class="h5">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>