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

[Iavor Diatchki]

You can define dynamic builders with the module based approach, there's an
example on the GitHub thread.

Iavor

On Mon, May 4, 2020, 05:00 Tom Harding <tomjharding at live.co.uk> wrote:

> I’ve been quiet so far because I think both outcomes are perfectly
> sensible, and I don’t think I have anything to add that hasn’t already been
> covered.
>
> If really pushed, I’d perhaps have a slight bias towards the record-based
> approach, but really only because of the future possibility of dynamically
> constructing builders. However, I don’t think that preference is strong
> enough to be worth counting - I’m happy to abstain.
>
> Thanks,
> Tom
>
> > On 2 May 2020, at 10:54, Cale Gibbard <cgibbard at gmail.com> wrote:
> >
> > 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
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> 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/20200504/9cc54ba4/attachment.html>