Re: We need to add role annotations for 7.8

--===============8297781821179510103==
Content-Type: multipart/alternative; boundary=001a1134635ad6b1b404f55c2ac5

--001a1134635ad6b1b404f55c2ac5
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Mar 24, 2014 at 10:57 AM, Brandon Allbery <[email protected]>wrote:

> No? Immediately switching to nominal requires those annotations
> immediately. No immediate change is needed if we keep the current default;
> if you have problems with conditional code, you will have them no matter
> what with roles --- the only question is when. Also see SPJ's response.
>

I don't think this is true. If nominal-by-default is not on the road map,
then most people never have to do anything. If I can generalize about
myself at least, most data types that are defined do not have (additional,
role-enforceable) invariants. They are mainly simple combinations of other
types in ways that allow me to structure my code well. So the vast majority
of types defined by people like me should have representational parameters,
unless one of the constituent types is a Set or Map or what have you, in
which case nominal can be inferred, assuming Set and Map are appropriately
annotated. Nominal-by-default would require annotations for every minor
definition like this in order to correctly specify the type.

By contrast, representational-by-default imposes some work/diligence on
authors of data structures with invariants, which tend (in my experience)
to be the minority of definitions, and typically come as libraries.

I feel a little bad suggesting 'unsafety' as the default, but the safe
default imposes a significant, perpetual cost on everyone using the
language in return for defense against occasional oversights by library
authors. That doesn't seem like a good trade off.

--
 Dan

--001a1134635ad6b1b404f55c2ac5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On Mon, Mar 24, 2014 at 10:57 A=
M, Brandon Allbery <span dir=3D"ltr">&lt;<a href=3D"mailto:allbery.b@gmail.=
com" target=3D"_blank">[email protected]</a>&gt;</span> wrote:<br><div cl=
ass=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>No? Immediately switching to nominal requir=
es those annotations immediately. No immediate change is needed if we keep =
the current default; if you have problems with conditional code, you will h=
ave them no matter what with roles --- the only question is when. Also see =
SPJ&#39;s response.</div>
</div></div></div></blockquote><div><br><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif">I don&#39;t think this is true.=
 If nominal-by-default is not on the road map, then most people never have =
to do anything. If I can generalize about myself at least, most data types =
that are defined do not have (additional, role-enforceable) invariants. The=
y are mainly simple combinations of other types in ways that allow me to st=
ructure my code well. So the vast majority of types defined by people like =
me should have representational parameters, unless one of the constituent t=
ypes is a Set or Map or what have you, in which case nominal can be inferre=
d, assuming Set and Map are appropriately annotated. Nominal-by-default wou=
ld require annotations for every minor definition like this in order to cor=
rectly specify the type.<br>
<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif">By contrast, representational-by-default imposes some work/dil=
igence on authors of data structures with invariants, which tend (in my exp=
erience) to be the minority of definitions, and typically come as libraries=
.<br>
</div><br><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif">I feel a little bad suggesting &#39;unsafety&#39; as the defau=
lt, but the safe default imposes a significant, perpetual cost on everyone =
using the language in return for defense against occasional oversights by l=
ibrary authors. That doesn&#39;t seem like a good trade off.<br>
</div><br>--<div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;display:inline"> Dan</div><br></div></div></div></div>

--001a1134635ad6b1b404f55c2ac5--

--===============8297781821179510103==
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

--===============8297781821179510103==--