I have to say I'm a big -1 on the proposed syntax -- it's awfully confusing to have the import list mean something entirely different before the `as` compared to after the `as`. I proposed a different syntax on the ticket (https://ghc.haskell.org/trac/ghc/ticket/10478#comment:3), which I paste here for ease of access. --- I'm in favor of abbreviating the syntax in this common scenario, but I don't like your choice of syntax, I'm afraid. It would give {{{ import Data.Map (Map) as M -- (1) }}} a very different meaning from {{{ import Data.Map as M (Map) -- (2) }}} (1) imports all of `Data.Map`, qualified with the alias `M`, and imports the name `Map` unqualified. (2) imports only the name `Map` (unqualified) while also aliasing `Data.Map`. Having these two coexist seems like we're asking users to be confused. What about {{{ import Data.Map (Map) qualified as M * }}} ? The general schema, which replaces the current syntax. This schema does not permit some current syntax, but it would be easy to extend it to be backward-compatible. I've chosen not to for this presentation to avoid clutter. {{{ import_statement ::= 'import' module_name maybe_name_list import_specifiers module_name ::= ... maybe_name_list ::= name_list | <empty> name_list ::= '(' names ')' | '*' import_specifiers ::= <empty> | import_specifier import_specifiers import_specifier ::= 'hiding' name_list | qualified_spec name_list qualified_spec ::= 'qualified' | 'qualified' 'as' name }}} The top-level `maybe_name_list` would list all unqualified imports. If it is omitted, and there are no `qualified_spec`s, then all names would be imported unqualified. If it is omitted and there are one or more `qualified_spec`s, then no names would be imported unqualified. Each `import_specifier` either adds qualified names (perhaps under a module synonym) or removes names. Removing names with `hiding` removes those names from the `qualified_spec` (or top-level `maybe_name_list`) immediately preceding the `hiding`. The special `name_list` `*` (note that it is ''not'' in parentheses, to avoid ambiguity) means "all names". This schema allows one import statement to import a mix of qualified and unqualified names, and even allows using different module synonyms for different sets of qualified names. The legacy `import` syntax could desugar to this form, which seems strictly more expressive. For example: {{{ import qualified Foo --> import Foo qualified * import qualified Bar as B --> import Bar qualified as B * import Baz hiding (wurble) --> import Baz hiding (wurble) }}} Thoughts? Richard On Jun 3, 2015, at 1:31 PM, Adam Bergmark wrote:

+1, I thought of the exact same syntax at some point.

On Wed, Jun 3, 2015 at 7:18 PM, Michael Snoyman wrote: That's nifty. Just about every module in the project I'm working on now has two lines like the former (and the same for Set). I like the new syntax, +1.

On Wed, Jun 3, 2015 at 8:15 PM Anthony Cowley wrote: Hi Everyone,

I didn't think this would see any resistance as it doesn't break anything, but this is the internet, so, if you haven't already, take a look at this GHC feature request https://ghc.haskell.org/trac/ghc/ticket/10478

The idea is that rather than writing,

import Data.Map (Map) import qualified Data.Map as M

you could instead write,

import Data.Map (Map) as M

The Map identifier would imported unqualified, while M would be introduced as an alias for the qualified import of Data.Map.

Note that, currently, following a parenthesized group with the "as" keyword is a parse error. So allowing this syntax would not affect any currently working programs.

I've mentioned this proposal before and gotten good response, so I finally wrote it up last night after people on IRC responded positively to it. As well as IRC and trac, I put the link up on Twitter to get it in front of a large audience, and here's what we have after a bit over 12 hours (not counting the handful of supporters in IRC):

+20 -2

You can see the tweet at https://twitter.com/a_cowley/status/605909841148702720

I'll try to summarize the two negative votes: 1) This isn't that big a burden, and we should instead focus on controlled export of class instances; and 2) We should instead focus on exporting name spaces, and that the ordering of parentheses and the "as" keyword is too close to the existing "import Foo as F(foo)" syntax.

Since there are these negative votes, I think it best if as many people as possible at least see the proposal so the GHC developers can get a better sense for the overall response.

Anthony _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Thanks for providing the numbers -- it's always helpful to keep in mind how common an idiom is. I would like to point out that my proposal *is* meant to be fully backward-compatible. I just didn't put the backward-compatible bits in the grammar I laid out, because I thought they would obscure the point. The existing syntax would remain, entirely unchanged. Richard On Jun 3, 2015, at 3:01 PM, Anthony Cowley wrote:

On Wed, Jun 3, 2015 at 1:43 PM, Richard Eisenberg wrote:

...

