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

[Simon Marlow]

On Sat, 2 May 2020 at 10: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?
>

Ideally the extension would use record overloading, but I understand why
that can't work right now (thanks Richard for enlightening me). Given that,
I'm not keen on introducing the concept of "fully settled types" - it feels
like a kludge, and introducing a special type system concept for this one
particular extension doesn't seem like the right tradeoff to me. Perhaps if
it was available for general record selection too... but then we have to
worry about the interaction with the existing overloaded record selection
mechanism.

On the other hand, the modules-based approach is simple to describe,
conservative, and supports the important uses. It's not ideal, but on
balance it seems like the right approach for now.

Cheers
Simon


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200505/23b3aee6/attachment.html>