darcs

Patch 1910 darcs.cabal: sort extensions except NoMo... (and 1 more)

Title darcs.cabal: sort extensions except NoMo... (and 1 more)
Superseder Nosy List bf
Related Issues
Status accepted Assigned To
Milestone

Created on 2019-09-03.15:45:11 by bf, last changed 2019-09-23.11:53:36 by ganesh.

Files
File name Status Uploaded Type Edit Remove
darcs_cabal_-sort-extensions-except-nomonolocalbinds.dpatch bf, 2019-09-03.15:45:11 application/x-darcs-patch
patch-preview.txt bf, 2019-09-03.15:45:11 text/x-darcs-patch
unnamed bf, 2019-09-03.15:45:11 text/plain
See mailing list archives for discussion on individual patches.
Messages
msg21340 (view) Author: bf Date: 2019-09-03.15:45:11
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
msg21341 (view) Author: ganesh Date: 2019-09-03.16:05:11
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?
msg21345 (view) Author: bf Date: 2019-09-03.17:44:54
>>   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.
msg21346 (view) Author: bf Date: 2019-09-03.17:51:13
> 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.
msg21348 (view) Author: bf Date: 2019-09-03.17:58:14
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.
msg21349 (view) Author: bf Date: 2019-09-03.18:02:58
> 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?
msg21351 (view) Author: ganesh Date: 2019-09-03.18:08:35
> 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.
msg21352 (view) Author: ganesh Date: 2019-09-03.18:08:38
> 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.
msg21353 (view) Author: ganesh Date: 2019-09-03.18:14:03
>>> 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.
msg21357 (view) Author: bf Date: 2019-09-03.19:41:14
>>>   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.
msg21450 (view) Author: ganesh Date: 2019-09-18.19:54:57
Accepting this. We can sort out any other extensions in followups if needed.
History
Date User Action Args
2019-09-03 15:45:11bfcreate
2019-09-03 16:05:11ganeshsetmessages: + msg21341
2019-09-03 17:44:55bfsetmessages: + msg21345
2019-09-03 17:51:13bfsetmessages: + msg21346
2019-09-03 17:58:14bfsetmessages: + msg21348
2019-09-03 18:02:58bfsetmessages: + msg21349
2019-09-03 18:08:35ganeshsetmessages: + msg21351
2019-09-03 18:08:38ganeshsetmessages: + msg21352
2019-09-03 18:14:03ganeshsetmessages: + msg21353
2019-09-03 19:29:38bfsetstatus: needs-screening -> needs-review
2019-09-03 19:41:14bfsetmessages: + msg21357
2019-09-18 19:54:57ganeshsetstatus: needs-review -> accepted-pending-tests
messages: + msg21450
2019-09-23 11:53:36ganeshsetstatus: accepted-pending-tests -> accepted