RE: Implementing pattern synonym constructor signatures

[David Feuer]

3. Someone could write
pattern P x <- ... where  P :: ...  P x = ...
The pattern signature has to be the same as the constructor signature except 
for constraints, so it doesn't necessarily sound trivial to infer.


David FeuerWell-Typed, LLP
 Original message From: Simon Peyton Jones 
 Date: 1/15/18  6:36 PM  (GMT-05:00) To: David Feuer 
 Cc: ghc-devs@haskell.org Subject: RE: Implementing 
pattern synonym constructor signatures 
0. Parsing. I wasn't actually able to find the code that parses pattern 
synonyms. Can someone point me in the right direction?

Parser.y line 1356, production ‘patteron_synonym_decl’ looks plausible.

Currently we have
data HsPatSynDir id
  = Unidirectional
  | ImplicitBidirectional
  | ExplicitBidirectional (MatchGroup id (LHsExpr id))
so in the bidirectional case all we have a MatchGroup, built with 
mkPatSynMatchGroup.    To serve the proposal we need an optional signature in 
there too.

1. When there is a constructor signature, it needs to be used for the 
construction function instead of the pattern signature. Can someone give point 
me in the right direction about how to do this?

TcPatSyn.tcPatSynBuilderBind is a good place to start.

2. When there is a constructor signature but no pattern signature, what should 
we do? I think "give up" sounds okay for now.

I don’t understand.  Can you give an example?

Simon
From: David Feuer [mailto:da...@well-typed.com]
Sent: 15 January 2018 19:11
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org
Subject: Implementing pattern synonym constructor signatures

Over the past week I've started digging into the code that implements pattern 
synonyms with an eye toward implementing the pattern synonym construction 
function signature proposal. I think I understand a decent amount of what's 
going on most places. However, I don't understand enough about type checking to 
have any idea about what needs to change where or how. There are several things 
that need to be addressed:

0. Parsing. I wasn't actually able to find the code that parses pattern 
synonyms. Can someone point me in the right direction?

1. When there is a constructor signature, it needs to be used for the 
construction function instead of the pattern signature. Can someone give point 
me in the right direction about how to do this?

2. When there is a constructor signature but no pattern signature, what should 
we do? I think "give up" sounds okay for now.

3. A pattern synonym without a constructor signature needs to be treated as it 
is today, so the machinery for matching things up needs to remain available.

David Feuer
Well-Typed, LLP
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Implementing pattern synonym constructor signatures

[David Feuer]

Never mind about parsing. It looks like the parser is already doing what it 
needs to do and I need to look to RdrHsSyn.hs.


David FeuerWell-Typed, LLP
 Original message From: David Feuer  
Date: 1/15/18  2:10 PM  (GMT-05:00) To: Simon Peyton Jones 
 Cc: ghc-devs@haskell.org Subject: Implementing pattern 
synonym constructor signatures 
Over the past week I've started digging into the code that implements pattern 
synonyms with an eye toward implementing the pattern synonym construction 
function signature proposal. I think I understand a decent amount of what's 
going on most places. However, I don't understand enough about type checking to 
have any idea about what needs to change where or how. There are several things 
that need to be addressed:
0. Parsing. I wasn't actually able to find the code that parses pattern 
synonyms. Can someone point me in the right direction?
1. When there is a constructor signature, it needs to be used for the 
construction function instead of the pattern signature. Can someone give point 
me in the right direction about how to do this?
2. When there is a constructor signature but no pattern signature, what should 
we do? I think "give up" sounds okay for now.
3. A pattern synonym without a constructor signature needs to be treated as it 
is today, so the machinery for matching things up needs to remain available.
David FeuerWell-Typed, LLP___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Implementing pattern synonym constructor signatures

[Simon Peyton Jones via ghc-devs]

0. Parsing. I wasn't actually able to find the code that parses pattern 
synonyms. Can someone point me in the right direction?

Parser.y line 1356, production ‘patteron_synonym_decl’ looks plausible.

Currently we have
data HsPatSynDir id
  = Unidirectional
  | ImplicitBidirectional
  | ExplicitBidirectional (MatchGroup id (LHsExpr id))
so in the bidirectional case all we have a MatchGroup, built with 
mkPatSynMatchGroup.To serve the proposal we need an optional signature in 
there too.

1. When there is a constructor signature, it needs to be used for the 
construction function instead of the pattern signature. Can someone give point 
me in the right direction about how to do this?

TcPatSyn.tcPatSynBuilderBind is a good place to start.

