Re: convention around pattern synonyms

[Richard Eisenberg]

> On Dec 30, 2021, at 3:25 PM, Viktor Dukhovni  wrote:
> 
> Perhaps my assumption that TH types directly mirror the internal AST is
> not correct...  A recent user-visible change is in `ConP`

Many TH types are modeled after GHC-internal types, but this is just a matter 
of convenience, not necessity. (The necessity -- if we are to maintain feature 
parity in TH -- is that the same information is representable in both sets of 
types, not that the representations are the same.) So the convention I'm 
proposing here wouldn't affect TH.

Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: convention around pattern synonyms

[Viktor Dukhovni]

On Thu, Dec 30, 2021 at 04:46:29PM +, Richard Eisenberg wrote:

> I agree that this kind of backward-compatibility pattern synonym is
> good and shouldn't be prefixed with PS_.
> 
> But do you have a concrete example of this leakage of an internal GHC
> type via TH? While I can imagine this happening, I don't know of any
> examples in practice. Note that even enumeration types (like Role)
> have separate TH counterparts.

Perhaps my assumption that TH types directly mirror the internal AST is
not correct...  A recent user-visible change is in `ConP`

https://github.com/nikita-volkov/contravariant-extras/pull/9

-- 
Viktor.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: convention around pattern synonyms

[Richard Eisenberg]

I agree that this kind of backward-compatibility pattern synonym is good and 
shouldn't be prefixed with PS_.

But do you have a concrete example of this leakage of an internal GHC type via 
TH? While I can imagine this happening, I don't know of any examples in 
practice. Note that even enumeration types (like Role) have separate TH 
counterparts.

Richard

> On Dec 29, 2021, at 6:12 PM, Viktor Dukhovni  wrote:
> 
> Some "GHC-internal" types leak to users via TH, and their constructors
> occasionally pick up new fields, causing breakage downstream.  The extra
> field often has a sensible default (Nothing, [], ...) and it should be
> best practice to rename the constructor when adding the new field, while
> replacing the original constructor with a pattern synonym with the "old"
> signature.
> 
>   data Foo = ...
>| NewImprovedMkFoo X Y Z -- was MkFoo Y Z
> 
>   pattern MkFoo :: Foo
>   pattern MkFoo Y Z = NewImprovedMkFoo Nothing Y Z
> 
> When pattern synonyms are used to maintain a backwards-compatible API,
> there should of course be no special signalling to differentiate them
> from "real" constructors.
> 
> The boundary between "GHC-internal" and external may not always be
> obvious, some care is required to reduce leaking breakage via TH.
> 
> -- 
>   Viktor.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: convention around pattern synonyms

[Viktor Dukhovni]

Some "GHC-internal" types leak to users via TH, and their constructors
occasionally pick up new fields, causing breakage downstream.  The extra
field often has a sensible default (Nothing, [], ...) and it should be
best practice to rename the constructor when adding the new field, while
replacing the original constructor with a pattern synonym with the "old"
signature.

data Foo = ...
 | NewImprovedMkFoo X Y Z -- was MkFoo Y Z

pattern MkFoo :: Foo
pattern MkFoo Y Z = NewImprovedMkFoo Nothing Y Z

When pattern synonyms are used to maintain a backwards-compatible API,
there should of course be no special signalling to differentiate them
from "real" constructors.

The boundary between "GHC-internal" and external may not always be
obvious, some care is required to reduce leaking breakage via TH.

-- 
Viktor.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: convention around pattern synonyms

[Richard Eisenberg]

> On Dec 29, 2021, at 1:19 PM, Edward Kmett  wrote:
> 
> If this is just about GHC internals, then by all means carry on.

Yes, I should have clarified: this is just and solely about GHC internals! I 
have no designs on suggesting a wider convention like this. Indeed, both of the 
designs you describe below make great sense to use pattern synonyms for -- and 
without any herald that you are doing so. Within GHC, however, we now have a 
few cases where pattern synonyms are effectively behaving like or-patterns, 
which I find unexpected and confusing without a marker telling me Something 
Unusual is going on.