I have to say I'm a big -1 on the proposed syntax -- it's awfully confusing to have the import list mean something entirely different before the `as` compared to after the `as`. I proposed a different syntax on the ticket (https://ghc.haskell.org/trac/ghc/ticket/10478#comment:3), which I paste here for ease of access.

Calling this "awfully confusing" is dramatically overstating things. A quick grep over all of the Stackage package set sources suggests that the "import Foo as F (foo)" syntax is used in less than 0.3% of all import statements. If the rule that the "explicit import list is always imported unqualified" really is too confusing (even though it is the current rule), you could guess wrong every time and only misunderstand three out of a thousand imports you encounter in the wild.

I think this is a tiny tail wagging an otherwise healthy dog. That we can get rid of the word "qualified" for a common case without breaking anything seems like a clear win to me. But I appreciate some people disagree, which is why I thought it was important to make the broad support visible rather than surprise anyone. If there is enough opposition (we're around 25-3 at the moment), we can let the sleeping dog lie.

As to the alternative proposal, I'm less positive on it as it seems unnecessarily verbose given the original option, and the fact that, as presented, it breaks existing code makes it a non-starter.

Anthony

...

--- I'm in favor of abbreviating the syntax in this common scenario, but I don't like your choice of syntax, I'm afraid. It would give

{{{ import Data.Map (Map) as M -- (1) }}}

a very different meaning from

{{{ import Data.Map as M (Map) -- (2) }}}

(1) imports all of `Data.Map`, qualified with the alias `M`, and imports the name `Map` unqualified. (2) imports only the name `Map` (unqualified) while also aliasing `Data.Map`. Having these two coexist seems like we're asking users to be confused.

What about

{{{ import Data.Map (Map) qualified as M * }}}

?

The general schema, which replaces the current syntax. This schema does not permit some current syntax, but it would be easy to extend it to be backward-compatible. I've chosen not to for this presentation to avoid clutter.

{{{ import_statement ::= 'import' module_name maybe_name_list import_specifiers module_name ::= ... maybe_name_list ::= name_list | <empty> name_list ::= '(' names ')' | '*' import_specifiers ::= <empty> | import_specifier import_specifiers import_specifier ::= 'hiding' name_list | qualified_spec name_list qualified_spec ::= 'qualified' | 'qualified' 'as' name }}}

The top-level `maybe_name_list` would list all unqualified imports. If it is omitted, and there are no `qualified_spec`s, then all names would be imported unqualified. If it is omitted and there are one or more `qualified_spec`s, then no names would be imported unqualified.

Each `import_specifier` either adds qualified names (perhaps under a module synonym) or removes names. Removing names with `hiding` removes those names from the `qualified_spec` (or top-level `maybe_name_list`) immediately preceding the `hiding`.

The special `name_list` `*` (note that it is ''not'' in parentheses, to avoid ambiguity) means "all names".

This schema allows one import statement to import a mix of qualified and unqualified names, and even allows using different module synonyms for different sets of qualified names. The legacy `import` syntax could desugar to this form, which seems strictly more expressive. For example:

{{{ import qualified Foo --> import Foo qualified * import qualified Bar as B --> import Bar qualified as B * import Baz hiding (wurble) --> import Baz hiding (wurble) }}}

Thoughts?

Richard

On Jun 3, 2015, at 1:31 PM, Adam Bergmark wrote:

+1, I thought of the exact same syntax at some point.

On Wed, Jun 3, 2015 at 7:18 PM, Michael Snoyman wrote:

...

That's nifty. Just about every module in the project I'm working on now has two lines like the former (and the same for Set). I like the new syntax, +1.

On Wed, Jun 3, 2015 at 8:15 PM Anthony Cowley wrote:

...

Hi Everyone,

I didn't think this would see any resistance as it doesn't break anything, but this is the internet, so, if you haven't already, take a look at this GHC feature request https://ghc.haskell.org/trac/ghc/ticket/10478

The idea is that rather than writing,

import Data.Map (Map) import qualified Data.Map as M

you could instead write,

import Data.Map (Map) as M

The Map identifier would imported unqualified, while M would be introduced as an alias for the qualified import of Data.Map.

Note that, currently, following a parenthesized group with the "as" keyword is a parse error. So allowing this syntax would not affect any currently working programs.

I've mentioned this proposal before and gotten good response, so I finally wrote it up last night after people on IRC responded positively to it. As well as IRC and trac, I put the link up on Twitter to get it in front of a large audience, and here's what we have after a bit over 12 hours (not counting the handful of supporters in IRC):

+20 -2

You can see the tweet at https://twitter.com/a_cowley/status/605909841148702720

I'll try to summarize the two negative votes: 1) This isn't that big a burden, and we should instead focus on controlled export of class instances; and 2) We should instead focus on exporting name spaces, and that the ordering of parentheses and the "as" keyword is too close to the existing "import Foo as F(foo)" syntax.

Since there are these negative votes, I think it best if as many people as possible at least see the proposal so the GHC developers can get a better sense for the overall response.

Anthony _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

amindfv@gmail.com writes:

I'd be +1 provided we can write e.g.:

import Data.Map (Map) as M (fromList)

And then we'd get only the Map type and M.fromList

Then wouldn't it also make sense to also: 1. eliminate the arguably confusing double-import through as-without-qualified: import FQMN as M .. (which imports the exportlist of FQMN twice) Does a lot of code use that? Is this a good practice? Do we want to encourage this kind of usage? 2. and take advantage of the reduced complexity by implying "qualified", wheneved "as" is present, by replacing: import qualified FQMN as M … with import FQMN as M … 3. effectively drop the "qualified" keyword from use (can be done lazily) It would break things, though. -- с уважениeм, Косырев Серёга

Anthony Cowley writes:

On Wed, Jun 3, 2015 at 2:45 PM, Kosyrev Serge <_deepfire@feelingofgreen.ru> wrote:

...

Then wouldn't it also make sense to also:

1. eliminate the arguably confusing double-import through as-without-qualified:

import FQMN as M .. (which imports the exportlist of FQMN twice)

Does a lot of code use that? Is this a good practice? Do we want to encourage this kind of usage?

2. and take advantage of the reduced complexity by implying "qualified", wheneved "as" is present, by replacing:

import qualified FQMN as M …

with

import FQMN as M …

3. effectively drop the "qualified" keyword from use (can be done lazily)

It would break things, though.

This (2) is what I would want to do, too, ideally. However, the breakage really makes it inviable.

I tried to quantify the use of the other syntax in another email. I grepped through the source of all the packages in the Stackage Nightly package set and found that less 0.3% of imports use that syntax. It's a small number, but it's not zero, so the breakage would be unacceptable.

One can look at it this way -- the breakage is a fixed, one-time cost, whereas the confusion has a running cost. So in the end, the real question is what is our planning horizon. -- respectfully, Косырев Серёга

Alexey Shmalko writes:

I like Richard's syntax more. The only note is that I'd like to omit asterisk when it's last in line. Then the only case when * should be stated is something semantically similar to

import Foo as F

(which I found silly anyway).

Here are more examples: import Foo qualified --> import qualified Foo import Foo qualified as F --> import qualified Foo as F import Foo (foo) qualified as F --> import Foo as F (foo) import Foo * qualified as F --> import Foo as F

This looks far more comprehensible to me as well, precisely because I feel like I can assign stable meaning to the words.

It doesn't seem to break backward compatibility for me (am I wrong?).

This syntax also fixes alignment of module names in import list. You don't need to align anything because all module names are right after "import".

-- respectfully, Косырев Серёга

On 06/04/2015 04:24 AM, Phil Ruffwind wrote:

...

One can look at it this way -- the breakage is a fixed, one-time cost, whereas the confusion has a running cost.

It's not necessarily that simple. Breaking old code can also breaks all the tutorials, articles, and documentation scattered all over the Internet. That cost could last a long time. AFAIK Haskell hasn't done anything so drastic as to change the existing syntax, except to _remove_ things that were already strongly discouraged like n+k. It will also introduce confusion of a different kind, as programmers will find it strange that their formerly correct code code having suddenly changed semantics.

Of course we should take such concerns seriously, but given the rarity of such usage it would seem to indicate that not many people are using the "problematic" syntax in practice... which could be an indication that a) haven't learned/copy&pasted it from a tutorial/book, and/or b) haven't found it useful even if they *did* learn/copy&paste from a tutorial/book. So there's that...

