<div dir="ltr">I'm going to eat some humble pie and retract my earlier -1 for a +1.<div><br></div><div>My original reasoning was that this looked particularly confusing and incoherent compared to the other import types we already have.</div><div>I still think this is true, but given that the current import syntax can be cumbersome, I believe this makes sense as a first step towards nicer imports in the long term future.<br><br></div><div>My mistake was seeing the short term negatives, but not seeing the long term positives.<br><br><div class="gmail_quote"><div dir="ltr">On Sat, 6 Jun 2015 at 08:10 Anthony Cowley <<a href="mailto:acowley@seas.upenn.edu">acowley@seas.upenn.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jun 5, 2015 at 5:55 PM, Sven Panne <<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>> wrote:<br>
> 2015-06-05 7:52 GMT+02:00 Malcolm Wallace <<a href="mailto:malcolm.wallace@me.com" target="_blank">malcolm.wallace@me.com</a>>:<br>
>><br>
>> [...] I think there is a burden on the proposer to demonstrate a decent<br>
>> power-to-weight ratio for the change, and saving a few characters at the<br>
>> expense of introducing considerable confusion just does not seem right to<br>
>> me.  "The new syntax does not let us do anything we cannot do now."  On the<br>
>> other hand, I could imagine a different import system altogether being<br>
>> attractive, perhaps a higher-order one like ML modules, although someone<br>
>> would have to flesh out the details.<br>
><br>
><br>
> Just another +1 to everything Malcolm wrote: IMHO the proposal is just<br>
> bikeshedding and doesn't really buy us much. Saving a few keystrokes is not<br>
> a good argument when it comes to language design, see e.g. Perl or the<br>
> latest additions to JavaScript. The current syntax might be a bit verbose,<br>
> but it's easily comprehensible, and the proposal is a bit confusing. I would<br>
> really welcome some more powerful module system, e.g. in the spirit of<br>
> ML/OCaml, but not some ad hoc changes to the current one.<br>
><br>
> Regarding the grep on Stackage: Here transitive dependencies should be taken<br>
> into account, so I guess the overall breakage would be much, much higher. A<br>
> per-module/package grep is basically meaningless.<br>
><br>
> Finally: Enabling anything by default what might break something is a total<br>
> no-go, *unless* everybody agrees that the current state of affairs is broken<br>
> and the new state is much better. Both doesn't hold here. Enabling some<br>
> things behind a flag/pragma is OK, time will then tell if the idea is good<br>
> or not.<br>
><br>
> Just my 2c,<br>
>    S.<br>
<br>
<br>
This was stated unambiguously in the proposal and several times since<br>
then, but, just to clarify: *there is no possible breakage from this<br>
change*. In other words, the percentage of Haskell programs that will<br>
break will not be "much, much higher." It will be 0%.<br>
<br>
Again: nothing whatsoever *can* break. The proposed syntax is<br>
currently a parse error. Please let me know how the proposal or the<br>
thread is confusing on this issue so I can clarify it and prevent<br>
people from doom and gloom prognostications.<br>
<br>
Anthony<br>
<br>
P.S. Nothing will break.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div></div></div>