[ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative

Cale Gibbard cgibbard at gmail.com
Sat May 2 09:54:30 UTC 2020


I greatly prefer the earlier module-based version of this where the
definitions of the relevant functions are simply obtained from the
qualified module and we don't have to talk about fully-settled types
to explain how expressions are going to desugar. Even if it's not
quite true in the case of GHC's internals that desugaring comes
entirely before typechecking, I think it's really very helpful in both
understanding the language ourselves and in explaining it to beginners
if we can at least think about it that way. The more that the
translation from surface syntax to core factors into a bunch of
individually comprehensible translations, the better.

On Sat, 2 May 2020 at 05:39, Joachim Breitner <mail at joachim-breitner.de> wrote:
>
> Dear Committee,
>
> it seems discussion has ebbed down. Are there any new arguments that
> can be brought forward? Did anyone have a change of mind which would
> bring us closer to (or farther away from) consensus? Or should we vote?
>
> Simon Marlow, Chris, Cale, Tom:
> You have not stated an opinion. Do you have one?
>
> Cheers,
> Joachim
>
> Am Mittwoch, den 22.04.2020, 12:26 +0200 schrieb Joachim Breitner:
> > Dear Committe,
> >
> > trying to summarize the discussion here.
> >
> > The main decision seems to be: Record based or module based.
> >
> >    Record based is preferred by:
> >    Arnaud (one of the authors), SPJ
> >
> >    Module based is preferred by:
> >    Richard (after changing his mind), Eric, Iavor, Vitaly, Alejandro,
> >    me
> >
> > This is not a vote, merely a summary of sentimenss. But it seems that
> > maybe the onus to make stronger arguments for the record-based approach
> > is on Simon and Arnaud?
> >
> >
> > Related to the  module based variant, there was some discussion about
> > whether the
> >  * desugaring should go to a “qualified name”, that is then resolved
> >    like any manually written name
> >    (i.e. could conceptually be done in the parser)
> >  * or if it should go directly a suitable “original name” of a suitable
> >    function, even if not explicitly imported
> >    (i.e. could conceptually be done in the renamer, but not the parser)
> >
> > I initially advocated for the latter, arguing with a “you shall not
> > have to import stuff you do not write explicitly” rule.
> > But Simon’s recent argument that
> >
> >     import qualified Monad as M
> >
> > (i.e. _with_ qualification, but _without_ an import list) will give the
> > developer a good user experience, and if they try to do things like
> >
> >     import Monad as M (runMonad)
> >     … M.do …
> >
> > then, well, they shouldn’t. So I am happy to advocate for the module
> > based approach with the “must be in scope” rule. But maybe we should
> > keep the focus more on the fundamental question above.
> >
> >
> >
> > We could keep in mind that eventually, people will ask for M.if; M.[
> > and other “qualified syntax”. But it seems that that will work equally
> > well with either choice here.
> >
> > Cheers,
> > Joachim
> >
> >
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


More information about the ghc-steering-committee mailing list