Personally I look forward to having to waste fewer keystrokes on the dreaded import list. Having to explicitly write 'qualified' in acrowley's syntax would be less desirable, though still an overall improvement from the current state of things.

My only worry here would be that the logical conclusion to this is you end up with a language which can only ever go towards a *local* optimimum. Regards,

El Jun 3, 2015, a las 14:32, Kosyrev Serge <_deepfire@feelingofgreen.ru> escribió:

Anthony Cowley writes:

...

The idea is that rather than writing,

import Data.Map (Map)

The head parses this in following steps:

1. import FQMN ≡ we're going to directly import from FQMN 2. import FQMN (…) ≡ ok, the scope is restricted by the parens

...

import qualified Data.Map as M

1. import qualified FQMN ≡ we're going to import qualified names from FQMN 2. import qualified FQMN as X ≡ ok, and the prefix is going to be X

...

you could instead write,

import Data.Map (Map) as M

…and you see how this is broken:

1. import FQMN ≡ we're going to directly import from FQMN (not!) <category error red light flashing>

In other words, if you intend to keep all three cases, you're going to have an ugly inconsistency. Sure, it's small and contained, but still it's an inconsistency that's going to have a non-zero cost in the long run.

I think the existing syntax that this most-closely corresponds to is "import Data.Map as Map" (note the "as" without "qualified") Tom

-- respectfully, Косырев Серёга _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Sorry, Yuras! I wanted to make sure the dissenting voices were heard. The current vote count is ~28-4. It seems like we're on the precipice of a fatal bike shedding, so I'm counting all the votes for keeping "quantified" as negative (as that's what Richard stated for himself), and trying to be conservative counting the +1's. I hope that's enough of a majority. To put things in perspective again, the Stackage package set has 10x as many qualified imports as unqualified imports that use the "as" keyword. The point here is to slightly smooth things out for the 10-1 majority case. While I do appreciate that these two lines can potentially be mistaken for each other, import Map as M (fromList) import Map (fromList) as M I think the movement of the explicit import group is quite visibly striking, and, as previously noted, you could misread the former every time and only misunderstand 0.3% of import statements you read. Preserving the "qualified" keyword is better than no change at all, but is, I think, gratuitous preservation of a minor wart. Given the support for the original proposal, I'd hate to snatch defeat from the jaws of victory here. Anthony On Wed, Jun 3, 2015 at 3:53 PM, Yuras Shumovich wrote:

On Wed, 2015-06-03 at 13:15 -0400, Anthony Cowley wrote:

...

I'll try to summarize the two negative votes: 1) This isn't that big a burden, and we should instead focus on controlled export of class instances; and 2) We should instead focus on exporting name spaces, and that the ordering of parentheses and the "as" keyword is too close to the existing "import Foo as F(foo)" syntax.

Hello,

You counted me as -1, but I'm not against the proposal. I just expressed my concerns in the my comment on Trac.

Actually I'd prefer "import Foo as F(foo)" to import "foo" qualified. Too often I write such import by mistake (missing "qualified"), and get compilation error later. Unfortunately it will break code.

Thanks, Yuras.

...

Since there are these negative votes, I think it best if as many people as possible at least see the proposal so the GHC developers can get a better sense for the overall response.

Anthony _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On 2015-06-04 at 22:23:26 +0200, Bardur Arantsson wrote: [...]

...

Preserving the "qualified" keyword is better than no change at all, but is, I think, gratuitous preservation of a minor wart. Given the support for the original proposal, I'd hate to snatch defeat from the jaws of victory here.