(Why? Because in both cases, the pattern synonym is really designed to act like 
a constructor. In the first case, if I understand correctly, the pattern 
synonym is just a renaming of an existing constructor, with no extra 
computation. In the second case, if I understand correctly, the pattern synonym 
captures what used to be a constructor. It's plausible that GHC will want to 
adopt either of these patterns at some point in the future, but we do not do 
either one today, and so I would say to address any change to my proposed 
coding convention when this happens.)

Richard

> 
> -Edward
> 
> On Wed, Dec 29, 2021 at 12:19 PM Edward Kmett  > wrote:
> Please no.
> 
> I use them to pun constructors between multiple types that will be in scope 
> at the same time, (e.g. when I have 8 Var constructors on different types in 
> scope between my core language term language and type language...) and often 
> overload them on classes. I can't write the pragma, and the PS_ destroys any 
> utiity I get from any common name.
> 
> I use them as a migration guide, when I add functionality. PS_ destroys that 
> usecase, but then COMPLETE pragmas are a hacky mess in their current state 
> and often simply can't be applied.
> 
> All the existing pattern constructors in the lens library would fail either 
> bar.
> 
> So I have to say, either of these would probably destroy every use of pattern 
> synonyms I use today.
> 
> -Edward
> 
> On Wed, Dec 29, 2021 at 11:55 AM Richard Eisenberg  > wrote:
> Hi devs,
> 
> Maybe I'm just old fashioned, but I've come to find pattern synonyms really 
> confusing. Because pattern synonyms will tend to appear next to proper data 
> constructors in code (and they look just like data constructors), when I see 
> one, I think it *is* a data constructor. This problem was motivated by a 
> recent MR that introduces a new pattern synonym 
> 
>  that caught me off-guard.
> 
> So, I'd like to propose the following convention: Every pattern synonym 
> satisfies one of the following two criteria:
> 1. The pattern synonym is a member of a set of synonyms/constructors that 
> expresses a view of a type. There would naturally be a `COMPLETE` pragma 
> including the set. `GHC.Types.Var.Inferred` is an example.
> 2. The pattern synonym begins with the prefix `PS_`.
> 
> In the end, I'd probably prefer just (2). With Inferred, for example, I've 
> been caught in the past trying to figure just what the constructors of 
> ArgFlag were (there seemed to be too many), until I realized what was going 
> on.
> 
> Pattern synonyms are useful abstractions. I like them. But my mental model of 
> a pattern match is that it matches the structure of the scrutinee and 
> performs no computation. Pattern synonyms violate both of these assumptions, 
> and so (as a reader) I like to know when to put these assumptions to the side.
> 
> Future IDE support that could, say, color pattern synonyms differently to 
> regular constructors would obviate the need for this convention.
> 
> What do others think here? `PS_` is ugly. I don't need something quite so 
> loud and ugly, but it's also easy to remember and recognize.
> 
> Thanks!
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> 

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: convention around pattern synonyms

[Edward Kmett]

If this is just about GHC internals, then by all means carry on.

-Edward

On Wed, Dec 29, 2021 at 12:19 PM Edward Kmett  wrote:

