Re: We need to add role annotations for 7.8

--===============6618939577378447331==
Content-Type: multipart/alternative; boundary=e89a8f642e1e7b57e504f55adb9f

--e89a8f642e1e7b57e504f55adb9f
Content-Type: text/plain; charset=UTF-8

Speaking from the vantage point of platform.... This pair of comments
(emphasis mine) have my alarm index on high:

On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell <[email protected]>wrote:

> I'm quite worried about this change though. I thought the default rolefor data type was nominal, as that's the safe default. *If
> the default is representational, every package author will need to be aware
> of this feature and update their packages.* That's quite a high cost.
>

On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery <[email protected]>
 wrote:

> *Nominal default breaks everything that uses newtype deriving and doesn't
> have role annotations, doesn't it?* Representational default means things
> behave in 7.8 as they did in earlier GHCs.
>

Am I reading these pair of statements correctly? It seems to imply to me
that *every* parameterized type that uses a type constraint on a parameter
*must* be reviewed and possibly annotated to work correctly, one way or the
other!

Seems so:

On Fri, Mar 14, 2014 at 7:22 AM, Richard Eisenberg <[email protected]>
 wrote:

> So, the best thing we came up with is this: Libraries that wish to export
> abstract data types must do two things:
> 1. Manage export lists carefully.
> *2. Use role annotations.*
>

This is huge order, and one that will produce significant strain on the
ecosystem. For one, this will set back Haskell Platform months: We have
250k lines of Haskell by 30+ authors that will need to be reviewed and
updated.

And all of this is so that data types can be coerced more safely? While I'm
all for safely, the number of places where coercion is that important seems
very small... and this addition to the language and burden on the libraries
very high.

If this feature cannot be added safely without reviewing 1/4 million lines
of library code (not to mention all of hackage)... Then I think it isn't
ready and shouldn't be released in 7.8.

- Mark

--e89a8f642e1e7b57e504f55adb9f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">Speaking from the vantage point=
 of platform.... This pair of comments (emphasis mine) have my alarm index =
on high:</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote">

On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr"><div>I&#39;m quite worried about this change though. I tho=
ught the default <span class=3D"">role</span> for data type was nominal, as=
 that&#39;s the safe default. <b>If the default is representational, every =
package author will <span class=3D"">need</span> to be aware of this featur=
e and update their packages.</b> That&#39;s quite a high cost.</div>



</div><div class=3D""></div></blockquote></div><br>On Fri, Mar 14, 2014 at =
6:00 AM, Brandon Allbery=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:allbe=
[email protected]" target=3D"_blank">[email protected]</a>&gt;</span>=C2=A0w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D""><b>Nominal default breaks everything that uses newtype deriving=
 and doesn&#39;t have role annotations, doesn&#39;t it?</b> Representationa=
l default means things behave in 7.8 as they did in earlier GHCs.</div>

</div></div></div></blockquote><div><br></div><div>Am I reading these pair =
of statements correctly? It seems to imply to me that <i>every</i> paramete=
rized type that uses a type constraint on a parameter <i>must</i>=C2=A0be r=
eviewed and possibly annotated to work correctly, one way or the other!</di=
v>

<div><br></div><div>Seems so:</div><div><br></div><div>On Fri, Mar 14, 2014=
 at 7:22 AM, Richard Eisenberg=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto=
:[email protected]" target=3D"_blank">[email protected]</a>&gt;</span>=C2=
=A0wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<div>So, the best thing=C2=A0<span class=3D"">we</span>=C2=A0came up with i=
s this: Libraries that wish to export abstract data types must do two thing=
s:</div><div>1. Manage export lists carefully.</div><div><b>2. Use=C2=A0<sp=
an class=3D"">role</span>=C2=A0<span class=3D"">annotations</span>.</b></di=
v>

</blockquote><div><br></div><div>This is huge order, and one that will prod=
uce significant strain on the ecosystem. For one, this will set back Haskel=
l Platform months: We have 250k lines of Haskell by 30+ authors that will n=
eed to be reviewed and updated.</div>

</div><div><br></div><div>And all of this is so that data types can be coer=
ced more safely? While I&#39;m all for safely, the number of places where c=
oercion is that important seems very small... and this addition to the lang=
uage and burden on the libraries very high.</div>

<div><br></div><div>If this feature cannot be added safely without reviewin=
g 1/4 million lines of library code (not to mention all of hackage)... Then=
 I think it isn&#39;t ready and shouldn&#39;t be released in 7.8.</div>

<div><br></div><div>- Mark</div><div><br></div><div><br></div></div></div>

--e89a8f642e1e7b57e504f55adb9f--

--===============6618939577378447331==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Libraries mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/libraries

--===============6618939577378447331==--