<div dir="ltr"><div><div><div><div><div>Personally I'm not convinced by the motivation for deprecating '*': "GHC's ability to parse <code>*</code> has a significant cost.". There are two kinds of cost here:<br></div>1. implementation complexity<br></div>2. potential for users to be confused<br><br></div>for (1), Haskell historically has not made concessions in the name of implementation simplicity, other concerns have tended to rate more highly: familiarity, conciseness, consistency, ease of use and so forth. (for an example of this tradeoff in action just look at the layout rule).<br><br></div><div>for (2), I think even though we strive for consistency in language design, humans actually cope with exceptions very well - a few quirks here and there actually help us remember things.  So the current situation isn't terrible, in my view.<br></div><div><br></div>Furthermore in this case we're also fighting inertia: there's a lot of code, documentation and other materials using the existing syntax.<br><br></div>Perhaps '*' wouldn't be what we would choose if we had a clean slate, but at this point I think changing it is likely worse than not changing it.<br><div><br></div><div>Cheers<br></div><div>Simon<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 February 2018 at 03:54, Manuel M T Chakravarty <span dir="ltr"><<a href="mailto:chak@justtesting.org" target="_blank">chak@justtesting.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, existing code uses ’Type’, but it also uses ’*’ (GHC included) — i.e., this change is going to be a pain for some devs anyway. A pragma that couples the removal of ’*’ as a synonym for ’Type’ with the implicit importing of ’Type’ could encourage people to just apply both changes in one go.<br>
<span class="HOEnZb"><font color="#888888"><br>
Manuel<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> Am 12.02.2018 um 02:04 schrieb Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>>:<br>
><br>
> Hi,<br>
><br>
><br>
> Am 11. Februar 2018 01:43:03 EST schrieb Manuel M T Chakravarty <<a href="mailto:chak@justtesting.org">chak@justtesting.org</a>>:<br>
>> So, I think, we need a convenient and concise notation that doesn’t<br>
>> require extra imports.<br>
><br>
> we have precedence for that: (->) could just as well be a name exported from Data.Function and the Prelude, with all the usual rules around it (qualifications, exports). But it is not, and rather parses as it's own thing. So far, nobody seems to bother about this exception from the rule.<br>
><br>
> But doing this to `Type` is annoying because existing code out there already used `Type`, in particular GHC.<br>
><br>
> Maybe if we can find a uncommonly used, short, descriptive name then making that available without imports is viable? Do we have any good ideas?<br>
><br>
><br>
> Joachim<br>
> ______________________________<wbr>_________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@<wbr>haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br>
<br>
______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@<wbr>haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br>
</div></div></blockquote></div><br></div>