2. When there is a constructor signature but no pattern signature, what should 
we do? I think "give up" sounds okay for now.

I don’t understand.  Can you give an example?

Simon
From: David Feuer [mailto:da...@well-typed.com]
Sent: 15 January 2018 19:11
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org
Subject: Implementing pattern synonym constructor signatures

Over the past week I've started digging into the code that implements pattern 
synonyms with an eye toward implementing the pattern synonym construction 
function signature proposal. I think I understand a decent amount of what's 
going on most places. However, I don't understand enough about type checking to 
have any idea about what needs to change where or how. There are several things 
that need to be addressed:

0. Parsing. I wasn't actually able to find the code that parses pattern 
synonyms. Can someone point me in the right direction?

1. When there is a constructor signature, it needs to be used for the 
construction function instead of the pattern signature. Can someone give point 
me in the right direction about how to do this?

2. When there is a constructor signature but no pattern signature, what should 
we do? I think "give up" sounds okay for now.

3. A pattern synonym without a constructor signature needs to be treated as it 
is today, so the machinery for matching things up needs to remain available.

David Feuer
Well-Typed, LLP
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Implementing pattern synonym constructor signatures

[David Feuer]

See the accepted proposal:  
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0005-bidir-constr-sigs.rst


David FeuerWell-Typed, LLP
 Original message From: Matthew Pickering 
 Date: 1/15/18  3:27 PM  (GMT-05:00) To: David 
Feuer  Cc: Simon Peyton Jones , 
GHC developers  Subject: Re: Implementing pattern synonym 
constructor signatures 
What is a constructor signature? Where is this specified?

On Mon, Jan 15, 2018 at 7:10 PM, David Feuer  wrote:
> Over the past week I've started digging into the code that implements
> pattern synonyms with an eye toward implementing the pattern synonym
> construction function signature proposal. I think I understand a decent
> amount of what's going on most places. However, I don't understand enough
> about type checking to have any idea about what needs to change where or
> how. There are several things that need to be addressed:
>
> 0. Parsing. I wasn't actually able to find the code that parses pattern
> synonyms. Can someone point me in the right direction?
>
> 1. When there is a constructor signature, it needs to be used for the
> construction function instead of the pattern signature. Can someone give
> point me in the right direction about how to do this?
>
> 2. When there is a constructor signature but no pattern signature, what
> should we do? I think "give up" sounds okay for now.
>
> 3. A pattern synonym without a constructor signature needs to be treated as
> it is today, so the machinery for matching things up needs to remain
> available.
>
> David Feuer
> Well-Typed, LLP
>
> ___
> 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: Implementing pattern synonym constructor signatures

[Matthew Pickering]

What is a constructor signature? Where is this specified?

On Mon, Jan 15, 2018 at 7:10 PM, David Feuer  wrote:
> Over the past week I've started digging into the code that implements
> pattern synonyms with an eye toward implementing the pattern synonym
> construction function signature proposal. I think I understand a decent
> amount of what's going on most places. However, I don't understand enough
> about type checking to have any idea about what needs to change where or
> how. There are several things that need to be addressed:
>
> 0. Parsing. I wasn't actually able to find the code that parses pattern
> synonyms. Can someone point me in the right direction?
>
> 1. When there is a constructor signature, it needs to be used for the
> construction function instead of the pattern signature. Can someone give
> point me in the right direction about how to do this?
>
> 2. When there is a constructor signature but no pattern signature, what
> should we do? I think "give up" sounds okay for now.
>
> 3. A pattern synonym without a constructor signature needs to be treated as
> it is today, so the machinery for matching things up needs to remain
> available.
>
> David Feuer
> Well-Typed, LLP
>
> ___
> 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

Implementing pattern synonym constructor signatures

[David Feuer]

Over the past week I've started digging into the code that implements pattern 
synonyms with an eye toward implementing the pattern synonym construction 
function signature proposal. I think I understand a decent amount of what's 
going on most places. However, I don't understand enough about type checking to 
have any idea about what needs to change where or how. There are several things 
that need to be addressed:
0. Parsing. I wasn't actually able to find the code that parses pattern 
synonyms. Can someone point me in the right direction?
1. When there is a constructor signature, it needs to be used for the 
construction function instead of the pattern signature. Can someone give point 
me in the right direction about how to do this?
2. When there is a constructor signature but no pattern signature, what should 
we do? I think "give up" sounds okay for now.
3. A pattern synonym without a constructor signature needs to be treated as it 
is today, so the machinery for matching things up needs to remain available.
David FeuerWell-Typed, LLP___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Release policies

