<div dir="ltr"><div>Sorry to have been quiet after Joachim's soliciting more input from me,</div><div><br></div><div>Let me try to summarize why I prefer the records approach (and I think it sort of boils down to the same intuition as Simon (Peyton Jones)'s reasons):</div><div><br></div><div>It boils down to: a record would define, in no ambiguous terms, a do notation desugaring strategy. Whereas in the module-based approach, a given do block is allowed to pick and mix different combinators from wherever it wants; even if they don't go together very well.<br></div><div><br></div><div>- This makes it certain which combinators are working together. With the modules, who's to say that I am not mistakenly taking `(>>)` from a different location because I'm mixing modules together (and the module I think I'm using doesn't actually export `(>>)`)? I'd eventually find out, but it would be rather unpleasant to debug considering that I'm not even seeing `M.>>` in my code.</div><div>- Error messages can tell me: “your builder doesn't support `>>`”, rather than telling me, “You're not importing an `M.>>`” which is a less ambiguous error.</div><div><br></div><div>This feature, overall, makes more sense to me with records.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 4, 2020 at 6:46 PM Tom Harding <<a href="mailto:tomjharding@live.co.uk" target="_blank">tomjharding@live.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
I’m nervous to endorse any solution that requires implicit parameters generally, just because of the cognitive overhead involved in reading and understanding any code involving them. I think, for the particular problem of dynamic builders, the record approach
 ends up being more “idiomatic Haskell” (for my personal definition of idiomatic, of course).
<div><br>
</div>
<div>That said, I can’t deny that the solution works! Moreover, given that I don’t have a concrete example of a problem in mind, I wouldn’t want to hold up a final decision.
<div><br>
</div>
<div>Cheers,</div>
<div>Tom<br>
<div><br>
<blockquote type="cite">
<div>On 4 May 2020, at 16:22, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>> wrote:</div>
<br>
<div>
<div dir="auto">You can define dynamic builders with the module based approach, there's an example on the GitHub thread.
<div dir="auto"><br>
</div>
<div dir="auto">Iavor</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, May 4, 2020, 05:00 Tom Harding <<a href="mailto:tomjharding@live.co.uk" rel="noreferrer" target="_blank">tomjharding@live.co.uk</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
Tom<br>
<br>
> On 2 May 2020, at 10:54, Cale Gibbard <<a href="mailto:cgibbard@gmail.com" rel="noreferrer noreferrer" target="_blank">cgibbard@gmail.com</a>> wrote:<br>
> <br>
> I greatly prefer the earlier module-based version of this where the<br>
> definitions of the relevant functions are simply obtained from the<br>
> qualified module and we don't have to talk about fully-settled types<br>
> to explain how expressions are going to desugar. Even if it's not<br>
> quite true in the case of GHC's internals that desugaring comes<br>
> entirely before typechecking, I think it's really very helpful in both<br>
> understanding the language ourselves and in explaining it to beginners<br>
> if we can at least think about it that way. The more that the<br>
> translation from surface syntax to core factors into a bunch of<br>
> individually comprehensible translations, the better.<br>
> <br>
> On Sat, 2 May 2020 at 05:39, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" rel="noreferrer noreferrer" target="_blank">mail@joachim-breitner.de</a>> wrote:<br>
>> <br>
>> Dear Committee,<br>
>> <br>
>> it seems discussion has ebbed down. Are there any new arguments that<br>
>> can be brought forward? Did anyone have a change of mind which would<br>
>> bring us closer to (or farther away from) consensus? Or should we vote?<br>
>> <br>
>> Simon Marlow, Chris, Cale, Tom:<br>
>> You have not stated an opinion. Do you have one?<br>
>> <br>
>> Cheers,<br>
>> Joachim<br>
>> <br>
>> Am Mittwoch, den 22.04.2020, 12:26 +0200 schrieb Joachim Breitner:<br>
>>> Dear Committe,<br>
>>> <br>
>>> trying to summarize the discussion here.<br>
>>> <br>
>>> The main decision seems to be: Record based or module based.<br>
>>> <br>
>>>   Record based is preferred by:<br>
>>>   Arnaud (one of the authors), SPJ<br>
>>> <br>
>>>   Module based is preferred by:<br>
>>>   Richard (after changing his mind), Eric, Iavor, Vitaly, Alejandro,<br>
>>>   me<br>
>>> <br>
>>> This is not a vote, merely a summary of sentimenss. But it seems that<br>
>>> maybe the onus to make stronger arguments for the record-based approach<br>
>>> is on Simon and Arnaud?<br>
>>> <br>
>>> <br>
>>> Related to the  module based variant, there was some discussion about<br>
>>> whether the<br>
>>> * desugaring should go to a “qualified name”, that is then resolved<br>
>>>   like any manually written name<br>
>>>   (i.e. could conceptually be done in the parser)<br>
>>> * or if it should go directly a suitable “original name” of a suitable<br>
>>>   function, even if not explicitly imported<br>
>>>   (i.e. could conceptually be done in the renamer, but not the parser)<br>
>>> <br>
>>> I initially advocated for the latter, arguing with a “you shall not<br>
>>> have to import stuff you do not write explicitly” rule.<br>
>>> But Simon’s recent argument that<br>
>>> <br>
>>>    import qualified Monad as M<br>
>>> <br>
>>> (i.e. _with_ qualification, but _without_ an import list) will give the<br>
>>> developer a good user experience, and if they try to do things like<br>
>>> <br>
>>>    import Monad as M (runMonad)<br>
>>>    … M.do …<br>
>>> <br>
>>> then, well, they shouldn’t. So I am happy to advocate for the module<br>
>>> based approach with the “must be in scope” rule. But maybe we should<br>
>>> keep the focus more on the fundamental question above.<br>
>>> <br>
>>> <br>
>>> <br>
>>> We could keep in mind that eventually, people will ask for M.if; M.[<br>
>>> and other “qualified syntax”. But it seems that that will work equally<br>
>>> well with either choice here.<br>
>>> <br>
>>> Cheers,<br>
>>> Joachim<br>
>>> <br>
>>> <br>
>> --<br>
>> Joachim Breitner<br>
>>  <a href="mailto:mail@joachim-breitner.de" rel="noreferrer noreferrer" target="_blank">
mail@joachim-breitner.de</a><br>
>>  <a href="http://www.joachim-breitner.de/" rel="noreferrer noreferrer noreferrer" target="_blank">
http://www.joachim-breitner.de/</a><br>
>> <br>
>> <br>
>> _______________________________________________<br>
>> ghc-steering-committee mailing list<br>
>> <a href="mailto:ghc-steering-committee@haskell.org" rel="noreferrer noreferrer" target="_blank">
ghc-steering-committee@haskell.org</a><br>
>> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer noreferrer noreferrer" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" rel="noreferrer noreferrer" target="_blank">
ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer noreferrer noreferrer" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" rel="noreferrer noreferrer" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer noreferrer noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>

_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>