[ghc-steering-committee] Bundling patterns with type synonyms (#28)

[Richard Eisenberg]

I agree with rejecting. I think this should be part of a larger proposal to introduce modules.

Thanks,
Richard

> On Sep 30, 2018, at 3:22 PM, Christopher Allen <cma at bitemyapp.com> wrote:
> 
> I think based on what transpired in this thread and on the GitHub PR,
> the proposal should be rejected. My reasoning:
> 
> - There was a more general way to solve the problem outlined by Simon.
> - The complexity doesn't pay for itself, esp. given how particular the
> problem it solves is.
> 
> What do y'all think?
> On Sat, Aug 4, 2018 at 10:35 AM Joachim Breitner
> <mail at joachim-breitner.de> wrote:
>> 
>> Hi,
>> 
>> we have disagreement here. Chris, would you steer us towards consensus?
>> 
>> Cheers,
>> Joachim
>> 
>> Am Samstag, den 23.06.2018, 23:19 -0400 schrieb Richard Eisenberg:
>>> Agreed. Beyond my posted technical reservations, I believe that a better solution is out there.
>>> 
>>> Richard
>>> 
>>>> On Jun 23, 2018, at 1:00 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Am Mittwoch, den 13.06.2018, 18:18 -0500 schrieb Christopher Allen:
>>>>> Bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski
>>>>> 
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/28
>>>>> 
>>>>> 
>>>>> I think we should accept this proposal. There are a couple of
>>>>> open questions, ambiguities, and potential downsides but the overall
>>>>> complexity of the proposal doesn't cause me great concern.
>>>> 
>>>> I agree with Simon that might not take the language in the direction we
>>>> want to take it.
>>>> 
>>>> In fact, if we had PatternSynonyms and ExplicitNamespaces back when
>>>> Haskell was first specified, we might not have the T(K) syntax at all,
>>>> and just a flat, explicit list of names, possibly requiring explicit
>>>> namespace qualifier to disambiguate? Things like deprecating exports
>>>> would have been easier then…
>>>> 
>>>> So while I follow the motivation of the proposal, and I don’t have
>>>> concrete other solution to offer, I am inclined to reject it: The
>>>> problem it is solving does not seem to be too urgent, and my gut
>>>> feeling says that there might be something better down the road.
>>>> 
>>>> 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
>> --
>> 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
> 
> 
> 
> -- 
> Chris Allen
> Currently working on http://haskellbook.com
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee