Agreed, this sounds sensible. Can anyone think of any unintended consequences? -Jose On Tue, May 16, 2017, at 09:50 AM, Iavor Diatchki wrote:

That seems fairly reasonable to me.

-Iavor

On Tue, May 16, 2017 at 7:18 AM, Joachim Breitner wrote:>> Hi,

...

a very small proposal to be considered for Haskell':

Currently, the report states

An abbreviated form of module, consisting only of the module body,>> is permitted. If this is used, the header is assumed to be ‘module>> Main(main) where’.

I propose to change that to

An abbreviated form of module, consisting only of the module body,>> is permitted. If this is used, the header is assumed to be ‘module>> Main where’.

The rationale is that a main-less main module is still useful, e.g.>> when you are working a lot in GHCi, and offload a few extensions to a>> separate file. Currently, tools like hdevtools will complain about a>> missing main function when editing such a file.

It would also work better with GHC’s -main-is flag, and avoid problems>> like the one described in https://ghc.haskell.org/trac/ghc/ticket/13704>>

I don’t see any downsides. When compiling to a binary, implementations>> are still able to detect that a Main module is not imported by any other module and only the main function is used, and optimize as if>> only main were exported.

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org>> _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

you're inside the module, so you have access to all top-level bindings, not just to the export list. the issue with the implicit `module Main(main) where` is that it errors if main is not defined, even though that's a perfectly harmless situation. (i hope i got the question right?) On Tue, May 16, 2017 at 05:53:17PM +0000, Adam Bergmark wrote:

Date: Tue, 16 May 2017 17:53:17 +0000 From: Adam Bergmark To: José Manuel Calderón Trilla , haskell-prime@haskell.org Subject: Re: Default module header `module Main where`

GHCIs current behavior seems inconsistent with this, why is foo accessible and why don't I get an unused warning like i do if i have an explicit `module Main (main) where`?

``` $ cat Main.hs main :: IO () main = pure ()

foo :: Int foo = 1

$ ghci Main.hs -Wall GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/adam.bergmark/.ghci [1 of 1] Compiling Main ( Main.hs, interpreted ) Ok, modules loaded: Main.

λ foo 1 ```

On Tue, 16 May 2017 at 19:00 José Manuel Calderón Trilla wrote:

...

Agreed, this sounds sensible.

Can anyone think of any unintended consequences?

-Jose

On Tue, May 16, 2017, at 09:50 AM, Iavor Diatchki wrote:

That seems fairly reasonable to me.

-Iavor

On Tue, May 16, 2017 at 7:18 AM, Joachim Breitner < mail@joachim-breitner.de> wrote:

Hi,

a very small proposal to be considered for Haskell':

Currently, the report states

An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be ‘module Main(main) where’.

I propose to change that to

An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be ‘module Main where’.

The rationale is that a main-less main module is still useful, e.g. when you are working a lot in GHCi, and offload a few extensions to a separate file. Currently, tools like hdevtools will complain about a missing main function when editing such a file.

It would also work better with GHC’s -main-is flag, and avoid problems like the one described in https://ghc.haskell.org/trac/ghc/ticket/13704

I don’t see any downsides. When compiling to a binary, implementations are still able to detect that a Main module is not imported by any other module and only the main function is used, and optimize as if only main were exported.

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

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

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

-- https://zerobuzz.net/ mf@zerobuzz.net +49 179 7733 223

Hi, I thought about this. But I fear that this will require a language extension or flag, and then the developers (quite rightly) say that it does not pull its weight of supporting both variants, and it gets lost. But maybe I should give it a shot if they accept it. Joachim Am Freitag, den 19.05.2017, 17:35 -0400 schrieb Mario Blažević:

On 2017-05-16 10:18 AM, Joachim Breitner wrote:

...

Hi,

a very small proposal to be considered for Haskell':

I like it, but it should probably be a GHC proposal first. I don't  think Haskell' is supposed to make any change to the standard that  hasn't been already implemented and tested. In this particular case, GHC  HQ might opt to implement your proposal but hide it behind a  command-line option, or to enable it by default only in GHCi. There are  already precedents for this.

...

Currently, the report states

    An abbreviated form of module, consisting only of the module body,     is permitted. If this is used, the header is assumed to be ‘module     Main(main) where’.

I propose to change that to

    An abbreviated form of module, consisting only of the module body,     is permitted. If this is used, the header is assumed to be ‘module     Main where’.

The rationale is that a main-less main module is still useful, e.g. when you are working a lot in GHCi, and offload a few extensions to a separate file. Currently, tools like hdevtools will complain about a missing main function when editing such a file.

It would also work better with GHC’s -main-is flag, and avoid problems like the one described in https://ghc.haskell.org/trac/ghc/ticket/1 3704

I don’t see any downsides. When compiling to a binary, implementations are still able to detect that a Main module is not imported by any other module and only the main function is used, and optimize as if only main were exported.

Greetings, Joachim

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

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

On 19/05/17 07:12 PM, Francesco Ariis wrote:

...

I thought about this. But I fear that this will require a language extension or flag, and then the developers (quite rightly) say that it does not pull its weight of supporting both variants, and it gets lost. But maybe I should give it a shot if they accept it. Indeed this strikes me as a not a good extension to have: every extension further fragments the ecosystem and is yet another thing to care about if you are reading someone else's code, etc. - the cost probably outweights

On Fri, May 19, 2017 at 06:32:30PM -0400, Joachim Breitner wrote: the benefit on this one.

But it seems a good proposal for H2020, as (if it is accepted), the costs linked with an extension/flag (added complexity, fragmentation of the community) aren't there.

The "extensions before report modification" is a solid rule, maybe the committee wants to add an exception for proposals which cannot realistically be "packaged" (and achieve widespread use) into extensions?

I feel it's rather ironic that there exists a class of proposals that are considered acceptable for Haskell' but too radical for GHC, considering that the stands are usually completely opposite. The obvious way out of this conundrum is to communicate with GHC. If the Haskell' committee gives a proposal some sort of conditional acceptance status, that should count for something with the GHC HQ. After all, they'd presumably have to implement it once it's officially a part of the next standard, so implementing it sooner as a proposal is not that much more to ask.

On 2017-05-24 10:28 AM, Joachim Breitner wrote:

...

I've ended up uncertain, so I'll just throw it out there: are unused value warnings affected by this proposal?

that is a very good point, thanks for raising it. I have two different answers:

A) You are right. Everything is exported, so without an explicit module header, unused value warnings would not happen. This is undesirable, and thus this proposal should probably be killed.

B) Warnings are not specified by the report, and the implementation is free to warn about unused bindings in a headerless Main module, based on the implementation’s knowledge that even though these are exported, they are not used.

I would say B') Warnings are not specified by the report. We can pretty much stop there. If you want to go deeper, IMO the compiler should just suppress the warnings by default. A headerless module would normally be used only for examples and quick tests, unused binding warnings would be a nuisance for that use case.

But answer B is less convincing in the corner case of Main being mutually recursive with another module. (Who would do that without naming Main? But yes, it is a problem.)

When dicussing a software-engineering issue like compiler warnings, as opposed to a language-design issue, it doesn't make sense to concentrate on corner cases. A non-root Main module is already a corner case. A non-root header-less Main module is a corner inside a corner case. Whoever does that may miss some compiler warnings, depending on the compiler implementation. I won't lose any sleep over that. If the compiler developers do, they have the option to issue the unused-binding warnings only when a header-less module is imported.