(I thought I'd posted this earlier, but I guess not from my news reader's idea of concensus reality as decided by GMANE.org.)

+1 to whatever syntax is decided upon as long as it doesn't break too much existing code (i.e. published/Hackage code). Down with bikeshedding for its own sake! :) [..]

Clearly, this new syntax won't be available by default when only {-# LANGUAGE Haskell2010 #-} is active. So I assume this is going to be a new language extension enabled by a new to-be-named LANGUAGE-pragma (and if it stands the test of time, be enabled by default in, say {-# LANGUAGE Haskell2020 #-})? If so, why is it a concern if there's code breakage, as this new syntax will be an explicit opt-in? Cheers, hvr

On 06/04/2015 11:05 PM, Alexey Shmalko wrote:

If I understand correctly, the initial proposal was to enable the new syntax by default and it mustn't break any code (full backward-compatible).

Yes, indeed. ... and personally, I *don't* necessarily think that an -X<whatever> flag is the solution. I think something along the lines of "gofix" (see https://golang.org/cmd/fix/) could actually do the second part of this transition, if we want to drop the "qualified" bit and the consequences are unambiguous in 20x5. Regards,

On Jun 4, 2015, at 5:22 PM, Herbert Valerio Riedel wrote:

...

On 2015-06-04 at 23:05:42 +0200, Alexey Shmalko wrote: If I understand correctly, the initial proposal was to enable the new syntax by default and it mustn't break any code (full backward-compatible).

That would be a departure from how language extensions were handled in GHC in the past afaik, and if there's no language pragma to toggle this new syntax, Cabal has no way to know that a new language syntax is required and that thereby needs exclude (not implemented yet) the affected package versions from the install-plan configuration space.

I can't parse your last sentence. The proposed syntax is currently a parse error, so a package that used it could depend on a GHC new enough to support it (eg with a base version constraint). No older packages would cause any errors whatsoever. Anthony

On Jun 4, 2015, at 5:41 PM, Brandon Allbery wrote:

...

On Thu, Jun 4, 2015 at 5:36 PM, Anthony Cowley wrote:

...

On Jun 4, 2015, at 5:22 PM, Herbert Valerio Riedel wrote: new syntax, Cabal has no way to know that a new language syntax is required and that thereby needs exclude (not implemented yet) the affected package versions from the install-plan configuration space.

I can't parse your last sentence. The proposed syntax is currently a parse error, so a package that used it could depend on a GHC new enough to support it (eg with a base version constraint). No older packages would cause any errors whatsoever.

Your unstated assumption is that everyone always has the latest ghc.

How do people who are on, say, Debian or CentOS, deal with a language change that is not compatible with their compiler? How does cabal avoid pulling in package versions using the new incompatible syntax?

I guess I'm just not familiar with how Debian and CentOS work, because this doesn't seem like a change to me, but you and hvr have much more experience than I do. How do those systems deal with a package that has a lower bound on base? If I require base >= 7.9, does that get thrown out to work with GHC 7.4? How does that work? Anthony

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Thu, Jun 4, 2015 at 6:25 PM, Brandon Allbery wrote:

On Thu, Jun 4, 2015 at 6:03 PM, Anthony Cowley wrote:

...

If I require base >= 7.9, does that get thrown out to work with GHC 7.4? How does that work?

So... to declare that I am using a new language construct, I place a bound on base.

I'm sure this makes sense to someone, somewhere....

Let's please step back, 1) I said we'd need a LANGUAGE pragma in response to hvr 2) A question was asked about enabling it by default 3) hvr said this would need a way of letting cabal know not to build it 4) I said it could be signaled with a bound on base 5) You said this assumed everyone had the latest GHC Your response was a non sequitur. As it happens, if you have code that hits a bug in GHC, then a pretty effective way of ensuring that cabal-install doesn't try to build it with an older GHC is to put a lower bound on base. I'm sorry if that is offensive. Anthony

On 06/04/2015 11:41 PM, Brandon Allbery wrote:

On Thu, Jun 4, 2015 at 5:36 PM, Anthony Cowley wrote:

...

Meta-point: Can we please stop cc'ing everyone on everything? It's getting pretty annoying and "reply-to-list" should be available in every decent e-mail client. Sure, if someone explicitly states that they aren't on the list, please do CC them, but that *not* the common case, so please act accordingly. (I'm getting a lot of "duplicates" because I'm already "silently" subscribed for a variety of mailing lists, but I use gmane.org to maintain sanity.) Regards,

On Fri, Jun 05, 2015 at 09:07:14AM +0100, Tom Ellis wrote:

I am strongly in support of this. Receiving duplicates is unnecessary and rather frustrating.

Hello Tom, as a mutt user, you are probably interested in: # mark duplicates for deletion folder-hook yourfolder 'push "<delete-pattern>~=<enter>"'

On 2015-06-04 at 23:36:01 +0200, Anthony Cowley wrote:

...

On Jun 4, 2015, at 5:22 PM, Herbert Valerio Riedel wrote:

...

On 2015-06-04 at 23:05:42 +0200, Alexey Shmalko wrote: If I understand correctly, the initial proposal was to enable the new syntax by default and it mustn't break any code (full backward-compatible).

That would be a departure from how language extensions were handled in GHC in the past afaik, and if there's no language pragma to toggle this new syntax, Cabal has no way to know that a new language syntax is required and that thereby needs exclude (not implemented yet) the affected package versions from the install-plan configuration space.

