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