From mail at joachim-breitner.de Tue May 16 14:18:51 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 16 May 2017 10:18:51 -0400 Subject: Default module header `module Main where` Message-ID: <1494944331.1206.4.camel@joachim-breitner.de> 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 at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From iavor.diatchki at gmail.com Tue May 16 16:50:17 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 16 May 2017 09:50:17 -0700 Subject: Default module header `module Main where` In-Reply-To: <1494944331.1206.4.camel@joachim-breitner.de> References: <1494944331.1206.4.camel@joachim-breitner.de> Message-ID: 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 at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmct at jmct.cc Tue May 16 16:59:49 2017 From: jmct at jmct.cc (=?utf-8?Q?Jos=C3=A9=20Manuel=20Calder=C3=B3n=20Trilla?=) Date: Tue, 16 May 2017 09:59:49 -0700 Subject: Default module header `module Main where` In-Reply-To: References: <1494944331.1206.4.camel@joachim-breitner.de> Message-ID: <1494953989.970128.978574568.6115CD2C@webmail.messagingengine.com> 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 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 at joachim-breitner.de • >> https://www.joachim-breitner.de/ XMPP: nomeata at joachim-breitner.de >> • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org>> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> > _________________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Tue May 16 17:53:17 2017 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 16 May 2017 17:53:17 +0000 Subject: Default module header `module Main where` In-Reply-To: <1494953989.970128.978574568.6115CD2C@webmail.messagingengine.com> References: <1494944331.1206.4.camel@joachim-breitner.de> <1494953989.970128.978574568.6115CD2C@webmail.messagingengine.com> Message-ID: 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 at 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 at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > *_______________________________________________* > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mf at zerobuzz.net Tue May 16 19:40:49 2017 From: mf at zerobuzz.net (Matthias Fischmann) Date: Tue, 16 May 2017 21:40:49 +0200 Subject: Default module header `module Main where` In-Reply-To: References: <1494944331.1206.4.camel@joachim-breitner.de> <1494953989.970128.978574568.6115CD2C@webmail.messagingengine.com> Message-ID: <20170516194049.GX1508@localhost.localdomain> 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 at 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 at 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 at joachim-breitner.de • https://www.joachim-breitner.de/ > > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > > Debian Developer: nomeata at debian.org > > _______________________________________________ > > Haskell-prime mailing list > > Haskell-prime at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > *_______________________________________________* > > Haskell-prime mailing list > > Haskell-prime at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > > > _______________________________________________ > > Haskell-prime mailing list > > Haskell-prime at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime -- https://zerobuzz.net/ mf at zerobuzz.net +49 179 7733 223 From iavor.diatchki at gmail.com Tue May 16 20:25:16 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 16 May 2017 13:25:16 -0700 Subject: Default module header `module Main where` In-Reply-To: <1494944331.1206.4.camel@joachim-breitner.de> References: <1494944331.1206.4.camel@joachim-breitner.de> Message-ID: One potential difference between the two is that the current behavior allows the `Main` module to import `main` from another module, while the new behavior would fail in that case. For example, a file that has only a single line: import SomeOtherModule(main) This still seems like a fairly unusual corner case (with an obvious work around), so I don't think it matters much, but I thought I'd mention it so that we are aware of it. 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 at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chow.soham at gmail.com Wed May 17 12:58:04 2017 From: chow.soham at gmail.com (Soham Chowdhury) Date: Wed, 17 May 2017 12:58:04 +0000 Subject: Haskell-prime Digest, Vol 104, Issue 2 In-Reply-To: References: Message-ID: Apologies if this question's already been discussed here, but have there been any discussions about switching the meanings of the : and :: operators? The rationale here is, of course, that :: is (probably, beware of anecdata) used a lot more than : is. Obviously this would have the effect of breaking essentially every module ever written if it were done "automatically", but could there not be something akin to what -XDataKinds did for the * kind? I don't genuinely expect this to ever happen, and I can't exactly defend the headache this would pose for comparatively little gain (including having to check the file header if not all your code sticks to one convention), but it would still, well, be really nice. I've been doing some type-level stuff for a while using Type instead of *, and it's caused less friction than I expected there to be. As a logical extension of this, it seems like a :/:: replacement might improve ergonomics more than a little as we move towards full Dependent Haskell. Soham On Wed, May 17, 2017, 17:57 wrote: > Send Haskell-prime mailing list submissions to > haskell-prime at haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > or, via email, send a message with subject or body 'help' to > haskell-prime-request at haskell.org > > You can reach the person managing the list at > haskell-prime-owner at haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-prime digest..." > > > Today's Topics: > > 1. Re: Default module header `module Main where` (Matthias Fischmann) > 2. Re: Default module header `module Main where` (Iavor Diatchki) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 16 May 2017 21:40:49 +0200 > From: Matthias Fischmann > To: Adam Bergmark > Cc: haskell-prime at haskell.org > Subject: Re: Default module header `module Main where` > Message-ID: <20170516194049.GX1508 at localhost.localdomain> > Content-Type: text/plain; charset=utf-8 > > > 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 at 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 at 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 at joachim-breitner.de • https://www.joachim-breitner.de/ > > > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > > > Debian Developer: nomeata at debian.org > > > _______________________________________________ > > > Haskell-prime mailing list > > > Haskell-prime at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > > > *_______________________________________________* > > > Haskell-prime mailing list > > > Haskell-prime at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > > > > > > _______________________________________________ > > > Haskell-prime mailing list > > > Haskell-prime at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > > > _______________________________________________ > > Haskell-prime mailing list > > Haskell-prime at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > -- > https://zerobuzz.net/ > mf at zerobuzz.net > +49 179 7733 223 > > > ------------------------------ > > Message: 2 > Date: Tue, 16 May 2017 13:25:16 -0700 > From: Iavor Diatchki > To: Joachim Breitner > Cc: "haskell-prime at haskell.org Prime" > Subject: Re: Default module header `module Main where` > Message-ID: > sjWnSafi_peu9nzpvxE5dpeAekDdwsxRfA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > One potential difference between the two is that the current behavior > allows the `Main` module to import `main` from another module, while the > new behavior would fail in that case. > > For example, a file that has only a single line: > > import SomeOtherModule(main) > > This still seems like a fairly unusual corner case (with an obvious work > around), so I don't think it matters much, but I thought I'd mention it so > that we are aware of it. > > > > > > > On Tue, May 16, 2017 at 7:18 AM, Joachim Breitner < > mail at 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 at joachim-breitner.de • https://www.joachim-breitner.de/ > > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > > Debian Developer: nomeata at debian.org > > _______________________________________________ > > Haskell-prime mailing list > > Haskell-prime at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mail.haskell.org/pipermail/haskell-prime/attachments/20170516/0c22e88d/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > ------------------------------ > > End of Haskell-prime Digest, Vol 104, Issue 2 > ********************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Thu May 18 21:55:05 2017 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Fri, 19 May 2017 07:55:05 +1000 Subject: Switching the meanings of the : and :: (was Haskell-prime Digest, Vol 104, Issue 2) In-Reply-To: References: Message-ID: <20170519075505.37640ba369ca3da3e89442b4@mega-nerd.com> Soham Chowdhury wrote: > Apologies if this question's already been discussed here, but have there > been any discussions about switching the meanings of the : and :: > operators? The rationale here is, of course, that :: is (probably, beware > of anecdata) used a lot more than : is. > > Obviously this would have the effect of breaking essentially every module > ever written if it were done "automatically", but could there not be > something akin to what -XDataKinds did for the * kind? Sorry, from a cost/benefit analysis point of view this doesn't look very promising at all. The costs are very obvious: * Implementation in GHC and ongoing maintenance. * The extra cognitive load put on every developer who has to work on code that has both forms. There are probably others, but as far as I am concerned the second alone far outweights any potential benefit. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mblazevic at stilo.com Fri May 19 21:35:24 2017 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Fri, 19 May 2017 17:35:24 -0400 Subject: Default module header `module Main where` In-Reply-To: <1494944331.1206.4.camel@joachim-breitner.de> References: <1494944331.1206.4.camel@joachim-breitner.de> Message-ID: 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/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 > > > > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -- Mario Blazevic mblazevic at stilo.com Stilo International This message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, copying, or distribution is strictly prohibited. If you are not the intended recipient(s) please contact the sender by reply email and destroy all copies of the original message and any attachments. From carter.schonwald at gmail.com Fri May 19 21:44:54 2017 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 19 May 2017 17:44:54 -0400 Subject: Default module header `module Main where` In-Reply-To: References: <1494944331.1206.4.camel@joachim-breitner.de> Message-ID: as a guideline what you say is true, and at least in this case as the motivation is user focused it should be validated thusly :) On Fri, May 19, 2017 at 5:35 PM, Mario Blažević wrote: > 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/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 >> >> >> >> >> >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> >> > > -- > Mario Blazevic > mblazevic at stilo.com > Stilo International > > This message, including any attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged > information. Any unauthorized review, use, disclosure, copying, or > distribution is strictly prohibited. If you are not the intended > recipient(s) please contact the sender by reply email and destroy > all copies of the original message and any attachments. > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri May 19 22:32:30 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 19 May 2017 18:32:30 -0400 Subject: Default module header `module Main where` In-Reply-To: References: <1494944331.1206.4.camel@joachim-breitner.de> Message-ID: <1495233150.1251.1.camel@joachim-breitner.de> 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 at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From fa-ml at ariis.it Fri May 19 23:12:31 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Sat, 20 May 2017 01:12:31 +0200 Subject: Default module header `module Main where` In-Reply-To: <1495233150.1251.1.camel@joachim-breitner.de> References: <1494944331.1206.4.camel@joachim-breitner.de> <1495233150.1251.1.camel@joachim-breitner.de> Message-ID: <20170519231231.GA12194@casa.casa> On Fri, May 19, 2017 at 06:32:30PM -0400, Joachim Breitner 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 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? From blamario at ciktel.net Sat May 20 03:03:32 2017 From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Fri, 19 May 2017 23:03:32 -0400 Subject: Default module header `module Main where` In-Reply-To: <20170519231231.GA12194@casa.casa> References: <1494944331.1206.4.camel@joachim-breitner.de> <1495233150.1251.1.camel@joachim-breitner.de> <20170519231231.GA12194@casa.casa> Message-ID: On 19/05/17 07:12 PM, Francesco Ariis wrote: > On Fri, May 19, 2017 at 06:32:30PM -0400, Joachim Breitner 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 > 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. From mail at joachim-breitner.de Sat May 20 16:19:22 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 20 May 2017 12:19:22 -0400 Subject: Default module header `module Main where` In-Reply-To: <1495233150.1251.1.camel@joachim-breitner.de> References: <1494944331.1206.4.camel@joachim-breitner.de> <1495233150.1251.1.camel@joachim-breitner.de> Message-ID: <1495297162.8781.1.camel@joachim-breitner.de> Hi for good measure, I drafted a GHC proposal: https://github.com/ghc-proposals/ghc-proposals/pull/53 Greetins, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From haskell at benmachine.co.uk Wed May 24 13:50:12 2017 From: haskell at benmachine.co.uk (Ben Millwood) Date: Wed, 24 May 2017 21:50:12 +0800 Subject: Default module header `module Main where` In-Reply-To: <1494944331.1206.4.camel@joachim-breitner.de> References: <1494944331.1206.4.camel@joachim-breitner.de> Message-ID: <20170524135008.GA610@euler.local> On Tue, May 16, 2017 at 10:18:51AM -0400, Joachim Breitner wrote: >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’. >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. Initially I was concerned that this proposal would implicitly export everything from Main, which would then prevent compilers from warning about unused values, since they can't tell if seemingly-unused things are in fact being exported for use elsewhere (perhaps by a program that is not currently being compiled, so looking at what exported values are used elsewhere is not a solution). Then I started wondering if a standards-compliant Haskell program can ever import anything from a module called Main (because module names should be unique across a program, and there should be a Main module at the root of the dependency graph). Then I started wondering about a Main module that was mutually recursive with another module. I've ended up uncertain, so I'll just throw it out there: are unused value warnings affected by this proposal? From mail at joachim-breitner.de Wed May 24 14:28:12 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 24 May 2017 10:28:12 -0400 Subject: Default module header `module Main where` In-Reply-To: <20170524135008.GA610@euler.local> References: <1494944331.1206.4.camel@joachim-breitner.de> <20170524135008.GA610@euler.local> Message-ID: <1495636092.32473.3.camel@joachim-breitner.de> Hi, Am Mittwoch, den 24.05.2017, 21:50 +0800 schrieb Ben Millwood: > Initially I was concerned that this proposal would implicitly export  > everything from Main, which would then prevent compilers from warning  > about unused values, since they can't tell if seemingly-unused things  > are in fact being exported for use elsewhere (perhaps by a program that  > is not currently being compiled, so looking at what exported values are  > used elsewhere is not a solution). > > Then I started wondering if a standards-compliant Haskell program can  > ever import anything from a module called Main (because module names  > should be unique across a program, and there should be a Main module  > at the root of the dependency graph). > > Then I started wondering about a Main module that was mutually recursive  > with another module. > > 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. 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.) So your point makes me less convinced about my proposal. So maybe the solution is to not make this change, but rather change fix the original problem (tools like IDEs complaining about the lack of “main” in a headerless, main-less module) by being a bit more liberal in these tools. I still believe that the -main-is flag should affect the default module header (GHC #13704), but that is a separate issue. Well, thanks for the constructive feedback everyone :-) Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mblazevic at stilo.com Wed May 24 16:14:44 2017 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Wed, 24 May 2017 12:14:44 -0400 Subject: Default module header `module Main where` In-Reply-To: <1495636092.32473.3.camel@joachim-breitner.de> References: <1494944331.1206.4.camel@joachim-breitner.de> <20170524135008.GA610@euler.local> <1495636092.32473.3.camel@joachim-breitner.de> Message-ID: <2b46258c-2152-16d8-4aa4-58ad76c21df3@stilo.com> 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. From johnw at newartisans.com Sat May 27 22:35:08 2017 From: johnw at newartisans.com (John Wiegley) Date: Sat, 27 May 2017 15:35:08 -0700 Subject: Haskell-prime Digest, Vol 104, Issue 2 In-Reply-To: (Soham Chowdhury's message of "Wed, 17 May 2017 12:58:04 +0000") References: Message-ID: >>>>> "SC" == Soham Chowdhury writes: SC> I don't genuinely expect this to ever happen, and I can't exactly defend SC> the headache this would pose for comparatively little gain (including SC> having to check the file header if not all your code sticks to one SC> convention), but it would still, well, be really nice. As much as I'd love to see it too (after programming in Coq, I constantly get things mixed up whenever I jump back to Haskell), I can't see this ever happening either. That ship has sailed, as they say. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2