I can't parse your last sentence.

I'll rephrase: Extending the syntax GHC accepts beyond H2010 w/o a language flag (but if I understood you correctly, you stated that there's gonna be an associated language pragma) is not desirable, since you wouldn't be able communicate that requirement to Cabal via the other-extensions/default-extensions mechanism (albeit that information is currently not used early enough to affect the install-plan solver, see also [1]) While I'm mildly against having this new syntax enabled in GHC's default-mode (i.e. when neither -XHaskell2010 nor -XHaskell98 is set), I'm strongly against enabling it implicitly via -XHaskell2010, as when you request -XHaskell2010 you want GHC ideally to tell you when you're using syntax beyond H2010. One risk I see with enabling this new and yet unproven syntax extension by default right away is that it blocks the way for any alternative (or just conflicting) import-syntax feature we may come up with in the future, as we would have already locked on to this new syntax by making it available out of the box, thereby increasing the cost of disabling it again. Another issue I see is with editors, which benefit a lot from having syntax advertised via language pragmas, as that can be used to control syntax highlighting, but if the text editor doesn't know whether that new syntax is allowed or not because it's not signalled via a {-# LANGUAGE #-} pragma, the syntax highlighter can't do its job of pointing out invalid syntax reliably. Other tooling may benefit from such an explicit pragma too (c.f. haskell-src-exts).

The proposed syntax is currently a parse error, so a package that used it could depend on a GHC new enough to support it (eg with a base version constraint). No older packages would cause any errors whatsoever.

*Currently*, you can indirectly depend on a GHC version (and thus available language extensions) by constraining on its associated `base` version (/if/ you depend on `base` directly), but that's more of workaround for lacking better means (which are not out of reach, see [1]), since by depending on the `base` library for /language/ features you assume that GHC and `base` will always have this direct correlation, but that's not guaranteed to remain so (and it would certainly solve quite a few GHC upgrade pains, if we could have a newer GHC install an older base major version.... but that's another story). And actually, you can also depend directly on a GHC version by using a cabal conditional construct of the kind if impl(ghc < 7.10) build-depends: base<0 However, it's semantically cleaner (and easier than to remember which GHC version introduced a given syntax extension) to state the syntax requirements in terms of other-extensions/default-extensions lists, rather than requesting a specific compiler (version), even if GHC is supposedly the only one left standing... Cheers, hvr [1]: https://github.com/haskell/cabal/issues/2644

On 2015-06-07 at 02:18:47 +0200, Anthony Cowley wrote:

On Sat, Jun 6, 2015 at 6:35 PM, Herbert Valerio Riedel wrote:

...

On 2015-06-04 at 23:36:01 +0200, Anthony Cowley wrote:

...

...

On Jun 4, 2015, at 5:22 PM, Herbert Valerio Riedel wrote:

...

On 2015-06-04 at 23:05:42 +0200, Alexey Shmalko wrote: If I understand correctly, the initial proposal was to enable the new syntax by default and it mustn't break any code (full backward-compatible).

That would be a departure from how language extensions were handled in GHC in the past afaik, and if there's no language pragma to toggle this new syntax, Cabal has no way to know that a new language syntax is required and that thereby needs exclude (not implemented yet) the affected package versions from the install-plan configuration space.

...

I can't parse your last sentence.

I'll rephrase: Extending the syntax GHC accepts beyond H2010 w/o a language flag (but if I understood you correctly, you stated that there's gonna be an associated language pragma) is not desirable, since you wouldn't be able communicate that requirement to Cabal via the other-extensions/default-extensions mechanism (albeit that information is currently not used early enough to affect the install-plan solver, see also [1])

While I'm mildly against having this new syntax enabled in GHC's default-mode (i.e. when neither -XHaskell2010 nor -XHaskell98 is set), I'm strongly against enabling it implicitly via -XHaskell2010, as when you request -XHaskell2010 you want GHC ideally to tell you when you're using syntax beyond H2010.

Just to be clear, that ideal is not reality, is it? I can pass ghc -XHaskell2010 and use syntactic extensions in my programs today (e.g. LambdaCase).

