[Haskell-cafe] Proposal: Shorter Import Syntax

[Amos Robinson]

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 Sat, 6 Jun 2015 at 08:10 Anthony Cowley <acowley at seas.upenn.edu> wrote:

> On Fri, Jun 5, 2015 at 5:55 PM, Sven Panne <svenpanne at gmail.com> wrote:
> > 2015-06-05 7:52 GMT+02:00 Malcolm Wallace <malcolm.wallace at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150606/9c549cc6/attachment.html>