<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 27, 2018, at 8:16 PM, Eric Seidel <<a href="mailto:eric@seidel.io" class="">eric@seidel.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">That being said, I'm less concerned about the overloading of the function arrow because Simon seems confident that we can reliably hide it when -XLinearTypes is disabled, even if datatypes are inferred linear. That makes it opt-in complexity, which I don't have a problem with.</span></div></blockquote></div><br class=""><div class="">I agree that this is opt-in complexity. The problem is that you can't opt-in partially. That is, if someone doesn't care about levity polymorphism or multiplicity polymorphism, then they're OK. If someone cares about both, they're OK. But if someone cares only about one (which is quite sensible in either direction), then they currently have to care about both. If we imagine yet more indices on arrows (e.g. what if we track whether term-level functions are injective? what if we put roles on arrows? both are conceivable) then the situation is worse. Now might be the right time to think about a structure where we can continue to add indices to arrows without overwhelming the cognitive load.</div><div class=""><br class=""></div><div class="">Richard</div></body></html>