[Haskell-cafe] Proposal: Shorter Import Syntax

Elliot Cameron elliot.cameron at covenanteyes.com
Sat Jun 6 03:22:54 UTC 2015


Haskell already loses people for silly things like its lack of curly braces and semicolons (if only they knew the truth). And it wins people for marginally silly things like how many parentheses you typically see. So, while this change may be silly in many ways, programmers are a picky bunch and we cannot underestimate the implications of silly annoyances like needing two lines to import “Text” and “T.pack”. +1 from me.

From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Sven Panne
Sent: Friday, June 5, 2015 5:55 PM
To: haskell-cafe
Subject: Re: [Haskell-cafe] Proposal: Shorter Import Syntax

2015-06-05 7:52 GMT+02:00 Malcolm Wallace <malcolm.wallace at me.com<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150606/b69f31dc/attachment.html>


More information about the Haskell-Cafe mailing list