*Only* if you also explicitly enable them, e.g. if you have a module which only contains {-# LANGUAGE Haskell2010 #-} and let's assume for simplicity there are no additional -X* flags passed via the CLI to GHC, then you can't use syntactic extensions like LambdaCase; i.e. the following module {-# LANGUAGE Haskell2010 #-} module M1 where f :: () -> () f = \case () -> () when compiled with `ghc -Wall -c M1.hs` is rightfully rejected with: M1.hs:6:5: parse error: naked lambda expression '' However, if an additional `{-# LANGUAGE LambdaCase #-} is added, GHC compiles it w/o any complaint.

I can additionally pass ghc -Wall and not hear about it. So I think what you're writing here is a proposal for a new GHC feature that restricts available syntactic extensions in the presence of a language standard flag?

Maybe I was unclear, but I didn't mean that -XHaskell2010 should enable additional warnings for additionally *requested* language extensions. If I write {-# LANGUAGE Haskell2010 #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE RecordWildcards #-} into a module, I explicitly state that the code requires Haskell2010 syntax *with* additionally those 3 syntax extensions enabled (which btw are syntax extensions that afaik don't break any legal Haskell2010, and hence could be enabled by default -- but GHC doesn't enable them by default either!). There's obviously no point in warning if I really make use of those additional language extension, as that's what the pragma-mechanism is for in the first place.

The interplay between things like Haskell2010 and other language extensions isn't great. It would be nice to have a better story, but I think that really is a separate issue wherein you want Haskell2010 to act like a meta-pragma to ensure that the file really is Haskell2010 compatible. I am not volunteering to make that happen :)

To be clear, I only meant to say that the presence of -XHaskell2010 (or equivalently, {-# LANGUAGE Haskell2010 #-}) *without* any additional -X flags or LANGUAGE-pragmas is supposed to enable only the minimum required syntax extensions to provide the Haskell2010 syntax, as any syntax beyond Haskell2010 ought to be provided via -X/LANGUAGE pragmas. See also https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs-and-inf... which states that | By default, GHC mainly aims to behave (mostly) like a Haskell 2010 | compiler, although you can tell it to try to behave like a particular | version of the language with the -XHaskell98 and -XHaskell2010 flags. and fwiw GHC's default-mode is not the same as -XHaskell2010

On 06/04/2015 02:14 PM, Anthony Cowley wrote:

Sorry, Yuras! I wanted to make sure the dissenting voices were heard.

The current vote count is ~28-4. It seems like we're on the precipice of a fatal bike shedding, so I'm counting all the votes for keeping "quantified" as negative (as that's what Richard stated for himself), and trying to be conservative counting the +1's. I hope that's enough of a majority.

To put things in perspective again, the Stackage package set has 10x as many qualified imports as unqualified imports that use the "as" keyword. The point here is to slightly smooth things out for the 10-1 majority case.

While I do appreciate that these two lines can potentially be mistaken for each other,

import Map as M (fromList) import Map (fromList) as M

I think the movement of the explicit import group is quite visibly striking, and, as previously noted, you could misread the former every time and only misunderstand 0.3% of import statements you read.

Here's what I don't like about this, although I'm not necessarily giving it the thumbs down. Currently, the parentheses come at the end of the line, like import Foo (bar) import qualified Foo as F (bar) So, when your import list gets huge, it's easy to break: import Foo ( bar1, bar2, ,,,, barN ) import qualified Foo as F ( baz1, baz2, ,,,, bazN ) With the new syntax, you have two towers of names: import Foo ( bar1, bar2, ..., barN ) as F ( -- This line is ugly and important and buried baz1, baz2, ... bazN )

I agree with everything Richard says here. Not only is the proposed syntax bad, but I don't see any good motivation for the general idea of making minor tweaks to the imports section. I don't find it at all annoying to use a couple of lines to be completely explicit about which names are always qualified, which are optionally qualified, and the qualifier to use; and indeed I am a heavy user of the 'as' form, both with and without 'qualified'. 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. Regards, Malcolm

On 5 Jun 2015, at 05:23, "Richard A. O'Keefe" wrote:

...

On 4/06/2015, at 5:15 am, Anthony Cowley wrote: The idea is that rather than writing,

import Data.Map (Map) import qualified Data.Map as M

you could instead write,

import Data.Map (Map) as M

This puts the list (Map) in the wrong place. You know how in English, "heavy" parts of a sentence go at the end? The "heavy" part of an import declaration is the impspec.

...

The Map identifier would imported unqualified, while M would be introduced as an alias for the qualified import of Data.Map.

I find that confusing. I expected it to mean that only Data.Map.Map would be available and that it would have to be referred to as M.Map. The core problem is that this is a bit too close to English syntax, where the placement of "as M" after (Map) suggests that it refers to (Map), rather than to Data.Map.

The new syntax does not let us do anything we cannot do now.

It is also asking too much to ask people to distinguish between

import Full as Local (thingy) -- current import Full (thingy) as Local -- proposed

Whatever its faults, the current scheme at least makes it obvious that 'as Local' refers to 'Full', not '(thingy)'.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

2015-06-05 7:52 GMT+02:00 Malcolm Wallace :

[...] 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.

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 wrote:

...

2015-06-05 7:52 GMT+02:00 Malcolm Wallace :

...

[...] 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

On Fri, Jun 5, 2015 at 5:55 PM, Sven Panne wrote: 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

On Sat, Jun 6, 2015 at 3:07 PM, Sven Panne wrote:

2015-06-06 0:09 GMT+02:00 Anthony Cowley :

...

This was stated unambiguously [...]

Looking back through the thread, this might be a bit of an exaggeration... ;-)

...

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%. [...]

OK, but even if we reach consensus that the change is worthwhile (for me it's not), it's still extremely important to make this a language extension which must be explicitly declared. Otherwise there *will* be heavy breakage through transitive dependencies, cabal not being able to find an install plan, etc. As was already noted, not everybody is using the latest and greatest GHC (often for a good reason).

So in a nutshell: -0.5 from me if it's a language extension, -1000 if it's on by default.

Is there a reason you and others are singling out this extension for causing breakage? No language extension is taken into account by cabal unless you put a lower bound on base, which offends some people. If you use any extension, you are causing the exact breakage you are so concerned with! This is how cabal works and has worked: the use of a language extension does not solve this. So what are you basing all these confidently negative predictions on? If you don't like the syntax, vote -1 (current status is roughly 31-5), but don't invent technical-sounding objections. Anthony

On Sat, Jun 6, 2015 at 4:02 PM, Brandon Allbery wrote:

On Sat, Jun 6, 2015 at 3:56 PM, Anthony Cowley wrote:

...

This is how cabal works and has worked: the use of a language extension does not solve this

Yes, blame cabal for something that you refuse to give it any clue about. That cabal cannot read your mind is a terrible bug!

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

I'll repeat myself: 1) The proposed extension will live behind a pragma 2) cabal does not take language extensions into account when computing a build plan The only way to give cabal a clue about a used extension is to put a lower bound on base, but you specifically rejected that as ridiculous. Anthony

On Sat, Jun 6, 2015 at 6:21 PM, Sven Panne wrote:

2015-06-06 22:09 GMT+02:00 Anthony Cowley :

...

I'll repeat myself:

... and so do I:

...

1) The proposed extension will live behind a pragma

That's exactly what I'm asking for: A new {-# LANGUAGE FunkyImports #-} pragma (name to be decided ;-), which must be mentioned in a cabal file's "extension:" field (https://www.haskell.org/cabal/users-guide/developing-packages.html#creating-...). Failing to mention a language extension is just as wrong as declaring wrong bounds.

This was clarified in several mails in the thread before yours starting with a response to Herbert.

...

2) cabal does not take language extensions into account when computing a build plan

If that's actually the case (can some Cabal devs clarify this?), than it's a Cabal bug, otherwise the "extension:" field would be meaningless and build plans would be fragile. Anyway, this has nothing to do per se with the proposal.

That is the state of affairs. After claiming in this thread that an extension is the only way to help cabal, Herbert himself went on github to open an issue requesting the feature https://github.com/haskell/cabal/issues/2644. I'm not going to try to explain or justify his actions, but the point is that your predictions of how compatibility is sure to be broken have been based on not reading the proposal followed by a misunderstanding of how our tools have worked for years. Cabal should be improved, but if the dozens of extensions we've seen thus far haven't caused widespread havoc, then it seems unlikely that this one would.

...

The only way to give cabal a clue about a used extension is to put a lower bound on base, but you specifically rejected that as ridiculous.

That would in fact be ridiculous, just as saying "every release with a prime major version number implies the new language extension.". One could perfectly implement any base version without implementing the proposal.

And yet anybody who has seriously made an effort to preserve backwards compatibility has had to do this effectively forever. Again, I'm happy to mark you down as -1 on the proposal. Anthony

On 7 June 2015 at 09:20, Ivan Lazar Miljenovic wrote:

On 7 June 2015 at 08:21, Sven Panne wrote:

...

That's exactly what I'm asking for: A new {-# LANGUAGE FunkyImports #-} pragma (name to be decided ;-), which must be mentioned in a cabal file's "extension:" field (https://www.haskell.org/cabal/users-guide/developing-packages.html#creating-...). Failing to mention a language extension is just as wrong as declaring wrong bounds.

I was under the impression that the "extension:" fields were only used for extensions that were used by every module in the package. From that link:

Extensions used only by one module may be specified by placing a LANGUAGE pragma in the source file affected,

Oh, and just to chime in on the voting, I'm -1 (I don't think the current syntax is ideal, but I'm not a fan of the proposal. Does this come under the power of 1 by Wadler's Law? ;-) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

Maybe a slightly changed syntax like this could be less confusing import Data.Map (Map) andAs M (...) or import Data.Map (Map) and as M (...) It is clear (IMHO) what is coming from where, and both lists are at the end of their part, so can be written nicely in several rows, if needed. import Data.Map (Map) andAs M (lengthy, list) Parser can also easily distinguish between the current and the new syntax so they can coexist, so no backward compatibility problem. br, vlatko -------- Original Message -------- Subject: Re: [Haskell-cafe] Proposal: Shorter Import Syntax From: Malcolm Wallace To: haskell-cafe Date: 05/06/15 07:52

I agree with everything Richard says here. Not only is the proposed syntax bad, but I don't see any good motivation for the general idea of making minor tweaks to the imports section. I don't find it at all annoying to use a couple of lines to be completely explicit about which names are always qualified, which are optionally qualified, and the qualifier to use; and indeed I am a heavy user of the 'as' form, both with and without 'qualified'.

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.

Regards, Malcolm

...

On 5 Jun 2015, at 05:23, "Richard A. O'Keefe" wrote:

...

On 4/06/2015, at 5:15 am, Anthony Cowley wrote: The idea is that rather than writing,

import Data.Map (Map) import qualified Data.Map as M

you could instead write,

import Data.Map (Map) as M

This puts the list (Map) in the wrong place. You know how in English, "heavy" parts of a sentence go at the end? The "heavy" part of an import declaration is the impspec.

...

The Map identifier would imported unqualified, while M would be introduced as an alias for the qualified import of Data.Map.

I find that confusing. I expected it to mean that only Data.Map.Map would be available and that it would have to be referred to as M.Map. The core problem is that this is a bit too close to English syntax, where the placement of "as M" after (Map) suggests that it refers to (Map), rather than to Data.Map.

The new syntax does not let us do anything we cannot do now.

It is also asking too much to ask people to distinguish between

import Full as Local (thingy) -- current import Full (thingy) as Local -- proposed

Whatever its faults, the current scheme at least makes it obvious that 'as Local' refers to 'Full', not '(thingy)'.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Alexander Kjeldaas writes:

On Sat, Jun 6, 2015 at 10:26 AM, Vlatko Basic wrote: Maybe a slightly changed syntax like this could be less confusing

import Data.Map (Map) andAs M (...)

or

import Data.Map (Map) and as M (...)

It is clear (IMHO) what is coming from where, and both lists are at the end of their part, so can be written nicely in several rows, if needed.

import Data.Map (Map) andAs M (lengthy, list)

I much prefer a syntax with a bit more words, like this one. The original proposal is simply impossible to understand without reading a manual. It has at least two equally valid interpretations.

Adding one or two words like in this examples makes it possible, without reading a manual, to distinguish between possible interpretations. I think that must be a minimal requirement for such a syntax extension. Nobody needs to hire a language lawyer to understand a python import statement. That shouldn't be needed for Haskell either.

In the seemingly prevalent spirit of vote-counting, an empathic +1. -- respectfully, Косырев Серёга

On Sat, Jun 6, 2015 at 8:25 PM, Alexander Kjeldaas wrote:

On Sat, Jun 6, 2015 at 10:26 AM, Vlatko Basic wrote:

...

Maybe a slightly changed syntax like this could be less confusing

import Data.Map (Map) andAs M (...)

or

import Data.Map (Map) and as M (...)

It is clear (IMHO) what is coming from where, and both lists are at the end of their part, so can be written nicely in several rows, if needed.

import Data.Map (Map) andAs M (lengthy, list)

Parser can also easily distinguish between the current and the new syntax so they can coexist, so no backward compatibility problem.

I much prefer a syntax with a bit more words, like this one. The original proposal is simply impossible to understand without reading a manual. It has at least two equally valid interpretations.

Adding one or two words like in this examples makes it possible, without reading a manual, to distinguish between possible interpretations. I think that must be a minimal requirement for such a syntax extension. Nobody needs to hire a language lawyer to understand a python import statement. That shouldn't be needed for Haskell either.

Alexander

Thanks for the feedback, Vlatko, Alexander, and Kosyrev! I would like the syntax to avoid being overly hostile to newcomers, so some tweaks are certainly possible. So that I understand, you believe that a newcomer could read import Data.Map (Map) andAs M (lengthy) and infer which names are qualified and which aren't without consulting a manual, whereas without the "and" it would be "impossible to understand"? I confess I find that hard to believe, but I'll bear it in mind in case this option picks up wider support. There are already three of you on board, so it's off to a good start. Anthony

-------- Original Message -------- Subject: Re: [Haskell-cafe] Proposal: Shorter Import Syntax From: Anthony Cowley To: haskell-cafe Date: 07/06/15 03:29

On Sat, Jun 6, 2015 at 8:25 PM, Alexander Kjeldaas wrote:

...

On Sat, Jun 6, 2015 at 10:26 AM, Vlatko Basic wrote:

...

Maybe a slightly changed syntax like this could be less confusing

import Data.Map (Map) andAs M (...)

or

import Data.Map (Map) and as M (...)

It is clear (IMHO) what is coming from where, and both lists are at the end of their part, so can be written nicely in several rows, if needed.

import Data.Map (Map) andAs M (lengthy, list)

Parser can also easily distinguish between the current and the new syntax so they can coexist, so no backward compatibility problem.

I much prefer a syntax with a bit more words, like this one. The original proposal is simply impossible to understand without reading a manual. It has at least two equally valid interpretations.

Adding one or two words like in this examples makes it possible, without reading a manual, to distinguish between possible interpretations. I think that must be a minimal requirement for such a syntax extension. Nobody needs to hire a language lawyer to understand a python import statement. That shouldn't be needed for Haskell either.

Alexander

Thanks for the feedback, Vlatko, Alexander, and Kosyrev! I would like the syntax to avoid being overly hostile to newcomers, so some tweaks are certainly possible.

So that I understand, you believe that a newcomer could read

import Data.Map (Map) andAs M (lengthy)

and infer which names are qualified and which aren't without consulting a manual, whereas without the "and" it would be "impossible to understand"? I confess I find that hard to believe, but I'll bear it in mind in case this option picks up wider support. There are already three of you on board, so it's off to a good start.

Anthony

Well, when combining two sentences in natural language, you'd use a "comma" or the word "and" to distinguish between the two. Since we can't use comma here (can we?), the word "and" unambiguously shows that "as" does not relate to the previous "Data.Map (Map)", but is a beginning of the "new", qualified import. I think that is quite clear in this syntax. So to answer your question, I think yes, this would be clear to anyone, not only newcommers, that those are actually two combined imports, unqualified and qualified, without "consulting the manual". :-) Some other syntax/wording on the same track would be fine as well. br, vlatko

On Mon, Jun 8, 2015 at 3:23 AM, Sven Panne wrote:

Can we please have a page on https://wiki.haskell.org/ describing the proposal (including its detailed semantics), the various counter-proposals (2? 3? I lost track to be honest), the various concerns/issues/..., pros/cons etc. ? Email threads are very bad for longer-running discussions, and even the trac ticket has already degenerated a bit into an email thread. I think by now it's very clear that more detailed discussion is needed, just counting some +1 and -1 doesn't lead us anywhere. (Language design by voting is often a terrible idea, BTW, this has been demonstrated by history many times...)

The original email I sent was not a design by committee, but a PSA because when I started implementing this, I discovered that the parts of GHC dealing with imports are in rather poor shape. The work needed to shore that up touches half a dozen or so files, and I did not want to finish the work to have the patch languish. Enough popular support might have opened that door. The PSA was greeted by authors writing strongly worded rebuttals substantially longer than the four sentence proposal they obviously did not read. It received disdainful mockery based on a proprietary code base owned by a company which itself is in the process of adding new syntax that does not let us do anything we cannot do now. We were told about how cabal works as a prelude to a quiet feature request to actually make cabal work the way it was stated to work. I simply do not have the desire to navigate that kind of cognitive dissonance for a nights and weekends project, so I'm withdrawing the proposal. If someone else wishes to continue via Wiki or otherwise, that would be great. Anthony