[Boespflug, Mathieu]

[replying to ghc-devops-group@, which I assume based on your email's
content is the mailing list you intended.]

Hi Simon,

feedback from downstream consumers of Cabal metadata (e.g. build tool
authors) will be particularly useful for the discussion here. Here are my
thoughts as a bystander.

It's worth trying to identify what problems came up during the integer-gmp
incident in Trac #14558:

* GHC 8.2.1 shipped with integer-gmp-1.0.1.0 but the release notes said
otherwise.
* GHC 8.2.1 shipped with Cabal-2.0.0.2, but specifically claimed in the
release notes that cabal-install-1.24 (and by implication any other build
tool based on Cabal-the-library version 1.24) was supported: "GHC 8.2 only
works with cabal-install version 1.24 or later. Please upgrade if you have
an older version of cabal-install."
* GHC 8.2.2 also claimed Cabal-1.24 support.
* GHC 8.2.1 was released in July 2017 with Cabal-2.0.0.2, a brand new major
release with breaking changes to the metadata format, without much lead
time for downstream tooling authors (like Stack) to adapt.
* But actually if we look at their respective release notes, GHC 8.2.1 was
relased in July 2017, even though the Cabal website claims that
Cabal-2.0.0.2 was released in August 2017 (see
https://www.haskell.org/cabal/download.html). So it looks like GHC didn't
just not give enough lead time about an upstream dependency it shipped
with, it shipped with an unreleased version of Cabal!
* Libraries that ship with GHC are usually also uploaded to Hackage, to
make the documentation easily accessible, but integer-gmp-1.0.1.0 was not
uploaded to Hackage until 4 months after the release.
* The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage differed from
the metadata that was actually in the source tarball of GHC-8.2.1 and
GHC-8.2.2.
* The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage included
Cabal-2.0 specific syntactic sugar, making the metadata unreadable using
any tooling that did not link against the Cabal-2.0.0.2 library (or any
later version).
* It so happened that one particular version of one particular downstream
build tool, Stack, had a bug, compounding the bad effects of the previous
point. But a new release has now been made, and in any case that's not a
problem for GHC to solve. So let's keep that out of the discussion here.

So I suggest we discuss ways to eliminate or reduce the likelihood of any
of the above problems from occurring again. Here are some ideas:

* GHC should never under any circumstance ship with an unreleased version
of any independently maintained dependency. Cabal is one such dependency.
This should hold true for anything else. We could just add that policy to
the Release Policy.
* Stronger still, GHC should not switch to a new major release of a
dependency at any time during feature freeze ahead of a release. E.g. if
Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair
game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet.
* The 3-release backwards compat rule should apply in all circumstances.
That means major version bumps of any library GHC ships with, including
base, should not imply any breaking change in the API's of any such library.
* GHC does have control over reinstallable packages (like text and
bytestring): GHC need not ship with the latest versions of these, if indeed
they introduce breaking changes that would contravene the 3-release policy.
* Note: today, users are effectively tied to whatever version of the
packages ships with GHC (i.e. the "reinstallable" bit is problematic today
for various technical reasons). That's why a breaking change in bytestring
is technically a breaking change in GHC.
* The current release policy covers API stability, but what about metadata?
In the extreme, we could say a 3-release policy applies to metadata too.
Meaning, all metadata shipping with GHC now and in the next 2 releases
should be parseable by today's version of Cabal and downstream tooling. Is
such a long lead time necessary? That's for build tool authors to say, and
a point to negotiate with GHC devs.
* Because there are far fewer consumers of metadata than consumers of say
base, I think shorter lead time is reasonable. At the other extreme, it
could even be just the few months during feature freeze.
* The release notes bugs mentioned above and the lack of consistent upload
to Hackage are a symptom of lack of release automation, I suspect. That's
how to fix it, but we could also spell out in the Release Policy that GHC
libraries should all be on Hackage from the day of release.

Finally, a question for discussion:

* Hackage allows revising the metadata of an uploaded package even without
changing the version number. This happens routinely on Hackage today by the
Hackage trustees. Should this be permitted for packages whose release is
completely tied to that of GHC itself (like integer-gmp)?

Best,

Mathieu


On 13 December 2017 at 17:43, Simon Peyton Jones via ghc-devs <

cvs-ghc mailing list dead?

[Steven Shaw]

This email list  appears
to be dead but I figured it might forward to ghc-devs
. Just
checking...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs