Re: Default module header `module Main where`

2017-05-24 Thread Mario Blažević

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.


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


Re: Default module header `module Main where`

2017-05-24 Thread Joachim Breitner
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
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


signature.asc
Description: This is a digitally signed message part
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime