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: What's the benefit of taking "do" blocks apart? Is there a way to turn that off?

[Joachim Breitner]

Hi Gergo,

Am Dienstag, dem 28.12.2021 um 15:57 + schrieb Erdi, Gergo via ghc-
devs:
> PUBLIC

phew

> I’m seeing ‘do’ blocks getting taking apart into top-level
> definitions, so e.g.
>  
> main = do
>   some complicated expression 1
>   some complicated expression 2
>  
> is compiled into
>  
> sat_sKv = some complicated expression 1
> sat_sKw = \_ -> some complicated expression 2
> main = bindIO sat_sKv sat_sKw
>  
> This seems to happen regardless of any common subexpressions, i.e. it
> is not the case that sat_sKv or sat_sKw are used anywhere else.
>  
> What is the intended benefit of this floating-out? Is there a
> particular Core-to-Core pass that causes this? Is it possible to turn
> it off?


didn’t investigate deeper (maybe if you provide a small example I
would), but just from looking at this:

 * It is generally preferable to turn local lambda expressions
   into top-level functions. This way, instead of dynamically
   allocating a FUN heap object, it’s just a static function.

 * sat_sKv is an IO expression? Then it is actually a function in a way
   (taking the “State token” as an argument). So the above applies.

 * I think this is the FloatOut pass. You can turn it out using
   -fno-full-laziness. Not sure if some others passes might 
   do similar things, though.

Cheers,
Joachim


-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/

___
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

convention around pattern synonyms

[Richard Eisenberg]

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