> Please no.
>
> I use them to pun constructors between multiple types that will be in
> scope at the same time, (e.g. when I have 8 Var constructors on different
> types in scope between my core language term language and type language...)
> and often overload them on classes. I can't write the pragma, and the PS_
> destroys any utiity I get from any common name.
>
> I use them as a migration guide, when I add functionality. PS_ destroys
> that usecase, but then COMPLETE pragmas are a hacky mess in their current
> state and often simply can't be applied.
>
> All the existing pattern constructors in the lens library would fail
> either bar.
>
> So I have to say, either of these would probably destroy *every* use of
> pattern synonyms I use today.
>
> -Edward
>
> On Wed, Dec 29, 2021 at 11:55 AM Richard Eisenberg 
> wrote:
>
>> Hi devs,
>>
>> Maybe I'm just old fashioned, but I've come to find pattern synonyms
>> really confusing. Because pattern synonyms will tend to appear next to
>> proper data constructors in code (and they look just like data
>> constructors), when I see one, I think it *is* a data constructor. This
>> problem was motivated by a recent MR that introduces a new pattern
>> synonym
>> 
>>  that
>> caught me off-guard.
>>
>> So, I'd like to propose the following convention: Every pattern synonym
>> satisfies one of the following two criteria:
>> 1. The pattern synonym is a member of a set of synonyms/constructors that
>> expresses a view of a type. There would naturally be a `COMPLETE` pragma
>> including the set. `GHC.Types.Var.Inferred` is an example.
>> 2. The pattern synonym begins with the prefix `PS_`.
>>
>> In the end, I'd probably prefer just (2). With Inferred, for example,
>> I've been caught in the past trying to figure just what the constructors of
>> ArgFlag were (there seemed to be too many), until I realized what was going
>> on.
>>
>> Pattern synonyms are useful abstractions. I like them. But my mental
>> model of a pattern match is that it matches the structure of the scrutinee
>> and performs no computation. Pattern synonyms violate both of these
>> assumptions, and so (as a reader) I like to know when to put these
>> assumptions to the side.
>>
>> Future IDE support that could, say, color pattern synonyms differently to
>> regular constructors would obviate the need for this convention.
>>
>> What do others think here? `PS_` is ugly. I don't need something quite so
>> loud and ugly, but it's also easy to remember and recognize.
>>
>> Thanks!
>> Richard
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: convention around pattern synonyms

[Edward Kmett]

Please no.

I use them to pun constructors between multiple types that will be in scope
at the same time, (e.g. when I have 8 Var constructors on different types
in scope between my core language term language and type language...) and
often overload them on classes. I can't write the pragma, and the PS_
destroys any utiity I get from any common name.

I use them as a migration guide, when I add functionality. PS_ destroys
that usecase, but then COMPLETE pragmas are a hacky mess in their current
state and often simply can't be applied.

All the existing pattern constructors in the lens library would fail either
bar.

So I have to say, either of these would probably destroy *every* use of
pattern synonyms I use today.

-Edward

On Wed, Dec 29, 2021 at 11:55 AM Richard Eisenberg 
wrote:

> Hi devs,
>
> Maybe I'm just old fashioned, but I've come to find pattern synonyms
> really confusing. Because pattern synonyms will tend to appear next to
> proper data constructors in code (and they look just like data
> constructors), when I see one, I think it *is* a data constructor. This
> problem was motivated by a recent MR that introduces a new pattern synonym
> 
>  that
> caught me off-guard.
>
> So, I'd like to propose the following convention: Every pattern synonym
> satisfies one of the following two criteria:
> 1. The pattern synonym is a member of a set of synonyms/constructors that
> expresses a view of a type. There would naturally be a `COMPLETE` pragma
> including the set. `GHC.Types.Var.Inferred` is an example.
> 2. The pattern synonym begins with the prefix `PS_`.
>
> In the end, I'd probably prefer just (2). With Inferred, for example, I've
> been caught in the past trying to figure just what the constructors of
> ArgFlag were (there seemed to be too many), until I realized what was going
> on.
>
> Pattern synonyms are useful abstractions. I like them. But my mental model
> of a pattern match is that it matches the structure of the scrutinee and
> performs no computation. Pattern synonyms violate both of these
> assumptions, and so (as a reader) I like to know when to put these
> assumptions to the side.
>
> Future IDE support that could, say, color pattern synonyms differently to
> regular constructors would obviate the need for this convention.
>
> What do others think here? `PS_` is ugly. I don't need something quite so
> loud and ugly, but it's also easy to remember and recognize.
>
> Thanks!
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs