2 patches for repository http://darcs.net/screened:

patch 10c256d9b17879d7a7a890cb689f43e7403a84d2
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Sep  3 14:51:18 CEST 2019
  * darcs.cabal: sort extensions except NoMonoLocalBinds

patch d0c2ac71d42f609d3a89b75bc5bec919563853c4
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Sep  3 14:45:54 CEST 2019
  * clean up language extensions
  
  This removes AllowAmbiguousTypes (unneeded) and replaces
  ExistentialQuantification and GADTSyntax with GADTs. It also adds
  - DefaultSignatures
  - DeriveDataTypeable
  - DeriveFunctor
  - EmptyDataDecls
  - GeneralizedNewtypeDeriving
  - RecordWildCards
  - TupleSections
  and also removes any (now) redundant per-module extensions. Here is a list
  of the remaining extensions that are enabled on a per-module basis:
  - CPP
  - ForeignFunctionInterface
  - MultiParamTypeClasses
  - NamedFieldPuns
  - OverloadedStrings
  - PatternSynonyms
  - UndecidableInstances
  - UndecidableSuperClasses
  - ViewPatterns

Attachments

• darcs_cabal_-sort-extensions-except-nomonolocalbinds.dpatch
• patch-preview.txt
• unnamed

On 03/09/2019 16:45, Ben Franksen wrote:

>   This removes AllowAmbiguousTypes (unneeded) and replaces

I'm surprised this is unneeded, given that it often goes closely with
the use of TypeApplications. Even if we aren't using it right now, I
would prefer we have it available automatically. I'd certainly expect it
to be needed in the test harness as I remember making changes that used
it when getting rid of undefineds.

>   - PatternSynonyms
>   - ViewPatterns

Shall we make these available globally too?

>>   This removes AllowAmbiguousTypes (unneeded) and replaces
> 
> I'm surprised this is unneeded, given that it often goes closely with
> the use of TypeApplications. Even if we aren't using it right now, I
> would prefer we have it available automatically. I'd certainly expect it
> to be needed in the test harness as I remember making changes that used
> it when getting rid of undefineds.

I haven't removed it for darcs-test (if it was in there, I haven't
checked). I'd prefer not to add it to the library without good cause. We
can add it any time if it turns out to be needed and I promise I won't
raise a fuss ;-)

Note that AllowAmbiguousTypes is a lot weaker than it sounds, it just
moves the error from the definition site to the use site (but you
probably new that).

>>   - PatternSynonyms
>>   - ViewPatterns
> 
> Shall we make these available globally too?

I find ViewPatterns particularly ugly and hard to read, so I would
rather get rid of them than sanction their use.

PatternSynonyms are okay, I haven't personally used them in anger yet,
so I wasn't sure, but if you are, I will add them to the list.

> I find ViewPatterns particularly ugly and hard to read, so I would
> rather get rid of them than sanction their use.

Oops, sorry. I was confused. I meant the extension where you say

  case function -> .. of

I rember these being used in the old mangling code. I forgot how they
are named and I think they aren't used anymore in darcs.

ViewPatterns are the thing where you define a data type like thing and
use it as if it were the real data type, right? These are okay, too.

Sorry. Ignore last message.

>> I find ViewPatterns particularly ugly and hard to read, so I would
>> rather get rid of them than sanction their use.
> 
> Oops, sorry. I was confused. I meant the extension where you say
> 
>   case function -> .. of

I wasn't confused. These are view patterns. And my opinion about them
stands.

> I rember these being used in the old mangling code. I forgot how they
> are named and I think they aren't used anymore in darcs.

They are still used in several places.

> ViewPatterns are the thing where you define a data type like thing and
> use it as if it were the real data type, right? These are okay, too.

These are PatternSynonyms which are nice.

> PatternSynonyms are okay, I haven't personally used them in anger yet,
> so I wasn't sure, but if you are, I will add them to the list.

I found that they aren't compatible as 'pattern' is now a keyword. So I
can't enable them globally.

Can I screen the patch as is and we sort out the pattern extensions in
follow-up patches?

> I found that they aren't compatible as 'pattern' is now a keyword. So I
> can't enable them globally.
> 
> Can I screen the patch as is and we sort out the pattern extensions in
> follow-up patches?

Yep.

> I found that they aren't compatible as 'pattern' is now a keyword. So I
> can't enable them globally.
> 
> Can I screen the patch as is and we sort out the pattern extensions in
> follow-up patches?

Yep.

>>> I find ViewPatterns particularly ugly and hard to read, so I would
>>> rather get rid of them than sanction their use.
>>
>> Oops, sorry. I was confused. I meant the extension where you say
>>
>>   case function -> .. of
> 
> I wasn't confused. These are view patterns. And my opinion about them
> stands.

I didn't know you could use them in the scrutinee of a case expression.
In that situation you'd just apply the function directly.

I thought they go in the patterns, like in this function definition:

-- | Convert a 'Contexted' patch into a plain 'FL' with the patch at the
end.
ctxToFL :: Contexted p wX -> Sealed (FL p wX)
ctxToFL (ctxView -> Sealed (ps :> p)) = Sealed (ps +>+ p :>: NilFL)

Now that PatternSynonyms exist it might be that they provide a nicer
alternative, I'm not sure without some experiments. Personally I'm fine
with ViewPatterns.

>>>   case function -> .. of
> 
> I didn't know you could use them in the scrutinee of a case expression.
> In that situation you'd just apply the function directly.

You are right. That's what I meant. Sorry.

> I thought they go in the patterns, like in this function definition:
> 
> -- | Convert a 'Contexted' patch into a plain 'FL' with the patch at the
> end.
> ctxToFL :: Contexted p wX -> Sealed (FL p wX)
> ctxToFL (ctxView -> Sealed (ps :> p)) = Sealed (ps +>+ p :>: NilFL)

Yes.

> Now that PatternSynonyms exist it might be that they provide a nicer
> alternative, I'm not sure without some experiments. Personally I'm fine
> with ViewPatterns.

It's just that whenever I see them in code something knots in my brain
and I can't get myself to understand what they mean, probably due to the
inversed arrow. Somehow something in me doesn't want to accept this
syntax... OTOH they are a nice light-weight alternative to defining a
pattern synonym. So I can't decide whether to love or to hate them.
Anyway, I am not going to remove any of them or propose again that we do
so. Perhaps I'll get used to them some day.

Accepting this. We can sort out any other extensions in followups if needed.