<div dir="ltr">Yes, and a large part of this being that hiding stuff tends to come back and bite you when you need the internals anyway at some point. This leads to .Internals modules and such in the end, sometimes retrofitted when the need is realized.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 8:15 AM Mikolaj Konarski <<a href="mailto:mikolaj@well-typed.com">mikolaj@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br>
<br>
> I am aware that the signature of fromBase states that for all 'b' of Base<br>
> an Extend of type 'a' must be able to be made.<br>
> Yet, in my case 'a' is a parameterized class 'BaseExpose x' and<br>
> since the type of Extend is provided (it is a constructor)<br>
> I think it is acceptable that 'BaseExpose b' is returned as type.<br>
<br>
I'm afraid I'm agreeing with the compiler here. When you instantiate this class<br>
<br>
class Base a => Extend a where<br>
  fromBase :: Base b => b -> a<br>
<br>
so that `a` is `BaseExpose x`, then you need to implement<br>
<br>
  fromBase :: Base b => b -> BaseExpose x<br>
<br>
and your fromBase' has a less general type<br>
<br>
  fromBase' :: Base x => x -> BaseExpose x<br>
<br>
and that's it. It's the same issue as when you try<br>
to typecheck `id :: a -> b`. If it type-checked, you could<br>
write (pure) crashing type-correct code.<br>
<br>
I don't have enough data, but I guess you don't need `fromBase`<br>
at all. if `a` is `Base`, then it's also `Extend`, as long as you<br>
implement any extra operations. You don't need to coerce it<br>
to `Extend` with `fromBase`.<br>
<br>
BTW, as opposed to object oriented programmers,<br>
I think most of us doesn't use the class system<br>
for encapsulation, but the module system instead<br>
(with all its limitations). If the module system is not enough<br>
for you and you are ready for the bleeding edge,<br>
the Backpack may have what you need. Having said that,<br>
I think we usually err on the side of exposing too much,<br>
with all the simplicity and testing ease benefits it provides,<br>
rather than on the side of hiding too much. The user of a library<br>
is free to encapsulate more strongly in his import lists<br>
or by defining an interface module. Only the user knows<br>
his use case.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>