@Malte, in my opinion, with the extension on, types which are not covered by the type class should error out. I'd like to have some more understanding of what's feasible to implement. Adam, Simon PJ, could you share some insight there? On Thu, 21 Mar 2024 at 00:19, Malte Ott <malte.ott@maralorn.de> wrote:
On 2024-03-19 15:15, Arnaud Spiwack wrote:
So, my opinion that I promised, is that the best would probably be to have add a warning when main doesn't have type `IO ()` or `IO Void` without the extension (the behaviour is otherwise unchanged), and then change the behaviour to use the typeclass with an extension (which we hope to turn on by default in the next language edition). The extension should probably
Now, I don't actually know how to implement this properly. So maybe it's a bad idea. But I believe that's what I'd like to see. disable the warning.
From my understanding that is basically equivalent to what I was proposing. It has the properties:
* Using a return type which could reasonably be expected to exit with failure should warn on -Wdefault (no matter whether a potential extension is enabled). * Concretely this means any return type but (), Void and maybe forall a. a, when the extension is off. * The warning could point to existing instances and the extension. * For anything which does not have an ExitCode implementation, when the extension is on. * Using the ExitCode type class should be possible but gated behind an extension.
Now the question whether we should have two different warnings, one when the extension is on and one when it is off or one warning which changes its wording and behavior slightly depending on the extension being enabled does not matter that much in my opinion.
Best Malte
On Fri, 15 Mar 2024 at 15:32, Matthías Páll Gissurarson <mpg@mpg.is> wrote:
I agree. I like it, but better behind an extension to avoid surprises and enable experimentation.
On Fri, 15 Mar 2024 at 13:15, Simon Marlow <marlowsd@gmail.com> wrote:
I also think any change in behaviour should be behind an extension.
Cheers Simon
On Thu, 14 Mar 2024 at 16:51, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
I like the proposal basically as is. i.e. typeclass + warning Especially the fact that it warns everyone and breaks no-one (who doesn’t want to).
I am weakly in favor of gating the usage of the typeclass for anything but () and Void behind an extension. That way no program will newly exit with failure without the user opting in and we might be able to experiment more on the type class.
I'm with Malte. But I don't have strongly held views.
Simon
On Thu, 14 Mar 2024 at 14:04, Malte Ott <malte.ott@maralorn.de> wrote:
I like the proposal basically as is. i.e. typeclass + warning Especially the fact that it warns everyone and breaks no-one (who doesn’t want to).
I am weakly in favor of gating the usage of the typeclass for anything but () and Void behind an extension. That way no program will newly exit with failure without the user opting in and we might be able to experiment more on the type class.
Best Malte
On 2024-03-14 14:32, Arnaud Spiwack wrote:
Dear all,
Shea has updated his proposal based on the committee's feedback.
There seem to be two main alternatives being considered at the moment - Having a type class to compute the exit code based on the type. This is Shea's favourite. It can be done without an extension (as Shea's proposing) or with an extension. - Keep the current behaviour but emit a warning when the return type of `main` isn't `()` or `Void`.
I have opinions about my preference, but I'd like to hear about everybody's thoughts first.
On Thu, 7 Mar 2024 at 10:27, Adam Gundry <adam@well-typed.com> wrote:
I've added a comment to the GitHub thread (
https://github.com/ghc-proposals/ghc-proposals/pull/631#issuecomment-1983060...
)
elaborating slightly on Richard's suggestion (albeit with an
effectively
indefinite transition period).
Adam
On 05/03/2024 08:52, Arnaud Spiwack wrote:
This is Alternative 7.5 in the current version of the proposal
https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main...
<
https://github.com/shlevy/ghc-proposals/blob/io-exitcode/proposals/0631-main...
.
PS: I tend to agree with Richard that requiring an ExitStatus
instance
is the preferable option. But food for thought for the proposal thread when that conversation happens there: should that be gated behind an extension? In which case it won't become the default before the next language edition.
/Arnaud
On Mon, 4 Mar 2024 at 21:35, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto: simon.peytonjones@gmail.com
wrote:
I left out a key part of my last email -- apologies.
I'm
floating a counter-proposal where we *require* an
instance of
ExitStatus on the return type of `main`, with a
transition
period. In contrast, my understanding of the proposal
written is
that it would use such an instance if it exists, but
issue a
warning if it doesn't, in perpetuity.
Ah I had not realised that.
But why?
Rather than answer here (private to SC) why don't you put
your
proposal on the discussion thread, say why, and invite
feedback.
Simon
On Mon, 4 Mar 2024 at 19:24, Richard Eisenberg <reisenberg@janestreet.com <mailto:
reisenberg@janestreet.com
wrote:
I left out a key part of my last email -- apologies.
I'm
floating a counter-proposal where we *require* an
instance of
ExitStatus on the return type of `main`, with a
transition
period. In contrast, my understanding of the proposal
written is
that it would use such an instance if it exists, but
issue a
warning if it doesn't, in perpetuity.
Richard
On Mon, Mar 4, 2024 at 6:14 AM Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
I am a little worried about breaking programs
that end
in an innocent-looking `return 0`, just
because some
other languages like to end programs with that
phrase
The proposal specifies that such a program returns `ExitSuccess`, but adds a warning. That seems OK
to me; it
does not break the program.
Oh -- maybe you mean that `return 1` means "return
with exit
code 1" today. Is that really true? I don't
think so.
Overall this proposal seems fine to me. I'd be
happy to see
it done.
Simon
On Thu, 29 Feb 2024 at 12:38, Richard Eisenberg <reisenberg@janestreet.com <mailto:reisenberg@janestreet.com>> wrote:
I haven't followed this proposal closely. But
couldn't
we have a transition period toward this
eventual goal?
That is, introduce a new warning, on by
default, if
`main` returns anything other than `()`. That
goes for a
few releases. Then we require that the return
type of
main has an instance of ExitStatus.
I'm not worried about changing the behavior of
programs
that have type IO ExitCode but expect the
program to
return 0 unconditionally; that's just begging
for
confusion. I am a little worried about
breaking programs
that end in an innocent-looking `return 0`,
just because
some other languages like to end programs with
that
phrase. So I'm not sure if we should have an
instance
ExitStatus Int (or instance ExitStatus
Integer) -- but
we probably should. If a program ends with
`return 1`,
the programmer probably wants the OS to
return 1 as well.
Richard
On Thu, Feb 29, 2024 at 5:29 AM Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Dear all,
Shea Levy proposes to do something with
the values
returned by `main`
https://github.com/ghc-proposals/ghc-proposals/pull/631 < https://github.com/ghc-proposals/ghc-proposals/pull/631> .
The problem is that `main` is allowed to
be of type
`IO A` for any `A`. And GHC will simply
drop the
value returned by `main`. Shea contends
that it's
surprising. I agree that dropping a value
without
the compiler being explicitly instructed
to is
surprising. But Shea says that when `A` is `ExitCode` this is even more surprising.
Namely
`main :: IO ExitCode; main = return $
Failure 1`
actually terminates with exit code 0. And
I doubt
that it's what anybody expects when
reading the code.
The proposal is simple, but I have a lot
of comments
on it. Sorry about that…
Now, this sort of proposal is tricky.
When the
current behaviour is confusing, we want to
change
the default. But putting the new default
behind an
extension doesn't really solve the fact
that there's
a trap. The extension is, therefore,
unlikely to be
well tested before it becomes part of the
next
language edition.
Shea's main proposition doesn't actually
use an
extension though. He adds a type class
`ExitStatus`,
and if `ExistStatus A`, then `main :: IO
A` uses the
instance to determine the exit code based
on the
return value.
The only change to the current behaviour
is that
`main :: IO ExitCode` instead of always
terminating
with exit code 0 when returning now
terminates with
the expected error code. The argument for
not
putting this behind an extension is that
virtually
anybody affected by the change will
actually have
the behaviour they were expecting. But
maybe the
argument isn't strong enough (the changes
may be
more “interesting” if some library exports
some
`ExistStatus` instance).
This design of this proposal is inspired
by Rust's
design. I've asked our Rust team, and they
certainly
seem to have internalised the idea of
returning an
exit code. It really seems a pretty
natural feature
to have. So I'm rather in favour of some
flavour of
the type class implementation. Though
have a look at
the alternatives, where you'll find other
approaches
such as restricting the type of `main` to unsurprising types.
One caveat with respect to the main
proposal: it is
proposed that when no `ExistStatus A` is
found, then
we drop the returned value like today. I
don't know
that it's quite easy to implement this
behaviour.
But it can be recovered by a catch-all
overlapping
instance, so maybe it's a better way to
specify the
desired behaviour.
-- Arnaud Spiwack Director, Research at
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- -- Matthías Páll Gissurarson <http://mpg.is/> _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.