Re: Deriving mechanisms in GHC

[Ryan Scott]

(Disclaimer: I have never used hs-to-coq before, so everything below is
merely an educated guess.)

Looking at the source code for hs-to-coq, I see this [1]:

addDerivedInstances :: GhcMonad m => TypecheckedModule -> m
> TypecheckedModule
> addDerivedInstances tcm = do
> let Just (hsgroup, a, b, c) = tm_renamed_source tcm
>
> (_gbl_env, inst_infos, _rn_binds) <- initTcHack tcm $ do
> let tcg_env = fst (tm_internals_ tcm)
> tcg_env_hack = tcg_env { tcg_mod = fakeDerivingMod,
> tcg_semantic_mod = fakeDerivingMod }
> -- Set the module to make it look like we are in GHCi
> -- so that GHC will allow us to re-typecheck existing
> instances
> setGblEnv tcg_env_hack $
> #if __GLASGOW_HASKELL__ >= 810
> tcInstDeclsDeriv [] (hs_derivds hsgroup)
> #else
> tcInstDeclsDeriv [] (hs_tyclds hsgroup >>= group_tyclds)
> (hs_derivds hsgroup)
> #endif


If I understand this code correctly, it is using the GHC API to produce
deriving-generated code and typecheck it, which seems reasonable. The part
that confuses me is the #if __GLASGOW_HASKELL__ >= 810 bit. Prior to GHC
8.10, this code would obtain deriving-related information from two places:

   1. The deriving clauses of data type declarations (i.e., the hs_tyclds)
   2. Standalone deriving declarations (i.e., the hs_derivds)

In GHC 8.10 and later, however, the code only obtains deriving-related
information from standalone deriving declarations. This means that you'll
completely skip over any derived instances that arise from deriving
clauses, which is likely the source of the trouble you're encountering.

In order to give advice on what you *should* be doing, let me briefly
describe why the type of tcInstDeclsDeriv changed in GHC 8.10. The commit
that changed tcInstDeclsDeriv is [2]. Prior to that commit, tcInstDeclsDeriv
would obtain information related to deriving clauses via its first two
arguments:

   1. The first argument (of type [DerivInfo]) contained all of the
   deriving clauses for data family instances. (Note that hs-to-coq uses an
   empty list, so this means that hs-to-coq will always skip over data
   family instances, before or after GHC 8.10. I'm not sure if this should be
   considered as a separate bug.)
   2. The second argument (of type [LTyClDecl GhcRn]) contained all of the
   data type definitions, which might have deriving clauses attached to them.

The linked commit changes things so that *all* deriving clause–related
information (both for ordinary data types as well as data family instances)
is passed as a [DerivInfo] list. This means that hs-to-coq needs to produce
those DerivInfo values somehow. As inspiration, you might want to look at
how GHC calls tcInstDeclsDeriv here [3]. GHC first calls the
tcTyAndClassDecls function to produce the DerivInfo values, and then it
passes the DerivInfo values to tcInstDeclsDeriv. I would hope that
something similar would work for hs-to-coq.

Best,

Ryan
-
[1]
https://github.com/plclub/hs-to-coq/blob/03e823972fc7c5f85a300e554c691563f89a3e5f/src/lib/HsToCoq/Util/GHC/Deriving.hs#L50-L64
[2]
https://gitlab.haskell.org/ghc/ghc/-/commit/679427f878e50ba5a9981bac4c2f9c76f4de3c3c#4c1af4850cb90ab2963edb06b69b57e87ccdf9c1
[3]
https://gitlab.haskell.org/ghc/ghc/-/blob/bc1d435e399d8376b4e33d5d936424ff76cb686a/compiler/GHC/Tc/Module.hs#L1704-L1723
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Call for Lightning Talks: Haskell Implementors' Workshop 2023

[Ryan Scott]

ACM SIGPLAN Haskell Implementors' Workshop
https://icfp23.sigplan.org/home/hiw-2023
Seattle, Washington, United States, September 4, 2023

Co-located with ICFP 2023
https://icfp23.sigplan.org/

---

The 15th Haskell Implementors' Workshop is to be held alongside ICFP
2023 this year in Seattle. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure to share their work and to discuss future
directions and collaborations with others.

We have a number of slots for lightning talks. Lightning talks will be ~7
minutes and are scheduled on the day of the workshop. Suggested topics for
lightning talks are to present a single idea, a work-in-progress project, a
problem to intrigue and perplex Haskell implementors, or simply to ask for
feedback and collaborators.

Lightning talks are proposed by submitting a title and an abstract.
Submissions will not be part of the peer-review process. Notification of
acceptance will be continuous until slots are full. Accepted lightning
talks will be posted on the workshop’s website.

Submissions should be made via this Google form:
https://forms.gle/2jGceompwNghbRQR9

Accepted lightning talks will be posted on the workshop’s website.

Scope and target audience
-

The Implementors' Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related tool,
or even propose future lines of Haskell development. Members of the
wider Haskell community are encouraged to attend the workshop -- we need
your feedback to keep the Haskell ecosystem thriving. Students working
with Haskell are especially encouraged to share their work.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

* Compilation techniques
* Language features and extensions
* Type system implementation
* Concurrency and parallelism: language design and implementation
* Performance, optimisation and benchmarking
* Virtual machines and run-time systems
* Libraries and tools for development or deployment

Contact
---

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

Re: Call for Talks: Haskell Implementors' Workshop 2023 (deadline extension)

[Ryan Scott]

Apologies, that should read *July* 16, not June 16, for the submission
deadline at the top of the email. (The body of the email contains the
correct date.)

Best,

Ryan

On Mon, Jul 10, 2023 at 6:34 PM Ryan Scott  wrote:

> TL;DR: The submission deadline for the 2023 Haskell Implementors' Workshop
> has been extended to June 16.
>
> ==
>
> ACM SIGPLAN Haskell Implementors' Workshop
> https://icfp23.sigplan.org/home/hiw-2023
> Seattle, Washington, United States, September 4, 2023
>
> Co-located with ICFP 2023
> https://icfp23.sigplan.org/
>
> Important dates
> ---
>
> Deadline: July 16, 2023 (AoE) (extended)
> Notification: August 4, 2023
> Workshop: September 4, 2023
>
> The 15th Haskell Implementors' Workshop is to be held alongside ICFP
> 2023 this year in Seattle. It is a forum for people involved in the
> design and development of Haskell implementations, tools, libraries,
> and supporting infrastructure to share their work and to discuss future
> directions and collaborations with others.
>
> Talks and/or demos are proposed by submitting an abstract, and
> selected by a small program committee. There will be no published
> proceedings. The workshop will be informal and interactive, with
> open spaces in the timetable and room for ad-hoc discussion, demos,
> and short lightning talks.
>
> Scope and target audience
> -
>
> It is important to distinguish the Haskell Implementors' Workshop from
> the Haskell Symposium which is also co-located with ICFP 2023. The
> Haskell Symposium is for the publication of Haskell-related research. In
> contrast, the Haskell Implementors' Workshop will have no proceedings --
> although we will aim to make talk videos, slides, and presented data
> available with the consent of the speakers.
>
> The Implementors' Workshop is an ideal place to describe a Haskell
> extension, describe works-in-progress, demo a new Haskell-related tool,
> or even propose future lines of Haskell development. Members of the
> wider Haskell community are encouraged to attend the workshop -- we need
> your feedback to keep the Haskell ecosystem thriving. Students working
> with Haskell are especially encouraged to share their work.
>
> The scope covers any of the following topics. There may be some topics
> that people feel we've missed, so by all means submit a proposal even if
> it doesn't fit exactly into one of these buckets:
>
> * Compilation techniques
> * Language features and extensions
> * Type system implementation
> * Concurrency and parallelism: language design and implementation
> * Performance, optimisation and benchmarking
> * Virtual machines and run-time systems
> * Libraries and tools for development or deployment
>
> Talks
> -
>
> We invite proposals from potential speakers for talks and
> demonstrations. We are aiming for 20-minute talks with 5 minutes for
> questions and changeovers. We want to hear from people writing
> compilers, tools, or libraries, people with cool ideas for directions in
> which we should take the platform, proposals for new features to be
> implemented, and half-baked crazy ideas. Please submit a talk title and
> abstract of no more than 300 words.
>
> Submissions can be made via HotCRP at https://icfp-hiw23.hotcrp.com
> until July 16 (anywhere on earth).
>
> We will also have a lightning talks session. These have been very well
> received in recent years, and we aim to increase the time available to
> them. Lightning talks should be ~7mins and are scheduled on the day of the
> workshop. Suggested topics for lightning talks are to present a single
> idea, a work-in-progress project, a problem to intrigue and perplex
> Haskell implementors, or simply to ask for feedback and collaborators.
>
> Program Committee
> -----
>
> * Gergő Érdi (Standard Chartered Bank)
> * Sebastian Graf (Karlsruhe Institute of Technology)
> * Wen Kokke (University of Strathclyde)
> * Ryan Scott (Galois, Inc.)
> * Rebecca Skinner (Mercury)
> * Li-yao Xia (University of Edinburgh)
>
> Contact
> ---
>
> * Ryan Scott 
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Call for Talks: Haskell Implementors' Workshop 2023 (deadline extension)

[Ryan Scott]

TL;DR: The submission deadline for the 2023 Haskell Implementors' Workshop
has been extended to June 16.

==

ACM SIGPLAN Haskell Implementors' Workshop
https://icfp23.sigplan.org/home/hiw-2023
Seattle, Washington, United States, September 4, 2023

Co-located with ICFP 2023
https://icfp23.sigplan.org/

Important dates
---

Deadline: July 16, 2023 (AoE) (extended)
Notification: August 4, 2023
Workshop: September 4, 2023

The 15th Haskell Implementors' Workshop is to be held alongside ICFP
2023 this year in Seattle. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure to share their work and to discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings. The workshop will be informal and interactive, with
open spaces in the timetable and room for ad-hoc discussion, demos,
and short lightning talks.

Scope and target audience
-

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2023. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides, and presented data
available with the consent of the speakers.

The Implementors' Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related tool,
or even propose future lines of Haskell development. Members of the
wider Haskell community are encouraged to attend the workshop -- we need
your feedback to keep the Haskell ecosystem thriving. Students working
with Haskell are especially encouraged to share their work.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

* Compilation techniques
* Language features and extensions
* Type system implementation
* Concurrency and parallelism: language design and implementation
* Performance, optimisation and benchmarking
* Virtual machines and run-time systems
* Libraries and tools for development or deployment

Talks
-

We invite proposals from potential speakers for talks and
demonstrations. We are aiming for 20-minute talks with 5 minutes for
questions and changeovers. We want to hear from people writing
compilers, tools, or libraries, people with cool ideas for directions in
which we should take the platform, proposals for new features to be
implemented, and half-baked crazy ideas. Please submit a talk title and
abstract of no more than 300 words.

Submissions can be made via HotCRP at https://icfp-hiw23.hotcrp.com
until July 16 (anywhere on earth).

We will also have a lightning talks session. These have been very well
received in recent years, and we aim to increase the time available to
them. Lightning talks should be ~7mins and are scheduled on the day of the
workshop. Suggested topics for lightning talks are to present a single
idea, a work-in-progress project, a problem to intrigue and perplex
Haskell implementors, or simply to ask for feedback and collaborators.

Program Committee
-

* Gergő Érdi (Standard Chartered Bank)
* Sebastian Graf (Karlsruhe Institute of Technology)
* Wen Kokke (University of Strathclyde)
* Ryan Scott (Galois, Inc.)
* Rebecca Skinner (Mercury)
* Li-yao Xia (University of Edinburgh)

Contact
---

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

Re: Final Call for Talks: Haskell Implementors' Workshop 2023

[Ryan Scott]

One correction to the previous email: the link should be
https://icfp-hiw2023.hotcrp.com (with a hyphen), not
https://icfphiw23.hotcrp.com. (The former matches what is listed on the HIW
website at https://icfp23.sigplan.org/home/hiw-2023.) I apologise for any
confusion this may have caused.

Best,

Ryan

On Mon, Jun 5, 2023 at 7:47 AM Ryan Scott  wrote:

> The 2023 Haskell Implementors' Workshop deadline is just under one month
> away. We are looking forward to your talk submissions.
>
> Best,
>
> Ryan
>
> ==
>
> ACM SIGPLAN Haskell Implementors' Workshop
> https://icfp23.sigplan.org/home/hiw-2023
> Seattle, Washington, United States, September 4, 2023
>
> Co-located with ICFP 2023
> https://icfp23.sigplan.org/
>
> Important dates
> ---
>
> Deadline: July 4, 2023 (AoE)
> Notification: August 4, 2023
> Workshop: September 4, 2023
>
> The 15th Haskell Implementors' Workshop is to be held alongside ICFP
> 2023 this year in Seattle. It is a forum for people involved in the
> design and development of Haskell implementations, tools, libraries,
> and supporting infrastructure to share their work and to discuss future
> directions and collaborations with others.
>
> Talks and/or demos are proposed by submitting an abstract, and
> selected by a small program committee. There will be no published
> proceedings. The workshop will be informal and interactive, with
> open spaces in the timetable and room for ad-hoc discussion, demos,
> and short lightning talks.
>
> Scope and target audience
> -
>
> It is important to distinguish the Haskell Implementors' Workshop from
> the Haskell Symposium which is also co-located with ICFP 2023. The
> Haskell Symposium is for the publication of Haskell-related research. In
> contrast, the Haskell Implementors' Workshop will have no proceedings --
> although we will aim to make talk videos, slides, and presented data
> available with the consent of the speakers.
>
> The Implementors' Workshop is an ideal place to describe a Haskell
> extension, describe works-in-progress, demo a new Haskell-related tool,
> or even propose future lines of Haskell development. Members of the
> wider Haskell community are encouraged to attend the workshop -- we need
> your feedback to keep the Haskell ecosystem thriving. Students working
> with Haskell are especially encouraged to share their work.
>
> The scope covers any of the following topics. There may be some topics
> that people feel we've missed, so by all means submit a proposal even if
> it doesn't fit exactly into one of these buckets:
>
> * Compilation techniques
> * Language features and extensions
> * Type system implementation
> * Concurrency and parallelism: language design and implementation
> * Performance, optimisation and benchmarking
> * Virtual machines and run-time systems
> * Libraries and tools for development or deployment
>
> Talks
> -
>
> We invite proposals from potential speakers for talks and
> demonstrations. We are aiming for 20-minute talks with 5 minutes for
> questions and changeovers. We want to hear from people writing
> compilers, tools, or libraries, people with cool ideas for directions in
> which we should take the platform, proposals for new features to be
> implemented, and half-baked crazy ideas. Please submit a talk title and
> abstract of no more than 300 words.
>
> Submissions can be made via HotCRP at https://icfphiw23.hotcrp.com
> until July 4 (anywhere on earth).
>
> We will also have a lightning talks session. These have been very well
> received in recent years, and we aim to increase the time available to
> them. Lightning talks should be ~7mins and are scheduled on the day of the
> workshop. Suggested topics for lightning talks are to present a single
> idea, a work-in-progress project, a problem to intrigue and perplex
> Haskell implementors, or simply to ask for feedback and collaborators.
>
> Program Committee
> -
>
> * Gergő Érdi (Standard Chartered Bank)
> * Sebastian Graf (Karlsruhe Institute of Technology)
> * Wen Kokke (University of Strathclyde)
> * Ryan Scott (Galois, Inc.)
> * Rebecca Skinner (Mercury)
> * Li-yao Xia (University of Edinburgh)
>
> Contact
> ---
>
> * Ryan Scott 
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Final Call for Talks: Haskell Implementors' Workshop 2023

[Ryan Scott]

The 2023 Haskell Implementors' Workshop deadline is just under one month
away. We are looking forward to your talk submissions.

Best,

Ryan

==

ACM SIGPLAN Haskell Implementors' Workshop
https://icfp23.sigplan.org/home/hiw-2023
Seattle, Washington, United States, September 4, 2023

Co-located with ICFP 2023
https://icfp23.sigplan.org/

Important dates
---

Deadline: July 4, 2023 (AoE)
Notification: August 4, 2023
Workshop: September 4, 2023

The 15th Haskell Implementors' Workshop is to be held alongside ICFP
2023 this year in Seattle. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure to share their work and to discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings. The workshop will be informal and interactive, with
open spaces in the timetable and room for ad-hoc discussion, demos,
and short lightning talks.

Scope and target audience
-

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2023. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides, and presented data
available with the consent of the speakers.

The Implementors' Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related tool,
or even propose future lines of Haskell development. Members of the
wider Haskell community are encouraged to attend the workshop -- we need
your feedback to keep the Haskell ecosystem thriving. Students working
with Haskell are especially encouraged to share their work.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

* Compilation techniques
* Language features and extensions
* Type system implementation
* Concurrency and parallelism: language design and implementation
* Performance, optimisation and benchmarking
* Virtual machines and run-time systems
* Libraries and tools for development or deployment

Talks
-

We invite proposals from potential speakers for talks and
demonstrations. We are aiming for 20-minute talks with 5 minutes for
questions and changeovers. We want to hear from people writing
compilers, tools, or libraries, people with cool ideas for directions in
which we should take the platform, proposals for new features to be
implemented, and half-baked crazy ideas. Please submit a talk title and
abstract of no more than 300 words.

Submissions can be made via HotCRP at https://icfphiw23.hotcrp.com
until July 4 (anywhere on earth).

We will also have a lightning talks session. These have been very well
received in recent years, and we aim to increase the time available to
them. Lightning talks should be ~7mins and are scheduled on the day of the
workshop. Suggested topics for lightning talks are to present a single
idea, a work-in-progress project, a problem to intrigue and perplex
Haskell implementors, or simply to ask for feedback and collaborators.

Program Committee
-

* Gergő Érdi (Standard Chartered Bank)
* Sebastian Graf (Karlsruhe Institute of Technology)
* Wen Kokke (University of Strathclyde)
* Ryan Scott (Galois, Inc.)
* Rebecca Skinner (Mercury)
* Li-yao Xia (University of Edinburgh)

Contact
---

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

Call for Talks: Haskell Implementors' Workshop 2023

[Ryan Scott]

ACM SIGPLAN Haskell Implementors' Workshop
https://icfp23.sigplan.org/home/hiw-2023
Seattle, Washington, United States, September 4, 2023

Co-located with ICFP 2023
https://icfp23.sigplan.org/

Important dates
---

Deadline: July 4, 2023 (AoE)
Notification: August 4, 2023
Workshop: September 4, 2023

The 15th Haskell Implementors' Workshop is to be held alongside ICFP
2023 this year in Seattle. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure to share their work and to discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings. The workshop will be informal and interactive, with
open spaces in the timetable and room for ad-hoc discussion, demos,
and short lightning talks.

Scope and target audience
-

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2023. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides, and presented data
available with the consent of the speakers.

The Implementors' Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related tool,
or even propose future lines of Haskell development. Members of the
wider Haskell community are encouraged to attend the workshop -- we need
your feedback to keep the Haskell ecosystem thriving. Students working
with Haskell are especially encouraged to share their work.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

* Compilation techniques
* Language features and extensions
* Type system implementation
* Concurrency and parallelism: language design and implementation
* Performance, optimisation and benchmarking
* Virtual machines and run-time systems
* Libraries and tools for development or deployment

Talks
-

We invite proposals from potential speakers for talks and
demonstrations. We are aiming for 20-minute talks with 5 minutes for
questions and changeovers. We want to hear from people writing
compilers, tools, or libraries, people with cool ideas for directions in
which we should take the platform, proposals for new features to be
implemented, and half-baked crazy ideas. Please submit a talk title and
abstract of no more than 300 words.

Submissions can be made via HotCRP at https://icfphiw23.hotcrp.com
until July 4 (anywhere on earth).

We will also have a lightning talks session. These have been very well
received in recent years, and we aim to increase the time available to
them. Lightning talks should be ~7mins and are scheduled on the day of the
workshop. Suggested topics for lightning talks are to present a single
idea, a work-in-progress project, a problem to intrigue and perplex
Haskell implementors, or simply to ask for feedback and collaborators.

Program Committee
-

* Gergő Érdi (Standard Chartered Bank)
* Sebastian Graf (Karlsruhe Institute of Technology)
* Wen Kokke (University of Strathclyde)
* Ryan Scott (Galois, Inc.)
* Rebecca Skinner (Mercury)
* Li-yao Xia (University of Edinburgh)

Contact
---

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

Re: A macOS static linking mystery

[Ryan Scott]

> One peculiarity with the ordering is that linkers only search static
> archives for existing undefined references. If the reference to `Cffi`
> actually comes first, then nothing should be required from it yet and
> *it shouldn't be linked* (absent options like GNU ld's
> `--whole-archive`).

Hm, this doesn't seem to be the case when I try things locally on macOS. If
I try compiling this C libffi example [1] like so:

$ gcc "-L$(ghc --print-libdir)/rts" -lCffi -lffi -Wl,-dead_strip_dylibs
test.c -o test

Then `otool -L test` does not indicate a dynamic dependency on libffi.dylib:

$ otool -L test
test:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1281.100.1)

On the other hand, if I swap the order of -lCffi and -lffi:

$ gcc "-L$(ghc --print-libdir)/rts" -lffi -lCffi -Wl,-dead_strip_dylibs
test.c -o test

Then `otool -L test` _does_ indicate a dynamic dependency on libffi.dylib:

$ otool -L test
test:
@rpath/libffi.dylib (compatibility version 9.0.0, current
version 9.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1281.100.1)

So on macOS at least, the order does seem to matter.

Ryan
-
[1]
https://www.chiark.greenend.org.uk/doc/libffi-dev/html/Simple-Example.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: A macOS static linking mystery

[Ryan Scott]

I believe I've figured out what is happening here. This will take a bit of
explanation, so bear with me.

First, it's important to note that this behavior depends on whether your
GHC was configured with the `--with-system-libffi` flag or not. If it was
configured with this flag, then GHC will always link against your system's
version of libffi, and the behavior seen in this thread would not occur. I
am using a bindist provided by ghcup which was _not_ configured with
`--with-system-libffi`, so GHC bundles its own copy of libffi.
Interestingly, there appear to be at least two copies of libffi that are
bundled: one dynamic library, simply named libffi.dylib, and one static
library, which is named libCffi.a [1]. Remember the name libCffi.a, since
it will come up again later.

Next, let's take a look at how GHC performs the final linking step when
compiling an executable. GHC will call the C compiler to perform this final
linking step, which will have roughly the following shape on macOS:

gcc ... -L/rts  -lCffi
 -Wl,-dead_strip_dylibs -o Main

I'm omitting quite a few details here, but the important bits are that (1)
-lCffi comes before any of the C libraries listed in an `extra-libraries`
stanza in a .cabal file, and (2) GHC on macOS will pass
-Wl,-dead_strip_dylibs, which causes the linker to remove any references to
shared libraries that go unused.

In the particular case of libffi.cabal, we have `extra-libraries: ffi`, so
the C compiler is given `-lCffi -lffi` as arguments, in that order. Recall
that -libCffi.a (i.e., -lCffi) is a statically linked copy of libffi,
whereas libffi.dylib (i.e., -lffi) is a dynamically linked version. The
linker will resolve all of its references to libffi functionality from
libCffi.a because it appears first, and since the linker never needs to
resolve anything from libffi.dylib, the -Wl,-dead_strip_dylibs will remove
the reference to libffi.dylib entirely. The result is that the final
executable will statically link against libffi. This is why this phenomenon
only occurs with libffi and not with other C libraries, since only libffi
is given special treatment within GHC like this.

Why, then, does this only happen on macOS and not on, say, Linux? On Linux,
the final linking step looks slightly different. Instead of passing
-Wl,-dead_strip_dylibs (which is a macOS-specific option), it will pass
-Wl,--no-as-needed. Note that -Wl,--no-as-needed has the entirely
_opposite_ effect of -Wl,-dead_strip_dylibs: even if a shared library never
gets referenced, the linker will still declare a dynamic dependency on it.
That is exactly what happens here, as the -lCffi argument will still take
precedence over the -lffi argument on Linux, but there will be a useless
dynamic dependency on a dynamic libffi library due to -Wl,--no-as-needed.

At this point, I realized that one consequence of all this is that if you
want to statically link against against libffi, and you are using a GHC
configured without ` --with-system-libffi`, then it suffices to simply
compile your program without any `extra-libraries` at all. That is because
the final link step will pass `-lCffi` no matter what, so the resulting
executable will always statically link against libffi by way of libCffi.a.
Moreover, libCffi is provided on all platforms, not just macOS, so this
trick is reasonably portable.

-

Having explained all this, I am forced to wonder if this is intended
behavior of GHC, or if it is a series of coincidences. The fact that macOS
and Linux pass -Wl,-dead_strip_dylibs and -Wl,--no-as-needed, two flags
with completely opposite behavior, is certainly a little unusual. But these
choices appear to be deliberate, as they are explained in Notes in the GHC
source code here [2] (for macOS) and here [3] (for Linux). The other
possibly unusual thing is that GHC always passes -lCffi before any of the
`extra-libraries`. That could very well be just a coincidence—I'm not sure
if there's a particular reason for -lCffi to come first.

The reason that I'm looking so deeply into this matter is that I'm trying
to see what it would take to reliably link against libffi statically in the
Haskell bindings [4]. I've discovered a trick above to make it work for
most versions of GHC: just rely on `-lCffi`. Does this trick seem like it
would continue to work for the foreseeable future, or is this approach
liable to break in a future release?

Ryan
-
[1] See https://gitlab.haskell.org/ghc/ghc/-/issues/20395 for more on this
unusual amount of library duplication.
[2]
https://gitlab.haskell.org/ghc/ghc/-/blob/d71a20514546e0befe6e238d0658cbaad5a13996/compiler/GHC/Driver/Pipeline.hs#L293-340
[3]
https://gitlab.haskell.org/ghc/ghc/-/blob/d71a20514546e0befe6e238d0658cbaad5a13996/compiler/GHC/SysTools/Info.hs#L57-69
[4] https://github.com/remiturk/libffi/issues/6

On Tue, Aug 9, 2022 at 9:58 AM Ryan Scott  wrote:

> No, I'm using macOS 

Re: A macOS static linking mystery

[Ryan Scott]

No, I'm using macOS 10.15.7 (BuildVersion 19H2) on an x86_64 machine.

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

Re: A macOS static linking mystery

[Ryan Scott]

Possibly? I'm not familiar with the system cache you're referring to, but
it's a more solid lead than what I have currently. Do you know how one
would confirm if this is the case or not?

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

Re: A macOS static linking mystery

[Ryan Scott]

I should clarify that I'm using a borrowed macOS on which I don't have
admin privileges, so I'm unable to install pkg-config. As a result, I'm
commenting out the pkgconfig-depends: line in libffi.cabal and manually
specifying the extra-lib-dirs and include-dirs via a cabal.project.local
file.

I've configured the project to use both the macOS system libffi (located at
/usr/lib/libffi.dylib) as well as the version that Homebrew provides. Both
configurations exhibit the strange, apparently-statically-linked behavior.
Even stranger, the macOS system libffi _only_ provides a .dylib file, not
an .a file. If I examine the x86 code of the compiled executable using
`objdump -d`, I can see various libffi definitions (e.g., _ffi_call), so
perhaps these definitions are being inlined through some kind of link-time
optimization? I'm really not sure how else to explain what's happening.

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

A macOS static linking mystery

[Ryan Scott]

I'm trying to diagnose strange GHC linking behavior which, as far as I can
tell, only occurs on macOS. I feel a bit out of my league debugging this,
so I'm hoping someone knows what is causing this.

When building the Haskell libffi library [1], it will link pass -lffi to
GHC. Typically, most installations of libffi will include both a static
library (libffi.a) and a shared library (libffi.{so,dylib,dll}). My
impression is that when the linker finds both, it will default to the
shared library. This is definitely the case on Linux and Windows, at least.

An exception to this rule is macOS, however. On macOS, building libffi
always appears to default to linking against the static version of libffi,
even when a dynamic version is also available. To reproduce this
phenomenon, check out libffi [1] and run the following commands:

$ brew install libffi # If it is not already installed
$ cabal build ctime
$ otool -L $(cabal list-bin ctime)

The output reveals that the compiled executable does not dynamically link
against libffi.dylib:

$ otool -L $(cabal list-bin ctime)

/Users/rscott/Documents/Hacking/Haskell/libffi/dist-newstyle/build/x86_64-osx/ghc-8.10.7/libffi-examples-0.1/x/ctime/build/ctime/ctime:
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current
version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1281.100.1)
/usr/lib/libcharset.1.dylib (compatibility version 2.0.0,
current version 2.0.0)

This is exceedingly strange, since my Hombrew installation does in fact
provide libffi.dylib:

$ ls -alh ~/Software/homebrew/Cellar/libffi/3.4.2/lib/
total 232
drwxr-xr-x   6 rscott  1340850540   192B Aug  7 09:38 .
drwxr-xr-x  11 rscott  1340850540   352B Aug  7 08:51 ..
-rw-r--r--   1 rscott  134085054070K Aug  7 08:51 libffi.8.dylib
-r--r--r--   1 rscott  134085054041K Jun 28  2021 libffi.a
lrwxr-xr-x   1 rscott  134085054014B Jun 28  2021 libffi.dylib ->
libffi.8.dylib
drwxr-xr-x   3 rscott  134085054096B Aug  7 08:51 pkgconfig

What's more, this only seems to happen when building the libffi library in
particular. If I try building another library that has a C extra-libraries
dependency, such as HsOpenSSL, then I can find its dynamic dependencies
(libssl.dylib and libcrypto.dylib) using otool:

$ otool -L
dist-newstyle/build/x86_64-osx/ghc-8.10.7/HsOpenSSL-0.11.7.2/build/test-dsa/test-dsa

dist-newstyle/build/x86_64-osx/ghc-8.10.7/HsOpenSSL-0.11.7.2/build/test-dsa/test-dsa:
/usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility
version 1.1.0, current version 1.1.0)
/usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib
(compatibility version 1.1.0, current version 1.1.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current
version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1281.100.1)
/usr/lib/libcharset.1.dylib (compatibility version 2.0.0,
current version 2.0.0)

I'm at a bit of a loss trying to figure out why this only happens for
libffi, and only on macOS. To make things even stranger, this only seems to
happen when using GHC. If I try to compile a simple libffi C program using
-lffi, for instance, then otool finds libffi.dylib. Is there something
about GHC's linking behavior that would cause this?

Ryan S.
-
[1] https://github.com/remiturk/libffi
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 9.4.1 Final Call

[Ryan Scott]

One thing that wasn't included in the list but arguably should be is #21618
(Loading libc++ in ghci results in segfaults). As far as I am aware, this
renders GHC 9.4 unusable on Windows for libraries that link against C++.
(Or, at the very least, I haven't figured out a way to make it work.)

Best,

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

Re: To allow deriving poly-kinded Generic1 instances

[Ryan Scott]

> I figured out that this compiles:
>
> data HKD (f :: Type -> Type) = Foo (F1 Int f) (F1 Double f)
>   | Bar (F1 Bool f)
>   deriving Generic1
>
> newtype F1 a f = F1 { unF1 :: f a }

Yes, that's a useful trick to keep in mind. For what it's worth, I think
your `F1` is the same thing as `Barbie` [1] from the `barbies` library.

> Would it be a good idea to add F1 to GHC.Generics?

There's a couple of issues that make me cautious about this idea:

1. This isn't an issue that's specific to `DeriveGeneric`. Other `stock`
deriving strategies that deal with similar classes, such as
`DeriveFunctor`, also suffer from this problem. For instance, you can't do
the following:

   > data T a = MkT (Either a Int) deriving Functor

   Again, the issue is that the last type parameter (`a`) appears in a
field type in a position other than as the last argument. To make _this_
work, you'd need something like `Flip` [2] from the `bifunctors` library:

   > data T a = MkT (Flip Either Int a) deriving Functor

   That leads into the second issue...
2. There are an infinite number of different type variable combinations you
could conceivably add special support for. I've already mentioned `Barbie`
and `Flip` above, but you could just as well put the last type parameter in
other places as well:

   > data S1 a = MkS1 (a, Int, Int) deriving Generic1
   > data S2 a = MkS2 (a, Int, Int, Int) deriving Generic1
   > data S3 a = MkS3 (a, Int, Int, Int, Int) deriving Generic1
   > ...

   And this is only if you assume that the last type parameter only appears
once in each field type. You'd need even more special cases if the last
type parameter appears in multiple places in a field type:

   > data U1 a = MkU1 (a, a) deriving Generic1
   > data U2 a = MkU2 (a, a, a) deriving Generic1
   > ...

   With all of these possibilities, it's difficult to say how far we should
go with this.

Generally speaking, my recommendation for people who are dissatisfied with
`Generic1`'s restrictions on where the last type parameter can be placed is
to not use `Generic1` at all. There are other generic programming libraries
that do not have the same restrictions, such as `kind-generics` [3]. Using
something like `kind-generics` avoids the need to use things like `Barbie`,
`Flip`, etc. in the first place.

Best,

Ryan
-
[1]
https://hackage.haskell.org/package/barbies-2.0.3.0/docs/Barbies.html#t:Barbie
[2]
https://hackage.haskell.org/package/bifunctors-5.5.11/docs/Data-Bifunctor-Flip.html#t:Flip
[3] https://hackage.haskell.org/package/kind-generics

On Wed, Oct 13, 2021 at 9:26 AM Fumiaki Kinoshita 
wrote:

> Oh, I drew a conclusion too early when fiddling with a hypothetical
> Generic1 instance. I now think it's not possible to define an instance with
> the current kit.
>
> I figured out that this compiles:
>
> data HKD (f :: Type -> Type) = Foo (F1 Int f) (F1 Double f)
>   | Bar (F1 Bool f)
>   deriving Generic1
>
> newtype F1 a f = F1 { unF1 :: f a }
>
> Problem solved, thanks!
>
> Would it be a good idea to add F1 to GHC.Generics? Omitting metadata, it'd
> derive something like
>
> instance Generic1 HKD where
>   type Rep1 HKD = F1 Int :*: F1 Double :+: F1 Bool
>   from1 (Foo a b) = L1 (F1 a :*: F1 b)
>   from1 (Bar c) = R1 (F1 c)
>   to1 (L1 (F1 a :*: F1 b)) = Foo a b
>   to1 (R1 (F1 c)) = Bar c
>
> I suppose it doesn't affect existing Generic1 instances and uses, so I
> don't expect breakages by adding this
>
> ...
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: To allow deriving poly-kinded Generic1 instances

[Ryan Scott]

Thanks for posting an example—that's very helpful to figure out what is
going on.

> Currently, GHC rejects the following code:
>
> {-# LANGUAGE DeriveGeneric #-}
> {-# LANGUAGE PolyKinds #-}
> import GHC.Generics
>
> data HKD f = Foo (f Int) (f Double)
> | Bar (f Bool)
> deriving Generic1
> The compilation error is
>
> • Can't make a derived instance of ‘Generic1 HKD’:
> Constructor ‘Foo’ applies a type to an argument involving the last
parameter
>   but the applied type is not of kind * -> *, and
> Constructor ‘Foo’ applies a type to an argument involving the last
parameter
>   but the applied type is not of kind * -> *, and
> Constructor ‘Bar’ applies a type to an argument involving the last
parameter
>   but the applied type is not of kind * -> *
> • In the data declaration for ‘HKD’

I see. That error message could be worded better, in my opinion. The issue
really isn't so much about the kind of `f`. If you had written `data HKD (f
:: Type -> Type) = Baz (Proxy f)`, for instance, I would expect it to work.
The real issue is _where_ `f` appears in the data constructors. In `Bar`,
for instance, you have:

> Bar (f Bool)

`Generic1` is limited to data types where the last type parameter only
appears as the last type argument in any field. This means that a field
like `Proxy f` would be fine, as that would be represented as `Rec1 Proxy`
in a `Rep1` instance. `f Bool`, on the other hand, is problematic.
`GHC.Generics` doesn't have a representation type that simultaneously
allows representing this field while also "focusing" on the last type
parameter like `Rec1`, `Par1`, etc. would allow.

The `Foo` constructor has similar issues. The error-reporting machinery for
`DeriveGeneric` essentially just accumulates every issue it encounters and
reports everything at once, which is why there is a duplicate error message
involving `Foo`. Needless to say, this kind of error message could be
improved.

> Although it is possible to define a hand-rolled instance of Generic1

Really? I'm not sure how you would define a correct `Generic1` instance for
`HKD` at all. What did you have in mind?

Best,

Ryan

On Wed, Oct 13, 2021 at 8:33 AM Fumiaki Kinoshita 
wrote:

> Currently, GHC rejects the following code:
>
> {-# LANGUAGE DeriveGeneric #-}
> {-# LANGUAGE PolyKinds #-}
> import GHC.Generics
>
> data HKD f = Foo (f Int) (f Double)
> | Bar (f Bool)
> deriving Generic1
>
> The compilation error is
>
> • Can't make a derived instance of ‘Generic1 HKD’:
> Constructor ‘Foo’ applies a type to an argument involving the last
> parameter
>   but the applied type is not of kind * -> *, and
> Constructor ‘Foo’ applies a type to an argument involving the last
> parameter
>   but the applied type is not of kind * -> *, and
> Constructor ‘Bar’ applies a type to an argument involving the last
> parameter
>   but the applied type is not of kind * -> *
> • In the data declaration for ‘HKD’
>   |
> 7 | deriving Generic1
>
> Although it is possible to define a hand-rolled instance of Generic1,
> DeriveGeneric is still restricted to Type -> Type.
>
> 2021年10月13日(水) 21:17 Ryan Scott :
>
>> Hello,
>>
>> I'm not quite sure I understand the issue you're hitting. Generic1 is
>> poly-kinded, so I would expect it to be able to handle data types where the
>> last type parameter has differing kinds. Can you post a complete example of
>> the program you expect to typecheck, but doesn't?
>>
>> Best,
>>
>> Ryan
>> ___
>> 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: To allow deriving poly-kinded Generic1 instances

[Ryan Scott]

Hello,

I'm not quite sure I understand the issue you're hitting. Generic1 is
poly-kinded, so I would expect it to be able to handle data types where the
last type parameter has differing kinds. Can you post a complete example of
the program you expect to typecheck, but doesn't?

Best,

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

GitLab e-mails: down for everyone, or just me?

[Ryan Scott]

Since yesterday, I haven't been receiving any e-mail notifications from
GitLab. Are other people having this problem too, or is it a problem on my
end?

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

Seeking performance-minded reviewers on !2965

[Ryan Scott]

!2965 [1] seeks to improve the performance of derived Generic(1) instances
by heuristically annotating implementations of the from(1) and to(1) class
methods with INLINE[1] pragmas. For the most part, this results in
performance wins, as the generic intermediate representations of data types
can be optimized away in more situations.

However, I'm unclear on one aspect of the MR: it actually leads to a
compile-time performance increase (specifically, in bytes allocated) in one
test case: T12227:

  TestMetric value New value Change
T12227(normal) ghc/alloc   518417756.0   526479616.0  +1.6%
BAD

The MR author provides an explanation for why this happens here [2].
However, as I am not really a GHC performance guru, it's difficult for me
to accurately judge whether this difference is within acceptable limits or
not.

For those of you who care about compile-time performance, would you be
willing to give !2965 a look over and judge whether the difference is
acceptable? I think this is the last remaining hurdle to clear before we
can land !2965, so your input would be greatly appreciated. Thanks!

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2965
[2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2965#note_304501
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How is GHC.Prim.unpackInt8X64# meant to be used?

[Ryan Scott]

 > Ryan, the comment in GHC.Tuple seems to be misleading today, as
suggested by this SO post:
https://stackoverflow.com/questions/46412823/why-are-ghc-tuples-limited-to-size-62

> I was going to add it to the comment at some point but was hesitant as I
hadn’t verified the information myself.

For what it's worth, Ben has removed this comment in !4146 [1], where he
increases the maximum tuple size to 64. This is enough to unblock me on
progressing with !4097, so I'm happy. There seems to be a more general
question of whether it makes sense to enforce a size limit at all for
unboxed tuples, but I'll leave that question to people more knowledgeable
than I am.

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4146
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How is GHC.Prim.unpackInt8X64# meant to be used?

[Ryan Scott]

I had a feeling that this might be the case. Unfortunately, this technology
preview is actively blocking progress on !4097, which leaves me at a loss
for what to do. I can see two ways forward:

1. Remove unpackInt8X64# and friends.
2. Reconsider whether the tuple size limit should apply to unboxed tuples.
Perhaps this size limit only makes sense for boxed tuples? This comment [1]
suggests that defining a boxed tuple of size greater than 62 induces a
segfault, but it's unclear to me if the same thing happens for unboxed
tuples.

Ryan S.
-
[1]
https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/libraries/ghc-prim/GHC/Tuple.hs#L170

On Sat, Sep 26, 2020 at 7:54 AM Ben Gamari  wrote:

> On September 25, 2020 6:21:23 PM EDT, Ryan Scott 
> wrote:
> ...
> >However, I discovered recently that there are places where GHC *does*
> >use
> >unboxed tuples with arity greater than 62. For example, the
> >GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size
> >64. I
> >was confused for a while about how this was even possible, but I
> >realized
> >later than GHC only enforces the tuple size limit in expressions and
> >patterns [3]. Simply having a type signature with a large unboxed tuple
> >is
> >fine in and of itself, and since unpackInt8X64# is implemented as a
> >primop,
> >no large unboxed tuples are ever used in the "body" of the function.
> >(Indeed, primops don't have function bodies in the conventional sense.)
> >Other functions in GHC.Prim that use unboxed tuples of arity 64 include
> >unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].
> >
> >But this makes me wonder: how on earth is it even possible to *use*
> >unpackInt8X64#?
>
>
> I strongly suspect that the answer here is "you can't yet no one has
> noticed until now." The SIMD operations were essentially introduced as a
> technology preview and therefore never had proper tests added. Only a
> subset of these operations have any tests at all and I doubt anyone has
> attempted to use the 64-wide operations, which are rather specialized.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

How is GHC.Prim.unpackInt8X64# meant to be used?

[Ryan Scott]

GHC imposes an upper bound of 62 on the size of tuples one can use [1].
Currently, this upper bound applies to both boxed and unboxed tuples alike.
For example, if you try to create an unboxed tuple of arity 64, then GHC
will throw an error:

error:
A 64-tuple is too large for GHC
  (max size is 62)
  Workaround: use nested tuples or define a data type
  |
  | f =
(#,,,#)
  |
^^^

However, I discovered recently that there are places where GHC *does* use
unboxed tuples with arity greater than 62. For example, the
GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size 64. I
was confused for a while about how this was even possible, but I realized
later than GHC only enforces the tuple size limit in expressions and
patterns [3]. Simply having a type signature with a large unboxed tuple is
fine in and of itself, and since unpackInt8X64# is implemented as a primop,
no large unboxed tuples are ever used in the "body" of the function.
(Indeed, primops don't have function bodies in the conventional sense.)
Other functions in GHC.Prim that use unboxed tuples of arity 64 include
unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].

But this makes me wonder: how on earth is it even possible to *use*
unpackInt8X64#? The only thing that comes to mind is to pattern-match on
the unboxed tuple that it returns, but if you try to do that, you'll get a
"64-tuple is too large for GHC" error like shown above. What's more, I
can't find any test cases in the GHC test suite that show how
unpackInt8X64# or its cousins are supposed to be used. What am I missing?
The comments for these functions mention "Warning: this is only available
on LLVM", so perhaps someone familiar with the LLVM backend knows what the
answer is?

For some context, this came up in !4097, where I am attempting to extend
the "too large for GHC" error message to include types, in addition to
expressions and patterns [7]. However, doing so causes Haddock to error
when processing unpackInt8X64# et al.

Ryan S.
-
[1]
https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/compiler/GHC/Settings/Constants.hs#L13-15
[2]
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:unpackInt8X64-35-
[3] https://gitlab.haskell.org/ghc/ghc/-/issues/18723
[4]
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:unpackWord8X64-35-
[5]
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:packInt8X64-35-
[6]
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:packWord8X64-35-
[7] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4097#note_301191
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: HsPragTick

[Ryan Scott]

I think that HsPragTick is unused as of [1]. In fact, I was under the
impression that [1] removed HsPragTick entirely (as the commit message)
would suggest, but upon further inspection, that doesn't appear to be the
case. Vlad, do you recall why HsPragTick was kept around?

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2154
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: HEAD doesn't build. Totally stalled.

[Ryan Scott]

> And while Simon is the only
> one I'm aware of, for whom this breaks

For what it's worth, I am hitting the same issue when building GHC.

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

Re: GitLab status

[Ryan Scott]

Just as an FYI, there appears to be some data loss from this migration. For
example, I pushed a commit to !3536 [1] that appears to have been dropped,
leading to confusion here [2]. To make things worse, I never received an
e-mail notification for this comment—I only discovered it by chance.

I also opened an issue about FUN, but that appears to have been lost. I
could try to resubmit it, but perhaps the data still exists somewhere on
servers somewhere?

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3536
[2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3536#note_283322
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Marge Bot repeatedly failing due to stat decreases

[Ryan Scott]

Thanks Ben!

For future reference, is there anything that we as ordinary GHC
developers can do to help Marge along when she gets stuck on stat
changes? You mentioned that you amended a Marge batch to accept the
changes before. Are there instructions on how to do this properly? For
instance, which commit(s) in a batch should be amended? Is it better
to amend the branch that Marge works on directly, or to update the
original MR?

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

Re: Marge Bot repeatedly failing due to stat decreases

[Ryan Scott]

Something strange is still going on, since Marge now just opened an
empty merge batch [1].

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3465

On Mon, Jun 8, 2020 at 9:37 AM Ben Gamari  wrote:
>
> Ryan Scott  writes:
>
> > Hello,
> >
> > I've been receiving a flurry of e-mails all weekend about Marge Bot
> > failing to validate a batch on CI. Moreover, the failures appear to be
> > consistent each time. From the most recent one [1]:
> >
> Yesterday I had amended one of Marge's batches to accept the performance
> changes and marked it for auto-merging. Unfortunately Marge got to it
> before CI finished it and closed it.
>
> I just manually merged it and restarted Marge. Sorry for the delay!
>
> Cheers,
>
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Marge Bot repeatedly failing due to stat decreases

[Ryan Scott]

Hello,

I've been receiving a flurry of e-mails all weekend about Marge Bot
failing to validate a batch on CI. Moreover, the failures appear to be
consistent each time. From the most recent one [1]:

Unexpected stat failures:
   /builds/ghc/ghc/tmp/ghctest-mel1y5lo/test
spaces/testsuite/tests/perf/compiler/T12150.run  T12150 [stat
decreased from "x86_64-linux-deb9-hadrian" baseline @ HEAD~6] (optasm)
   /builds/ghc/ghc/tmp/ghctest-mel1y5lo/test
spaces/testsuite/tests/perf/compiler/T12234.run  T12234 [stat
decreased from "x86_64-linux-deb9-hadrian" baseline @ HEAD~6] (optasm)

Where

T12150(optasm)compile_time/bytes allocated
75982592.000
  (baseline @ HEAD~6)
76945688.000  [decreased, -1.3%]
T12234(optasm)compile_time/bytes allocated
82149240.000
  (baseline @ HEAD~6)
83109896.000  [decreased, -1.2%]

Can something be done about this? It's holding one one of my patches.

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/-/jobs/359994
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Uppercase OverloadedLabels

[Ryan Scott]

No particular reason. There is an accepted GHC proposal to relax this
restriction [1], as well as an accompanying GHC issue [2], but it has not
yet been implemented.

Ryan S.
-
[1]
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0170-unrestricted-overloadedlabels.rst
[2] https://gitlab.haskell.org/ghc/ghc/issues/11671
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Building libraries with an in-place GHC

[Ryan Scott]

Hi Simon,

As #18018 says, you need to use head.hackage to reproduce it. This
page [1] contains a rather short tutorial on how to use it, but Ben is
currently drafting a more detailed tutorial on its use here [2]. This
is what I use whenever building any Hackage library with GHC HEAD.

Ryan S.
-
[1] https://ghc.gitlab.haskell.org/head.hackage/
[2] https://gitlab.haskell.org/ghc/homepage/-/merge_requests/29
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

gitlab.haskell.org spam issues

[Ryan Scott]

There appears to be an account [1] that is submitting spam as GitLab
issues. I've noticed the following spam issues so far:

* https://gitlab.haskell.org/ghc/ghc/issues/17664
* https://gitlab.haskell.org/ghc/ghc/issues/17666
* https://gitlab.haskell.org/haskell/ghcup/issues/125
* https://gitlab.haskell.org/haskell/ghcup/issues/127
* https://gitlab.haskell.org/haskell/ghcup/issues/129

Best,
Ryan S.
-
[1] https://gitlab.haskell.org/nunikonaza88
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Reminder] Merge window for 8.10 closing

[Ryan Scott]

I've been working on a fix for #13154 [1] that I'd like to get into GHC
8.10. My patch [2] is mostly done; I just need to find the time to add
comments and perform some slight code cleanup. (Hopefully this week!)

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/issues/13154
[2] https://gitlab.haskell.org/RyanGlScott/ghc/tree/wip/T13154-take-two
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Guarded Impredicativity

[Ryan Scott]

Good to know. Thanks for checking!

Ryan S.

On Fri, Jul 19, 2019 at 11:22 AM Artem Pelenitsyn
 wrote:
>
> Hello Ryan,
>
> Your example seems to work out of the box with the GI branch.
>
> With the oneliner Matthew posted before:
> nix run -f 
> https://github.com/mpickering/ghc-artefact-nix/archive//master.tar.gz \
> ghc-head-from -c ghc-head-from \
> https://gitlab.haskell.org/mpickering/ghc/-/jobs/114593/artifacts/raw/ghc-x86_64-fedora27-linux.tar.xz
> It is really easy to check. Also, I didn't see anywhere mentioned that one 
> need to provide -XImpredicativeTypes. The whole example, therefore, is:
>
> {-#LANGUAGE ImpredicativeTypes, ConstraintKinds #-}
> module M where
> type F f = (Functor f, forall a. Eq (f a))
>
> --
> Best, Artem
>
> On Fri, 19 Jul 2019 at 09:18, Ryan Scott  wrote:
>>
>> I have another interesting application of guarded impredicativity that
>> I want to bring up. Currently, GHC #16140 [1] makes it rather
>> inconvenient to use quantified constraints in type synonyms. For
>> instance, GHC rejects the following example by default:
>>
>> type F f = (Functor f, forall a. Eq (f a))
>>
>> This is because F is a synonym for a constraint tuple, so mentioning a
>> quantified constraint in one of its arguments gets flagged as
>> impredicative. In the discussion for #16140, we have pondered doing a
>> major rewrite of the code in TcValidity to permit F. But perhaps we
>> don't need to! After all, the quantified constraint in the example
>> above appears directly underneath a type constructor (namely, the type
>> constructor for the constraint 2-tuple), which should be a textbook
>> case of guarded impredicativity.
>>
>> I don't have the guarded impredicativity branch built locally, so I am
>> unable to test if this hypothesis is true. In any case, I wanted to
>> mention it as another motivating use case.
>>
>> Ryan S.
>> -
>> [1] https://gitlab.haskell.org/ghc/ghc/issues/16140
>> ___
>> 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: Guarded Impredicativity

[Ryan Scott]

I have another interesting application of guarded impredicativity that
I want to bring up. Currently, GHC #16140 [1] makes it rather
inconvenient to use quantified constraints in type synonyms. For
instance, GHC rejects the following example by default:

type F f = (Functor f, forall a. Eq (f a))

This is because F is a synonym for a constraint tuple, so mentioning a
quantified constraint in one of its arguments gets flagged as
impredicative. In the discussion for #16140, we have pondered doing a
major rewrite of the code in TcValidity to permit F. But perhaps we
don't need to! After all, the quantified constraint in the example
above appears directly underneath a type constructor (namely, the type
constructor for the constraint 2-tuple), which should be a textbook
case of guarded impredicativity.

I don't have the guarded impredicativity branch built locally, so I am
unable to test if this hypothesis is true. In any case, I wanted to
mention it as another motivating use case.

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/issues/16140
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Moving head.hackage upstream

[Ryan Scott]

Count me among the people who are eagerly awaiting this move. If I
understood Ben correctly when discussing this idea with him on #ghc, then
one of the benefits of having head.hackage on GitLab would be that the
head.hackage index would automatically regenerate any time a commit lands.
This would make things far more streamlined than the status quo, where the
index has to be regenerated by hand.

If head.hackage is migrated over to GitLab, would that change how people
are expected to use it? That is, would it still be as simple as copying the
repository stanza from [1] into one's cabal.project file? Or would that
change with a move to GitLab?

Ryan S.
-
[1] http://head.hackage.haskell.org/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: lint-submods-marge consistently failing when attempting to update Haddock

[Ryan Scott]

The submodule linter appears to have been disabled in [1]. As Matthew notes
in [2], perhaps we should probably open a ticket to track how to restore it.

Ryan S.
-
[1]
https://gitlab.haskell.org/ghc/ghc/commit/a39a3cd663273c46cf4e346ddf3bf9fb39195c9d
[2]
https://gitlab.haskell.org/ghc/ghc/commit/a39a3cd663273c46cf4e346ddf3bf9fb39195c9d#note_213227
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: lint-submods-marge consistently failing when attempting to update Haddock

[Ryan Scott]

Ben indicates (on the #ghc IRC channel) that he suspects something is
amiss with the lint-submods-marge job.

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

lint-submods-marge consistently failing when attempting to update Haddock

[Ryan Scott]

I've noticed that Marge's most recent batch is consistently failing
after repeated attempts. Each time, the failure is only in the
lint-submods-marge job. Here is an excerpt from the most recent
failure [1]:

Submodule update(s) detected in 1cd22260c2467650dde8811cc58e89594a016f43:
 utils/haddock => 658ad4af237f3da196cca083ad525375260e38a7
*FAIL* commit not found in submodule repo
   or not reachable from persistent branches

My understanding is that the lint-submods-marge job checks for any
submodule updates, and if there is an update, it ensures that the new
commit is actually present upstream. However, I have already pushed
Haddock commit 658ad4af237f3da196cca083ad525375260e38a7 upstream on
GitHub [2], and there has been enough time for this commit to also
appear on the GitLab mirror [3]. Despite this, lint-submods-marge
keeps failing, and I have no idea why. Does anyone know what to do
from here?

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/-/jobs/119054
[2] 
https://github.com/haskell/haddock/commit/658ad4af237f3da196cca083ad525375260e38a7
[3] 
https://gitlab.haskell.org/ghc/haddock/commit/658ad4af237f3da196cca083ad525375260e38a7
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Guarded Impredicativity

[Ryan Scott]

Would this permit explicit impredicativity as described in [1]? Simon
mentions in [1] that explicit impredicativity is easier to implement than
guarded impredicativity, although it's not clear to me if the latter would
imply the former.

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/issues/14859
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Bug or feature?

[Ryan Scott]

Hi Iavor,

This is a feature in the sense that it is an expected outcome of the
OutsideIn(X) type inference algorithm (in particular, Section 5 of the
corresponding paper [1]). I'll try to explain the issue to the best of
my understanding.

The tricky thing about the Q3 data type:

data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b)

Is that there is a rank-n type with a /local/ equality constraint. In
order to ensure that the type of the Q3 data constructor is never
ambiguous, GHC tries to infer that Q3's type is always a subtype of
itself. As a part of this, GHC attempts to solve the following
implication constraint:

forall a. forall b. (F b ~ Int) => (a ~ alpha)

Where `alpha` is a unification variable. GHC tries to find a unique,
most-general substitution that solves this constraint but ultimately
gives up and reports the "untouchable" error message you observed.

This is a bit strange, however. Upon first glance, this constraint
would appear to have a unique solution: namely, [alpha |-> a]. Why
doesn't GHC just use this? Ultimately, it's because OutsideIn(X) is
conservative: there may exist constraints that admit a unique solution
which it may fail to solve. This is explained in greater depth in
Section 5.2 of the paper, but the essence of this restriction is
because of the open-world assumption for type families. Namely, it's
possible that your Q3 data type might later be linked against code
which defines the following type family:

type family G i a
type instance G Int a = a

If that were the case, then the implication constraint above would no
longer have a unique solution, since there would exist another
substitution [alpha |-> G (F b) a] that is incomparable with [alpha
|-> a]. OutsideIn(X) was designed to only pick unique solutions that
remain unique solutions even if more axioms (i.e., type family
equations) are added, so for these reasons it fails to solve the
implication constraint above.

See also GHC issues #10651 [2], #14921 [3], and #15649 [4], which all
involve similar issues.

-

I'm far from an expert on type inference, so I can't really offer a
better inference algorithm that would avoid this problem. The best you
can do, as far as I can tell, is to enable AllowAmbiguousTypes and
hope for the best. Even then, you'll still run into situations where
untouchability rears its ugly head, as in your `q3` definition. When
that happens, your only available option (again, as far as I can tell)
is to make use of TypeApplications. For example, the following /does/
typecheck:

q3 :: Q3
q3 = Q3 @Bool t

Hope that helps,

Ryan S.
-
[1] 
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp-outsidein.pdf
[2] https://gitlab.haskell.org/ghc/ghc/issues/10651
[3] https://gitlab.haskell.org/ghc/ghc/issues/14921
[4] https://gitlab.haskell.org/ghc/ghc/issues/15649
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: gitlab upgrade - change in approval system

[Ryan Scott]

To be clear, your workaround is precisely what I used to do, but that is no
longer working after the GitLab upgrade. I can add myself as a reviewer,
but only to a group besides the default approvers list. Because Marge only
counts approvals from those who belong to the default approvers list, my
approvals don't count anymore.

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

Re: gitlab upgrade - change in approval system

[Ryan Scott]

I would definitely appreciate changing Marge's behavior back to the old
one. As things stand currently, I am unable to approve anything that I'm
not explicitly listed as a reviewer for. See here [1] for an example of
where this has happened.

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/merge_requests/559#note_198714
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.8.1-alpha1 is now available

[Ryan Scott]

The 8.8 Migration Guide can be found here:
https://gitlab.haskell.org/ghc/ghc/wikis/migration/8.8

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

Re: Recover role of a type variable in source Haskell

[Ryan Scott]

It depends on what you mean by "source Haskell". If you're willing to
consider including Template Haskell in your definition of "source", then
the answer is yes, since there is a reifyRoles function [1] which gives you
this information.

I'm not aware of another way to accomplish this (without resorting to
something like the GHC API).

Ryan S.
-
[1]
https://hackage.haskell.org/package/template-haskell-2.14.0.0/docs/Language-Haskell-TH.html#v:reifyRoles
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Near-daily "Remote mirror update failed" e-mails from GitLab

[Ryan Scott]

This GitLab CE issue seems relevant: [1]

(I'm writing this just as I receive another "Remote mirror update failed"
e-mail, this time about the wip/lint-check-version-number branch.)

Ryan S.
-
[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/56222


On Sun, Apr 7, 2019 at 3:30 PM Ben Gamari  wrote:

> Ryan Scott  writes:
>
> > To be clear, the wip/dmd-arity is not the only branch I've received
> e-mails
> > about. I've also received "Remove mirror update failed" e-mails of a
> > similar caliber that warn about the wip/slowtest, ghc-8.6,
> ghc-8.8-merges,
> > wip/marge_bot_batch_merge_job, and master branches.
> >
> > Are you not received these as well? They almost seem to happen any time
> any
> > commit is landed.
> >
> Strangely I'm not. I did receive a number of similar emails for other
> repositories in March but I have not received any recently and never any
> concerning ghc/ghc. This is extremely strange given that I created the
> project and we both have maintainer role.
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Near-daily "Remote mirror update failed" e-mails from GitLab

[Ryan Scott]

To be clear, the wip/dmd-arity is not the only branch I've received e-mails
about. I've also received "Remove mirror update failed" e-mails of a
similar caliber that warn about the wip/slowtest, ghc-8.6, ghc-8.8-merges,
wip/marge_bot_batch_merge_job, and master branches.

Are you not received these as well? They almost seem to happen any time any
commit is landed.

Ryan S.

On Sat, Apr 6, 2019 at 2:28 PM Ben Gamari  wrote:

> Ryan Scott  writes:
>
> > Almost every day now I receive an e-mail from GitLab titled "Remote
> > mirror update failed", which contains something like:
> >
> > To
> >
> >  ! [remote rejected]   wip/dmd-arity -> wip/dmd-arity (cannot
> > lock ref 'refs/heads/wip/dmd-arity': is at
> > e1cc1254b81a7adadd8db77c7be625497264ab2b but expected
> > f07b61d047967129a3ae0c56f8894d41c5a9b036)
> >
> > error: failed to push some refs to '[FILTERED]@github.com/ghc/ghc'
> >
> Hmm, how annoying. Strangely, the `wip/dmd-arity` branch currently
> appears to be sitting at the same commit on GitLab and GitHub so I'm not
> really sure what to do here.
>
> sgraf, did you ever push a branch manually to the github.com/ghc/ghc
> mirror?
>
> Cheers,
>
> -  Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Debug printing inside the typechecker knot

[Ryan Scott]

> Did you mean "What is the TcHsSyn counterpart to TcMType.zonkTcTyVar"?

D'oh. Yes, I did.

> But it's never a bad idea to document more.

I've documented all the wisdom from here in this wiki page [1]! Feel
free to edit it if there are any corrections to be made.

Ryan S.
-
[1] 
https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/tying-the-knot/printing
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Near-daily "Remote mirror update failed" e-mails from GitLab

[Ryan Scott]

Almost every day now I receive an e-mail from GitLab titled "Remote
mirror update failed", which contains something like:

To

 ! [remote rejected]   wip/dmd-arity -> wip/dmd-arity (cannot
lock ref 'refs/heads/wip/dmd-arity': is at
e1cc1254b81a7adadd8db77c7be625497264ab2b but expected
f07b61d047967129a3ae0c56f8894d41c5a9b036)

error: failed to push some refs to '[FILTERED]@github.com/ghc/ghc'

Is there a way to make these stop?

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

Re: Debug printing inside the typechecker knot

[Ryan Scott]

> No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs 
> returns a [TyVar] -- this won't end well. If you look further in zonkTyBndrs, 
> you'll see that it calls `zonkTcTypeToType (tyVarKind tv)` (roughly), making 
> the equivalent to be TcMType.zonkTyCoVarKind.

Ah. I was led astray because there is a TcMType.zonkTyCoVarKind
function, but not a TcMType.zonkTyCoVarKinds function (with an -s at
the end). Similarly strange is that there is a TcHsType.zonkTyBndrs
function, but not a TcHsType.zonkTyBndr function (without an -s at the
end).

Out of curiosity, is a TcHsType counterpart to TcMType.zonkTcTyVar(s)?

> Clearly, it would behoove use to rename these functions to be more systematic.

Indeed. What would be better names for these? It looks like we've
identified at least a couple things that could be cleaned up in
TcMType and TcHsType, so if you suggest a more consistent naming
scheme, I would be willing to implement it.

My eventual goal is to write up this wisdom in a GHC wiki page simply
because I keep getting frustrated any time I have to debug code in the
typechecker knot, and I'd like to codify this solution somewhere where
I can look it up in the future if (when) I eventually forget it.

Ryan S.

On Thu, Apr 4, 2019 at 3:05 PM Richard Eisenberg  wrote:
>
>
>
> > On Apr 4, 2019, at 2:55 PM, Ryan Scott  wrote:
> >
> > Good to know, thanks. I assume that TcMType.zonkTcTypes is to
> > TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to
> > TcHsType.zonkTyBndrs?
>
> No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs 
> returns a [TyVar] -- this won't end well. If you look further in zonkTyBndrs, 
> you'll see that it calls `zonkTcTypeToType (tyVarKind tv)` (roughly), making 
> the equivalent to be TcMType.zonkTyCoVarKind.
>
> Clearly, it would behoove use to rename these functions to be more systematic.
>
> >
> > Also, what exactly is the optimization that ZonkEnv performs in types?
> > And why don't the functions in TcMType make use of this optimization?
>
> Suppose we have
>
> forall (a :: kappa). ... a ...
>
> We laboriously discover that kappa should be (Type -> Type). The ZonkEnv 
> stores a mapping (a |-> (a :: Type -> Type)) so that when we spot the `a` in 
> the body of the forall, we don't have to repeat the zonk -- we just do a 
> lookup. But, of course, zonking the occurrence of `a` would also work.
>
> Why don't we do this in TcMType? There's likely no good reason -- it would be 
> effective there, too. But it would be less effective. The code in TcHsSyn 
> generally starts with *closed* types/terms, meaning that all type variables 
> will be brought into scope somewhere. In contrast, TcMType functions can work 
> over *open* terms, so we have less opportunity to extend the ZonkEnv.
>
> Richard
>
> >
> > Ryan S.
> > ___
> > 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: Debug printing inside the typechecker knot

[Ryan Scott]

Good to know, thanks. I assume that TcMType.zonkTcTypes is to
TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to
TcHsType.zonkTyBndrs?

Also, what exactly is the optimization that ZonkEnv performs in types?
And why don't the functions in TcMType make use of this optimization?

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

Debug printing inside the typechecker knot

[Ryan Scott]

I've recently found myself wanting to add some pprTrace statements in
typechecker-related code but unable to do so, as the code would pull
on knot-tied TyCons (leading to an infinite loop if actually ran). In
particular, I want to print some code [1] in TcTyClsDecls.tcConDecl:

   ; (ze, tkvs) <- zonkTyBndrs tkvs
   ; (ze, user_tvs) <- zonkTyBndrsX ze user_tvs
   ; arg_tys <- zonkTcTypesToTypesX ze arg_tys
   ; ctxt<- zonkTcTypesToTypesX ze ctxt
   ; res_ty  <- zonkTcTypeToTypeX   ze res_ty

   ; let (univ_tvs, ex_tvs, tkvs', user_tvs', eq_preds, arg_subst)
   = rejigConRes tmpl_bndrs res_tmpl tkvs user_tvs res_ty

In [2], goldfire claimed that there is a way to work around this problem now:

> But you can do this. It just has to be before the final zonk. I
see that rejigConRes is used after the final zonk. But there's nothing
about that function that requires things be in their final state. The
arguments need to be zonked, but they can be zonked by zonkTcType and
friends, not zonkTcTypeToType and friends. So, for debugging: zonk
everything with the functions in TcMType (not those in TcHsSyn). Then
rejigConRes. Then print all the output you like. Then do the final
zonk. This double-zonk is redundant, so it's not good to keep going
forward, but it shouldn't cause other trouble.

Unfortunately, this advice doesn't seem to pan out in practice. I
started off by looking for a TcMType equivalent of this function:

zonkTcTypeToTypeX :: ZonkEnv -> TcType -> TcM Type

However, I am utterly unable to find anything defined in TcMType with
a similar type signature. Actually, it's worse than that: there isn't
a single mention of ZonkEnv anywhere in TcMType! So as far as I can
tell, this advice is completely unimplementable, unless I'm missing
something obvious. Any tips?

Ryan S.
-
[1] 
https://gitlab.haskell.org/ghc/ghc/blob/51fd357119b357c52e990ccce9059c423cc49406/compiler/typecheck/TcTyClsDecls.hs#L2312-2318
[2] https://phabricator.haskell.org/D4974#137224
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab conventions

[Ryan Scott]

> To identify backports I look at open tickets bearing the
> "backport needed" label.

That's good to know, thanks.

What should become of small MRs that are made directly against `master`
(without a corresponding issue) that are intended to be backported as well?
Does it suffice to label those with "backport needed", or should we also
open "backport needed"–labeled issues as well to ensure that they're
caught? (I have [1] and [2] in mind when asking this question.)

I ask since if the former suffices, that would imply that the set of places
that one would need to look to find all things that need to be backported
would be:

1. The set of all open tickets labeled with "backport needed", unioned with
2. The set of all resolved MRs labeled with "backport needed".

Unfortunately, GitLab doesn't appear to give you a way to view both
simultaneously (unless I'm missing something), which is why I thought it
worthwhile to ask you if this state of affairs would be inconvenient.

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/merge_requests/650
[2] https://gitlab.haskell.org/ghc/ghc/merge_requests/639

On Tue, Apr 2, 2019 at 2:24 PM Ben Gamari  wrote:

> Ryan Scott  writes:
>
> > Thanks! The updated information is now on
> > https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/merge-requests, for
> those
> > who are curious:
> >
> >> While the release manager can perform the backport on your behalf, it is
> > appreciated if you open a merge request with the backported patches
> > yourself.
> >
> > One further question: if a patch (that is intended to be backported)
> first
> > lands on master, is it considered good practice to leave the
> corresponding
> > issue open until the backport happens, similar to Trac's "merge" status?
> Or
> > is this practice obsolete in the new label-based workflow?
> >
> Indeed this should be documented (which I have done): the ticket should
> remain open. To identify backports I look at open tickets bearing the
> "backport needed" label.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab conventions

[Ryan Scott]

Thanks! The updated information is now on
https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/merge-requests, for those
who are curious:

> While the release manager can perform the backport on your behalf, it is
appreciated if you open a merge request with the backported patches
yourself.

One further question: if a patch (that is intended to be backported) first
lands on master, is it considered good practice to leave the corresponding
issue open until the backport happens, similar to Trac's "merge" status? Or
is this practice obsolete in the new label-based workflow?

Ryan S.

On Tue, Apr 2, 2019 at 10:05 AM Ben Gamari  wrote:

> Ryan Scott  writes:
>
> > Thanks for writing these up! These will be handy references that I'm sure
> > I'll come back to many times.
> >
> > Question: once I've marked my MR as "backport-needed" (and it is merged
> > into master), whose responsibility is it to ensure that it gets merged
> into
> > the latest release branch (e.g., ghc-8.8)? It it the responsibility of
> the
> > person who made the MR originally, or is there a process in place for
> > collecting these backport-needed patches into batches and merging them?
> >
> It is of course appreciated if people backport their own patches.
> However, I do intend on doing a sweep of the backport list and take care
> of anything I find while preparing the stable branch.
>
> I'll see to it that this is better documented.
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab conventions

[Ryan Scott]

Thanks for writing these up! These will be handy references that I'm sure
I'll come back to many times.

Question: once I've marked my MR as "backport-needed" (and it is merged
into master), whose responsibility is it to ensure that it gets merged into
the latest release branch (e.g., ghc-8.8)? It it the responsibility of the
person who made the MR originally, or is there a process in place for
collecting these backport-needed patches into batches and merging them?

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

Re: GitLab seems quite poorly

[Ryan Scott]

Things still appear not to work whenever I try to push a new branch:

fatal: unable to access 'https://gitlab.haskell.org/RyanGlScott/ghc.git/':
The requested URL returned error: 500

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

Re: Why can't we re-install the template-haskell package?

[Ryan Scott]

If you're reinstalling the same template-haskell version, then I can't
immediately think of anything that would go wrong. Then again, I'm not
intimately familiar with all of the little details that might be relevant
here.

Out of curiosity, are you asking this question because you've tried
implementing this and failed somewhere? Or are you trying to figure out is
there's some obvious problem with the idea that's been overlooked? In the
absence of anyone chiming in with such an obvious problem, I'd be inclined
to just try implementing it and seeing what happens. If it does break, that
could provide some valuable insight.

Ryan S.

On Thu, Mar 7, 2019 at 10:12 PM Moritz Angermann 
wrote:

> Hi Ryan, hi Richard,
>
> > My (limited) understanding is that template-haskell is not reinstallable
> for the same reasons that base and ghc-prim aren't reinstallable: the GHC
> codebase directly wires in several definitions several functions, types,
> and data constructors from template-haskell. See THNames [1]. If one were
> to, say, use GHC 8.6 but install a different version of template-haskell
> than the one that came bundled with 8.6, then it's almost certain that lots
> of code in THNames would no longer work, since they could be referencing
> identifiers that no longer exist (if the new version of template-haskell
> doesn't have them).
>
> Right, I'm mostly concerned about re-installing the *same* version again.
> For the motivation:
> template-haskell depends on pretty, deepseq and array.  Let's assume there
> is some off-by-one issue
> in array that only affects my application right now.  Now I'm going to
> patch my array package, but
> if my application depends on template-haskell, I end up with two different
> array packages in my dependency
> tree that are not identical.  What I'd ideally like to do here is to
> re-install deepseq, pretty and
> template-haskell based on my fixed array package.  Now I don't have two
> different array packeds in my
> dependencies anymore; it would however require me to be able to rebuild
> (the same version) of template-haskell.
>
>
> > I have to admit I don't have a strong grasp on what "reinstallable"
> implies. Does a package get the same hash after reinstalling? What could
> make a package not reinstallable? Why aren't packages reinstallable today?
> Why isn't ghc-prim reinstallable?
>
> We can't re-install packages that depend on build-time values. The RTS and
> ghc-prim right now
> include files that are generated during the build process and they have no
> capability on their
> own to create those files, as such re-installing them is not possible
> right now.
>
> > My concern stems from the fact that ghc is interlinked with TH in at
> least two ways:
> > - GHC imports definitions from template-haskell. But this is the same as
> the way GHC is involved with, say, `base`.
> > - GHC also wires in some template-haskell definitions. This is the
> aspect I am worried about. Is `base` reinstallable? If so, then perhaps
> template-haskell could be, too.
>
>
> Now especially with TH I might see an issue when *running/using* TH, as at
> that point the compiler
> and the produces code have to interact.  That is we are compiling splices
> against a different
> template-haskell package than the compiler is built against.  This is
> where I see *upgrading* (that
> is building a newer version of Template Haskell) could be an issue, but I
> feel I don't fully grasp
> why rebuilding the same version should pose an issue.
>
> If we go one step further and use iserv (-fexternal-interpreter) outright,
> then I think we could just
> rebuild iserv against the re-installed template-haskell, and would not
> even run into the above
> mentioned issue. Might this potentially even be allow us to upgrade
> template-haskell?
>
> Cheers,
>  Moritz
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why can't we re-install the template-haskell package?

[Ryan Scott]

My (limited) understanding is that template-haskell is not reinstallable
for the same reasons that base and ghc-prim aren't reinstallable: the GHC
codebase directly wires in several definitions several functions, types,
and data constructors from template-haskell. See THNames [1]. If one were
to, say, use GHC 8.6 but install a different version of template-haskell
than the one that came bundled with 8.6, then it's almost certain that lots
of code in THNames would no longer work, since they could be referencing
identifiers that no longer exist (if the new version of template-haskell
doesn't have them).

Ryan S.
-
[1]
https://gitlab.haskell.org/ghc/ghc/blob/25c3dd39f7d446f66b5c967be81f80cd7facb509/compiler/prelude/THNames.hs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Haddock tree spongled

[Ryan Scott]

I do think something is afoot here. The current Haddock submodule commit is
at 07f2ca [1], but the ghc-head branch of Haddock is still at commit 8459c6
[2]. It would be good if someone could update the ghc-head branch
accordingly.

Ryan S.
-
[1]
https://github.com/haskell/haddock/commit/07f2ca98fd4249dc6ebad053bd6aef90c814efe0
[2]
https://github.com/haskell/haddock/commit/8459c600e0f6da3f85abefdefe651bbe3ed3da4a
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Testing GHC against Hackage via CI

[Ryan Scott]

This is fantastic work! I'm looking forward to using this.

Are there plans to merge GitLab's fork of head.hackage back into the
upstream repo [1]? I ask since I regularly submit patches to upstream, but
if the GitLab CI is using the fork, then it may take some time for upstream
changes to make their way back to the fork.

Ryan S.
-
[1] https://github.com/hvr/head.hackage
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: scopedSort and kind variable left-biasing

[Ryan Scott]

As Vlad notes in [1], getting rid of FreeKiTyVars isn't as simple as it
would appear, as we still treat kinds and types differently in other
places, such as data type declarations. For instance:

data Proxy (a :: k) = Proxy -- k is brought into scope implicitly by
`extractDataDefnKindVars`

I don't know how to overcome this awkwardness, so if you have suggestions,
please comment at [1].

Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/merge_requests/361#note_6709
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: scopedSort and kind variable left-biasing

[Ryan Scott]

Ah, I read over this part [1] of the ScopedSort specification too quickly:

* If variable v at the cursor is depended on by any earlier variable w,
  move v immediately before the leftmost such w.

I glossed over the "immediately" part, so I was under the impression that
as long as v appeared *somewhere* to the left of the leftmost w, then
everything was up to spec. But no, v can appear in one (and only one) place.

I was also looking in Note [ScopedSort], not the users' guide. Now that I
look at the users' guide, it specifically carves out an exception for
variables that appear in kind annotations [2]:

- If the type signature includes any kind annotations (either on
variable
  binders or as annotations on types), any variables used in kind
  annotations come before any variables never used in kind annotations.
  This rule is not recursive: if there is an annotation within an
annotation,
  then the variables used therein are on equal footing. Examples::

f :: Proxy (a :: k) -> Proxy (b :: j) -> ()
  -- as if f :: forall k j a b. ...

g :: Proxy (b :: j) -> Proxy (a :: (Proxy :: (k -> Type) -> Type)
Proxy) -> ()
  -- as if g :: forall j k b a. ...
  -- NB: k is in a kind annotation within a kind annotation

I can see the appeal behind dropping this exception, both from a
specification and an implementation point of view. It'll require a massive
breaking change, alas, but it just might be worth it. Unfortunately, the
proposal for merging type and kind variables in `forall`s [3] makes no
mention of this detail—I wonder if it is worth its own proposal.

Ryan S.
-
[1]
https://gitlab.haskell.org/ghc/ghc/blob/5c1f268e2744fab2d36e64c163858995451d7095/compiler/types/Type.hs#L2110-2111
[2]
https://gitlab.haskell.org/ghc/ghc/blob/5c1f268e2744fab2d36e64c163858995451d7095/docs/users_guide/glasgow_exts.rst#L10815-10826
[3]
https://github.com/ghc-proposals/ghc-proposals/blob/c3142c4a6f6abb90e53c2cac22b285991d0d0b3f/proposals/0024-no-kind-vars.rst

On Thu, Feb 14, 2019 at 2:04 PM Richard Eisenberg 
wrote:

>
>
> > On Feb 14, 2019, at 10:34 AM, Ryan Scott 
> wrote:
> >
> >  the answer [j,a,k,b]! Strictly speaking, this answer meets the
> specification of ScopedSort,
>
> I wish to point out that the specification of ScopedSort is very tight: it
> says exactly what we should get, given an input. This is important, because
> the behavior of ScopedSort is user-visible and must be stable. Another way
> of saying this: if we got [j,k,a,b], that would be wrong. Arguably, GHC's
> behavior w.r.t. type and kind variables is wrong because of its habit of
> putting kind variables first.
>
> Once we treat kind and type variables identically, I want to just rely on
> ScopedSort. That is, GHC should infer the order [j,a,k,b]. While I
> understand the aesthetic appeal of moving k before a, I think it's simpler
> and more uniform just to use ScopedSort. No exceptions!
>
> Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: scopedSort and kind variable left-biasing

[Ryan Scott]

Ah, I somehow forgot all about FreeKiTyVars. It turns out that the
`freeKiTyVarsAllVars` function [1] is exactly what drives this behavior:

freeKiTyVarsAllVars :: FreeKiTyVars -> [Located RdrName]
freeKiTyVarsAllVars (FKTV { fktv_kis = kvs, fktv_tys = tvs }) = kvs ++
tvs

That's about as straightforward as it gets. Thanks!

Ryan S.
-
[1]
https://gitlab.haskell.org/ghc/ghc/blob/5c1f268e2744fab2d36e64c163858995451d7095/compiler/rename/RnTypes.hs#L1604-1605

On Thu, Feb 14, 2019 at 12:46 PM Simon Peyton Jones 
wrote:

> See Note [Kind and type-variable binders] in RnTypes, and Note [Ordering
> of implicit variables].
>
> And the data type FreeKiTyVars.
>
>
>
> But NB: that in https://gitlab.haskell.org/ghc/ghc/merge_requests/361, I
> argue that with this patch we can sweep all this away.
>
>
>
> If we did, we’d probably end up with [j,a,k,b].
>
>
>
> Perhaps that’s an ergonomic reason for retaining the current rather
> cumbersome code.  (Maybe it could be simplified.)
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Ryan Scott
> *Sent:* 14 February 2019 15:35
> *To:* ghc-devs@haskell.org
> *Subject:* scopedSort and kind variable left-biasing
>
>
>
> Consider this function:
>
> f :: Proxy (a :: j) -> Proxy (b :: k)
>
> If you just collect the free type variables of `f`'s type in left-to-right
> order, you'd be left with [a,j,b,k]. But the type of `f` is not `forall (a
> :: j) j (b :: k) k. Proxy a -> Proxy b`, as that would be ill scoped. `j`
> must come before `a`, since `j` appears in `a`'s kind, and similarly, `k`
> must come before `b`.
>
> Fortunately, GHC is quite smart about sorting free variables such that
> they respect dependency order. If you ask GHCi what the type of `f` is
> (with -fprint-explicit-foralls enabled), it will tell you this:
>
> λ> :type +v f
> f :: forall j k (a :: j) (b :: k). Proxy a -> Proxy b
>
> As expected, `j` appears before `a`, and `k` appears before `b`.
>
> In a different context, I've been trying to implement a type variable
> sorting algorithm similar to the one that GHC is using. My previous
> understanding was that the entirely of this sorting algorithm was
> implemented in `Type.scopedSort`. To test my understanding, I decided to
> write a program using the GHC API which directly uses `scopedSort` on the
> example above:
>
> main :: IO ()
> main = do
>   let tv :: String -> Int -> Type -> TyVar
>   tv n uniq ty = mkTyVar (mkSystemName (mkUniqueGrimily uniq)
> (mkTyVarOcc n)) ty
>   j = tv "j" 0 liftedTypeKind
>   a = tv "a" 1 (TyVarTy j)
>   k = tv "k" 2 liftedTypeKind
>   b = tv "b" 3 (TyVarTy k)
>   sorted = scopedSort [a, j, b, k]
>   putStrLn $ showSDocUnsafe $ ppr sorted
>
> To my surprise, however, running this program does /not/ give the answer
> [j,k,a,b], like what :type reported:
>
> λ> main
> [j_0, a_1, k_2, b_3]
>
> Instead, it gives the answer [j,a,k,b]! Strictly speaking, this answer
> meets the specification of ScopedSort, since it respects dependency order
> and preserves the left-to-right ordering of variables that don't depend on
> each other (i.e., `j` appears to the left of `k`, and `a` appears to the
> left of `b`). But it's noticeably different that what :type reports. The
> order that :type reports, [j,k,a,b], appears to bias kind variables to the
> left such that all kind variables (`j` and `k`) appear before any type
> variables (`a` and `b`).
>
> From what I can tell, scopedSort isn't the full story here. That is,
> something else appears to be left-biasing the kind variables. My question
> is: which part of GHC is doing this left-biasing?
>
>
>
> Ryan S.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

scopedSort and kind variable left-biasing

[Ryan Scott]

Consider this function:

f :: Proxy (a :: j) -> Proxy (b :: k)

If you just collect the free type variables of `f`'s type in left-to-right
order, you'd be left with [a,j,b,k]. But the type of `f` is not `forall (a
:: j) j (b :: k) k. Proxy a -> Proxy b`, as that would be ill scoped. `j`
must come before `a`, since `j` appears in `a`'s kind, and similarly, `k`
must come before `b`.

Fortunately, GHC is quite smart about sorting free variables such that they
respect dependency order. If you ask GHCi what the type of `f` is (with
-fprint-explicit-foralls enabled), it will tell you this:

λ> :type +v f
f :: forall j k (a :: j) (b :: k). Proxy a -> Proxy b

As expected, `j` appears before `a`, and `k` appears before `b`.

In a different context, I've been trying to implement a type variable
sorting algorithm similar to the one that GHC is using. My previous
understanding was that the entirely of this sorting algorithm was
implemented in `Type.scopedSort`. To test my understanding, I decided to
write a program using the GHC API which directly uses `scopedSort` on the
example above:

main :: IO ()
main = do
  let tv :: String -> Int -> Type -> TyVar
  tv n uniq ty = mkTyVar (mkSystemName (mkUniqueGrimily uniq)
(mkTyVarOcc n)) ty
  j = tv "j" 0 liftedTypeKind
  a = tv "a" 1 (TyVarTy j)
  k = tv "k" 2 liftedTypeKind
  b = tv "b" 3 (TyVarTy k)
  sorted = scopedSort [a, j, b, k]
  putStrLn $ showSDocUnsafe $ ppr sorted

To my surprise, however, running this program does /not/ give the answer
[j,k,a,b], like what :type reported:

λ> main
[j_0, a_1, k_2, b_3]

Instead, it gives the answer [j,a,k,b]! Strictly speaking, this answer
meets the specification of ScopedSort, since it respects dependency order
and preserves the left-to-right ordering of variables that don't depend on
each other (i.e., `j` appears to the left of `k`, and `a` appears to the
left of `b`). But it's noticeably different that what :type reports. The
order that :type reports, [j,k,a,b], appears to bias kind variables to the
left such that all kind variables (`j` and `k`) appear before any type
variables (`a` and `b`).

>From what I can tell, scopedSort isn't the full story here. That is,
something else appears to be left-biasing the kind variables. My question
is: which part of GHC is doing this left-biasing?

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

Re: TTG: Handling Source Locations

[Ryan Scott]

Yes, I agree. This will require sprinkling the codebase with EmptyCase due
to [1], but that's still a sight better than calling `panic`. After GHC
8.10 is released (and the minimum version of GHC that HEAD supports is
8.8), we can even remove these empty cases by making the empty data type
fields strict (see [2]).

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/ticket/15247#comment:4
[2] https://ghc.haskell.org/trac/ghc/ticket/15305
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: TTG: Handling Source Locations

[Ryan Scott]

> Yes, I have reported it while back. I don't know of the progress in
fixing this.

Reported what? #15884? [1] You do realize that there is a very simple
workaround for that issue, right? Instead of writing this, which is subject
to the pattern-guard completeness issues observed in #15753:

f :: Maybe a -> Bool
f (id->Nothing)  = False
f (id->(Just _)) = True

You can instead write this:

f :: Maybe a -> Bool
f (id -> x) =
  case x of
Nothing -> False
Just _  -> True

This will get proper coverage checking, which means that this technique
could be used to remove all of the panicking catch-all cases brought about
by dL view patterns.

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/ticket/15884
[2] https://ghc.haskell.org/trac/ghc/ticket/15753
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for comments on dry-run Trac -> GitLab migration

[Ryan Scott]

There appears to be some impedance mismatches between GitLab's formatting
and Trac's formatting in certain places. For example, see the bottom of
this issue [1], which has a long, hyperlinked line with the phrase:


Icanproducethe`missinginstance`issuewithouthavingtorecompileGHC,whichiswhyIthinkitmightbeindependentofthisbug.

Ryan S.
-
[1] https://gitlab.staging.haskell.org/ghc/ghc/issues/16211
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

[Ryan Scott]

You *can* put `LL` into a COMPLETE set, but under the stipulation that
you specify which type constructor it's monomorphized to. To quote the
wiki page on COMPLETE sets:

In the case where all the patterns are polymorphic, a user must
provide a type signature but we accept the definition regardless of
the type signature they provide. The type constructor for the whole
set of patterns is the type constructor as specified by the user. If
the user does not provide a type signature then the definition is
rejected as ambiguous.

This design is a consequence of the design of the pattern match
checker. Complete sets of patterns must be identified relative to a
type. This is a sanity check as users would never be able to match on
all constructors if the set of patterns is inconsistent in this
manner.

In other words, this would work provided that you'd be willing to list
every single instance of `HasSrcSpan` in its own COMPLETE set. It's
tedious, but possible.

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs#Typing
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

[Ryan Scott]

The fact that `LL` can't be used in a COMPLETE pragma is a consequence
of its current design. Per the users' guide [1]:

To make things more formal, when the pattern-match checker
requests a set of constructors for some data type constructor T, the
checker returns:

* The original set of data constructors for T
* Any COMPLETE sets of type T

Note the use of the phrase *type constructor*. The return type of all
constructor-like things in a COMPLETE set must all be headed by the
same type constructor T. Since `LL`'s return type is simply a type
variable `a`, this simply doesn't work with the design of COMPLETE
sets.

But to be perfectly honest, I feel that trying to put `LL` into a
COMPLETE set is like putting a square peg into a round hole. The
original motivation for COMPLETE sets, as given in this wiki page [2],
is to support using pattern synonyms in an abstract matter—that is, to
ensure that users who match on pattern synonyms don't have any
internal implementation details of those pattern synonyms leak into
error messages. This is well and good for many use cases, but there
are also many use cases where we don't *care* about abstraction.
Sometimes, we simply define a pattern synonym to be a convenient
shorthand for a complicated pattern to facilitate code reuse, and
nothing more.

`LL` is a perfect example of this, in my opinion. `LL` is simply a
thin wrapper around the use of `decomposeSrcSpan` as a view pattern.
Trying to put `LL` into a COMPLETE set is silly since our intention
isn't to hide the implementation details of decomposing a `SrcSpan`,
but rather to avoid the need to copy-paste `(decomposeSrcSpan -> (m ,
s))` in a bazillion patterns. Correspondingly, any use of `LL` ought
to be treated as if the `(decomposeSrcSpan -> (m , s))` pattern were
inlined—and from the pattern-match coverage checker's point of view,
that *is* exhaustive!

What's the moral of the story here? To me, this is a sign that the
design space of pattern synonym coverage checking isn't rich enough.
In addition to the existing {-# COMPLETE #-} machinery that we have
today, I think we need to have a separate pragma for pattern synonyms
that are intended to be transparent, non-abstract wrappers around
patterns ({-# TRANSPARENT #-}, perhaps).

Ryan S.
-
[1] 
https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/glasgow_exts.html#complete-pragma
[2] https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unpacking coercions

[Ryan Scott]

> We could utterly lie and say
>
>   data Coercion a b where
>
>   Coercion :: Coercion a a
>
>
>
> That would generate the right bits in in the .o file, and we’d totally
ignore the .hi file.  Gruesome but I think it would work.

This was precisely what I had in mind. We already perform this trick for
several things defined in ghc-prim (e.g., the (~) and (~~) classes), so
this would just be another example of that.

> But rather than all this circumlocution, why don’t we just make it
possible to write ~# and ~R# directly.  Even if we dodge the need right
now, it’ll surely come back.

Hah, the reason David is suggesting his idea in the first place is to avoid
having to do this! My understanding is that making it possible to write
(~#) and (~R#) directly would involve quite a number of complications, as
Richard's wiki entry on the subject [1] demonstrates.

That's not to say that I wouldn't like to see that happen some day. But a
mere mortal like myself couldn't possibly implement this, whereas David's
idea is actually within reach.

Ryan S.
-
[1]
https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Liftedvs.Unliftedequality

On Wed, Sep 5, 2018 at 10:45 AM, Simon Peyton Jones 
wrote:

> I think the intention is to have that proposal (which proposes a language
> change) be superseded by this idea (which does not change the language).
>
> Oh, I did not know that.   I’ll ignore the proposal for now, in that case.
>
>
>
> All that would take is putting Coercion in TysWiredIn, and moving Coercion
> from Data.Type.Coercion to somewhere in ghc-prim.
>
>
>
> I don’t think it’s quite as simple as that.  Yes, we can wire it into the
> compiler; but we still need a module that defines the info table, curried
> data constructor etc for the type.  And we have no way to do that.
>
>
>
> We could utterly lie and say
>
>   data Coercion a b where
>
>   Coercion :: Coercion a a
>
>
>
> That would generate the right bits in in the .o file, and we’d totally
> ignore the .hi file.  Gruesome but I think it would work.
>
>
>
>
>
> But rather than all this circumlocution, why don’t we just make it
> possible to write ~# and ~R# directly.  Even if we dodge the need right
> now, it’ll surely come back.
>
>
>
> If that is lexically tiresome, we could I suppose provide builtin-aliases
> for them, as if we had
>
>   type NomEq# = (~#)
>
>  type ReprEq# = (~R#)
>
>
>
> Simon
>
>
>
> *From:* Ryan Scott 
> *Sent:* 05 September 2018 15:26
> *To:* Simon Peyton Jones 
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Unpacking coercions
>
>
>
> > Simple is good.  But what is this dead simple idea?
>
>
>
> I'm referring to David's first e-mail on this thread:
> https://mail.haskell.org/pipermail/ghc-devs/2018-September/016191.html
>
>
>
> All that would take is putting Coercion in TysWiredIn, and moving Coercion
> from Data.Type.Coercion to somewhere in ghc-prim.
>
>
>
> > Maybe this thread belongs with the proposal, unless I’m
> misunderstanding.
>
>
>
> I think the intention is to have that proposal (which proposes a language
> change) be superseded by this idea (which does not change the language).
>
>
>
> Ryan S.
>
>
>
>
>
> On Wed, Sep 5, 2018 at 10:20 AM, Simon Peyton Jones 
> wrote:
>
> Simple is good.  But what is this dead simple idea?
>
>
>
> Perhaps: https://github.com/ghc-proposals/ghc-proposals/pull/116
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F116&data=02%7C01%7Csimonpj%40microsoft.com%7Cab6e886b24b548eab26608d6133b91b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636717543898919689&sdata=XKBwJiLM%2FcH5FeRLuodH3SKXQUppYT0QYDojH4fO7Tg%3D&reserved=0>
>
> But that proposal lists several possible alternatives.  Which one did you
> mean?
>
>
>
> And all of them are language changes. Making evidence strict would require
> no language changes to solve the original problem.
>
>
>
> Maybe this thread belongs with the proposal, unless I’m misunderstanding.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Ryan Scott
> *Sent:* 05 September 2018 15:15
> *To:* ghc-devs@haskell.org
> *Subject:* Re: Unpacking coercions
>
>
>
> These aren't mutually exclusive ideas. While I'm sure there's many ways we
> could solve this problem, David's idea has the distinct advantage of being
> dead simple. I'd rather not block his vision on some other large refactor
> that may never materialize. (And if it _does_ materialize, we could revert
> any wiring-in of Coercible quite easily.)
>
>
>
> Ryan S.
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Running GHC 7.10.2 on Ubuntu 18.04 ?

[Ryan Scott]

This is likely caused by an old GHC bug that interacts poorly with newer
version of binutils (I can't remember the exact bug, unfortunately).

I personally use hvr's Ubuntu PPA [1] whenever installing GHC on Ubuntu.
This PPA backports patches to old versions of GHC to keep them working with
newer versions of binutils, and I can confirm that the version of GHC
7.10.2 offered from here works well with Ubuntu 18.04.

Ryan S.
-
[1] https://launchpad.net/~hvr/+archive/ubuntu/ghc
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unpacking coercions

[Ryan Scott]

> Simple is good.  But what is this dead simple idea?

I'm referring to David's first e-mail on this thread:
https://mail.haskell.org/pipermail/ghc-devs/2018-September/016191.html

All that would take is putting Coercion in TysWiredIn, and moving Coercion
from Data.Type.Coercion to somewhere in ghc-prim.

> Maybe this thread belongs with the proposal, unless I’m misunderstanding.

I think the intention is to have that proposal (which proposes a language
change) be superseded by this idea (which does not change the language).

Ryan S.


On Wed, Sep 5, 2018 at 10:20 AM, Simon Peyton Jones 
wrote:

> Simple is good.  But what is this dead simple idea?
>
>
>
> Perhaps: https://github.com/ghc-proposals/ghc-proposals/pull/116
>
> But that proposal lists several possible alternatives.  Which one did you
> mean?
>
>
>
> And all of them are language changes. Making evidence strict would require
> no language changes to solve the original problem.
>
>
>
> Maybe this thread belongs with the proposal, unless I’m misunderstanding.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Ryan Scott
> *Sent:* 05 September 2018 15:15
> *To:* ghc-devs@haskell.org
> *Subject:* Re: Unpacking coercions
>
>
>
> These aren't mutually exclusive ideas. While I'm sure there's many ways we
> could solve this problem, David's idea has the distinct advantage of being
> dead simple. I'd rather not block his vision on some other large refactor
> that may never materialize. (And if it _does_ materialize, we could revert
> any wiring-in of Coercible quite easily.)
>
>
>
> Ryan S.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unpacking coercions

[Ryan Scott]

These aren't mutually exclusive ideas. While I'm sure there's many ways we
could solve this problem, David's idea has the distinct advantage of being
dead simple. I'd rather not block his vision on some other large refactor
that may never materialize. (And if it _does_ materialize, we could revert
any wiring-in of Coercible quite easily.)

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

Does tyCoVarsOfTypesList guarantee a particular order?

[Ryan Scott]

tyCoVarsOfTypesList guarantees that it returns its answer in a
deterministic order. For the longest time, I must have assumed that this
order was left to right. However, it appears that my assumption was wrong!
This can be demonstrated with this program:
module Main where

import Name
import TyCoRep
import TysPrim
import Var

main :: IO ()
main = do
  putStrLn "(1)"
  print $ map (getOccString . tyVarName)
$ tyCoVarsOfTypesList
  [TyVarTy alphaTyVar, TyVarTy betaTyVar]

  putStrLn "(2)"
  print $ map (getOccString . tyVarName)
$ tyCoVarsOfTypesList
  [TyVarTy alphaTyVar, TyVarTy betaTyVar, TyVarTy alphaTyVar]

This gives the following output:

(1)
["a","b"]
(2)
["b","a"]

The first one makes total sense to me. The second, one however, does not.
If the free variables of that list were returned in left-to-right order (or
even right-to-left order!), then (2) should give the same answer as (1).
Instead, it lists "b" _before_ "a", which I find incredibly baffling.

To explain why I care so much about this, we're currently trying to improve
Haddock's logic for choosing when to put explicit `forall`s in front of
types [1]. Our litmus test is this: if the order in which a user wrote the
`forall`d variables differs from the order in which the free variables of
the body would normally occur, then have Haddock display an explicit
forall. I would have assumed that tyCoVarsOfTypesList [2] would be enough
to determine the "normal" order of the free variables, but as the example
above proves, this sometimes gives unexpected orderings when there are
multiple occurrences of the same variable.

We are currently having to work around this issue [1] by implementing our
own custom versions of tyCoFVsOfType and friends that accumulate variables
in reverse order (and then reversing the list at the end!) to get the order
we expect. This feels incredibly wasteful to me, so I'd like to know if
there's a better way. In particular:

1. Is this behavior of tyCoVarsOfTypesList expected?
2. If not, should we change it?

Ryan S.
-
[1] See https://github.com/haskell/haddock/pull/931
[2] Actually, I would use tyCoVarsOfTypesWellScoped, but dependency order
doesn't come into play in the example I gave above.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unpacking coercions

[Ryan Scott]

In case this wasn't clear, the context of this discussion in this GHC
proposal [1], where David is trying to work around the fact that data types
with existential Coercible constraints do not support unpacking. (By
"unpacking", I mean putting an {-# UNPACK #-} pragma in front of a field of
that type does what you would expect.)

An example program which demonstrates the performance issue can be found
here [2]. That comment concerns unboxed equality vs. boxed equality, but
the same unpacking problems that affect boxed equality also affect
Coercible.

Ryan S.
-
[1] https://github.com/ghc-proposals/ghc-proposals/pull/116
[2]
https://github.com/ghc-proposals/ghc-proposals/pull/116#issuecomment-382346662
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unpacking coercions

[Ryan Scott]

If we can gain some performance from this, then I'm generally supportive of
this idea.

I'm still of the belief that we could teach GHC to unpack boxed equality
constraints, but your idea would definitely be the simpler one to implement.

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

Re: Bump base version

[Ryan Scott]

Everything that ships with a pre-release version of GHC is ultimately
subject to change before its final release, and that includes the libraries
that it ships with, too. In the case of the base library, the version that
GHC 8.6.1-beta ships with (4.12.0.0) doesn't yet correspond to any version
number released on Hackage, so one can think of the base-4.12.0.0 shipped
with GHC 8.6.1-beta being itself a form of beta release. Importantly, that
means we can change it if necessary before the final base-4.12.0.0 Hackage
release (which usually coincides with the final GHC 8.6.1 release).

Ryan S.

On Sun, Aug 26, 2018 at 11:04 PM, David Feuer  wrote:

> On Sunday, August 26, 2018 9:54:09 AM EDT Ryan Scott wrote:
> > I'm confused. base-4.12.0.0 hasn't been released yet, so can't we just
> make
> > this StableName change a part of 4.12.0.0?
> >
> > (Regardless of what we choose, we should make sure to advertise this
> change
> > in base's changelog—currently it's unmentioned.)
> >
> > Ryan S.
>
> I don't know what the policy is, to be honest! Is an alpha version a
> "real" version,
> whose base library has its own version number? Or is it a version that is
> expected
> to disappear as soon as the beta or full release comes out?
>
> --
> David Feuer
> Well-Typed
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Bump base version

[Ryan Scott]

I'm confused. base-4.12.0.0 hasn't been released yet, so can't we just make
this StableName change a part of 4.12.0.0?

(Regardless of what we choose, we should make sure to advertise this change
in base's changelog—currently it's unmentioned.)

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

Re: [ANNOUNCE] GHC 8.6.1-alpha2 available

[Ryan Scott]

Presumably, you're compiling this program outside of a git repository,
and so the Template Haskell splice $(gitHash) evaluates to "UNKNOWN"
at compile time. Here is an even more minimal example, which does not
depend on gitrev:

f :: ()
f = case "UNKNOWN" of
  "UNKNOWN" -> ()
  _ -> ()

This, when compiled with GHC 8.6.1 or later, gives the same warning:

Test.hs:4:7: warning: [-Woverlapping-patterns]
Pattern match is redundant
In a case alternative: _ -> ...
  |
4 |   _ -> ()
  |   ^^^

This, I would argue, is a correct error message. The string literal
"UNKNOWN" is, well, statically known to be "UNKNOWN", so GHC knows
that that catch-all case cannot be reached. (See [1] for the commit
which introduced this check.)

Granted, this makes things slightly inconvenient for your purposes,
since in your actual program, $(gitHash) might evaluate to *different*
things at compile time depending on the directory you compile it in.
I'd recommend rewriting the commitInfo function to pattern guards:

commitInfo :: Maybe String
commitInfo
  | hash == "UNKNOWN" = Nothing
  | otherwise = Just hash
  where
hash = $(gitHash)

Since that does not trigger -Woverlapping-patterns. (Granted, it's
possible that GHC could become much smarter in the future and be able
to detect that that `otherwise` case is unreachable when $(gitHash)
evaluates to "UNKNOWN" at compile time. But GHC certainly isn't that
smart today!)

Ryan S.
-
[1] 
http://git.haskell.org/ghc.git/commit/1f88f541aad1e36d01f22f9e71dfbc247e6558e2
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How do I make a constraint tuple in Core?

[Ryan Scott]

> Can you be a bit more precise about what you are doing? Constructing
> core like this is quite hairy.

I'm modifying TcGenGenerics to use an experimental representation type that
leverages ConstraintKinds (and thus constraint tuples) in its type. The
function I'm modifying is tc_mkRepTy [1], which constructs the Core Type
that's used for Rep/Rep1 in derived Generic instances.

> The "tuple" part doesn't really exist in core

Sure it does! It does in this code, at least:

data Foo c a where
  MkFoo :: c => a -> Foo c a

f :: Foo (Eq a, Show a) -> String
f (MkFoo x) = show x

According to ghci -ddump-simpl, that gives you the following (unoptimized)
Core:

f :: forall a. Foo (Eq a, Show a) a -> String
f = \ (@ a_a2RQ)
  (ds_d2S2 :: Foo (Eq a_a2RQ, Show a_a2RQ) a_a2RQ) ->
  case ds_d2S2 of { MkFoo $d(%,%)_a2RS x_a2Ry ->
  show
@ a_a2RQ
(GHC.Classes.$p2(%,%) @ (Eq a_a2RQ) @ (Show a_a2RQ)
$d(%,%)_a2RS)
x_a2Ry
  }

Notice the $d(%,%)_a2RS and $p2(%,%) bits, which correspond to a constraint
tuple dictionary and one of its superclass selectors, respectively.

Ryan S.
-
[1]
http://git.haskell.org/ghc.git/blob/26e9806ada8823160dd63ca2c34556e5848b2f45:/compiler/typecheck/TcGenGenerics.hs#l513


On Tue, Jun 19, 2018 at 1:09 PM Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> Can you be a bit more precise about what you are doing? Constructing
> core like this is quite hairy.
>
> The "tuple" part doesn't really exist in core, a constraint tuple is
> curried. So foo :: (C1 a, C2 a) => ... desugars to `foo = /\ a . \
> $dC1 . \$dC2 -> ...`.
>
> Cheers,
>
> Matt
>
>
>
> On Tue, Jun 19, 2018 at 4:48 PM, Ryan Scott 
> wrote:
> > Unfortunately, I can't directly use tc_tuple, since I don't have access
> to
> > the Haskell AST forms I need to make that work (I'm constructing
> everything
> > directly in Core). On the other hand, the implementation of tc_tuple does
> > have one nugget of wisdom in that it reveals how GHC creates a constraint
> > tuple *type constructor*. Namely, `tcLookupTyCon (cTupleTyConName arity)`
> > for some `arity`.
> >
> > That's still a bit inconvenient, as `tcLookupTyCon` forces me to work in
> a
> > monadic context (whereas the code I've been working on has been pure up
> to
> > this point). Is there not a pure way to retrieve a constraint tuple type
> > constructor?
> >
> > Ryan S.
> >
> > On Tue, Jun 19, 2018 at 10:07 AM Matthew Pickering
> >  wrote:
> >>
> >> How about `tc_tuple`?
> >>
> >> On Tue, Jun 19, 2018 at 2:53 PM, Ryan Scott 
> >> wrote:
> >> > I'm currently working on some code in which I need to produce a Core
> >> > Type
> >> > that mentions a constraint tuple. I thought that there must surely
> exist
> >> > some way to construct a constraint tuple using the GHC API, but to my
> >> > astonishment, I could not find anything. The closest thing I found was
> >> > mk_tuple [1], which gives you the ability to make boxed and unboxed
> >> > tuples,
> >> > but not constraint tuples.
> >> >
> >> > I then thought to myself, "But wait, PartialTypeSignatures has to
> create
> >> > constraint tuples, right? How does that part of the code work?" To my
> >> > horror, I discovered that PartialTypeSignatures actually creates
> *boxed*
> >> > tuples (see mk_ctuple here [2]), then hackily treats them as
> constraint
> >> > tuples, as explained in Note [Extra-constraint holes in partial type
> >> > signatures] [3]. I tried reading that Note, but I couldn't follow the
> >> > details.
> >> >
> >> > Is there a simpler way to create a constraint tuple that I'm not aware
> >> > of?
> >> >
> >> > Ryan S.
> >> > -
> >> > [1]
> >> >
> >> >
> http://git.haskell.org/ghc.git/blob/676c5754e3f9e1beeb5f01e0265ffbdc0e6f49e9:/compiler/prelude/TysWiredIn.hs#l810
> >> > [2]
> >> >
> >> >
> http://git.haskell.org/ghc.git/blob/676c5754e3f9e1beeb5f01e0265ffbdc0e6f49e9:/compiler/typecheck/TcBinds.hs#l1036
> >> > [3]
> >> >
> >> >
> http://git.haskell.org/ghc.git/blob/676c5754e3f9e1beeb5f01e0265ffbdc0e6f49e9:/compiler/typecheck/TcHsType.hs#l2367
> >> >
> >> > ___
> >> > 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: How do I make a constraint tuple in Core?

[Ryan Scott]

Unfortunately, I can't directly use tc_tuple, since I don't have access to
the Haskell AST forms I need to make that work (I'm constructing everything
directly in Core). On the other hand, the implementation of tc_tuple does
have one nugget of wisdom in that it reveals how GHC creates a constraint
tuple *type constructor*. Namely, `tcLookupTyCon (cTupleTyConName arity)`
for some `arity`.

That's still a bit inconvenient, as `tcLookupTyCon` forces me to work in a
monadic context (whereas the code I've been working on has been pure up to
this point). Is there not a pure way to retrieve a constraint tuple type
constructor?

Ryan S.

On Tue, Jun 19, 2018 at 10:07 AM Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> How about `tc_tuple`?
>
> On Tue, Jun 19, 2018 at 2:53 PM, Ryan Scott 
> wrote:
> > I'm currently working on some code in which I need to produce a Core Type
> > that mentions a constraint tuple. I thought that there must surely exist
> > some way to construct a constraint tuple using the GHC API, but to my
> > astonishment, I could not find anything. The closest thing I found was
> > mk_tuple [1], which gives you the ability to make boxed and unboxed
> tuples,
> > but not constraint tuples.
> >
> > I then thought to myself, "But wait, PartialTypeSignatures has to create
> > constraint tuples, right? How does that part of the code work?" To my
> > horror, I discovered that PartialTypeSignatures actually creates *boxed*
> > tuples (see mk_ctuple here [2]), then hackily treats them as constraint
> > tuples, as explained in Note [Extra-constraint holes in partial type
> > signatures] [3]. I tried reading that Note, but I couldn't follow the
> > details.
> >
> > Is there a simpler way to create a constraint tuple that I'm not aware
> of?
> >
> > Ryan S.
> > -
> > [1]
> >
> http://git.haskell.org/ghc.git/blob/676c5754e3f9e1beeb5f01e0265ffbdc0e6f49e9:/compiler/prelude/TysWiredIn.hs#l810
> > [2]
> >
> http://git.haskell.org/ghc.git/blob/676c5754e3f9e1beeb5f01e0265ffbdc0e6f49e9:/compiler/typecheck/TcBinds.hs#l1036
> > [3]
> >
> http://git.haskell.org/ghc.git/blob/676c5754e3f9e1beeb5f01e0265ffbdc0e6f49e9:/compiler/typecheck/TcHsType.hs#l2367
> >
> > ___
> > 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

How do I make a constraint tuple in Core?

[Ryan Scott]

I'm currently working on some code in which I need to produce a Core Type
that mentions a constraint tuple. I thought that there must surely exist
some way to construct a constraint tuple using the GHC API, but to my
astonishment, I could not find anything. The closest thing I found was
mk_tuple [1], which gives you the ability to make boxed and unboxed tuples,
but not constraint tuples.

I then thought to myself, "But wait, PartialTypeSignatures has to create
constraint tuples, right? How does that part of the code work?" To my
horror, I discovered that PartialTypeSignatures actually creates *boxed*
tuples (see mk_ctuple here [2]), then hackily treats them as constraint
tuples, as explained in Note [Extra-constraint holes in partial type
signatures] [3]. I tried reading that Note, but I couldn't follow the
details.

Is there a simpler way to create a constraint tuple that I'm not aware of?

Ryan S.
-
[1]
http://git.haskell.org/ghc.git/blob/676c5754e3f9e1beeb5f01e0265ffbdc0e6f49e9:/compiler/prelude/TysWiredIn.hs#l810
[2]
http://git.haskell.org/ghc.git/blob/676c5754e3f9e1beeb5f01e0265ffbdc0e6f49e9:/compiler/typecheck/TcBinds.hs#l1036
[3]
http://git.haskell.org/ghc.git/blob/676c5754e3f9e1beeb5f01e0265ffbdc0e6f49e9:/compiler/typecheck/TcHsType.hs#l2367
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: -fghci-leak-check apparently causes many tests to fail

[Ryan Scott]

> If you're seeing errors from this, then we should fix them.  Could you
open a ticket and assign to me please?

I've opened Trac #15246 [1] for this.

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/ticket/15246

On Thu, Jun 7, 2018 at 4:34 PM, Simon Marlow  wrote:

> Sorry, only just saw this. -fghci-leak-check is a new flag I added to
> prevent regressions of the space leak that was fixed in
> https://phabricator.haskell.org/D4659
>
> If you're seeing errors from this, then we should fix them.  Could you
> open a ticket and assign to me please?
>
> Cheers
> Simon
>
> On 1 June 2018 at 11:57, Ryan Scott  wrote:
>
>> One thing I forgot to mention is that these test failures only seem to
>> occur with the `quick` build flavor, and I couldn't reproduce them with
>> ./validate. Is -fghci-leak-check expected to have different behavior if
>> stage-2 GHC is built without optimization?
>>
>> Ryan S.
>>
>> ___
>> 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: -fghci-leak-check apparently causes many tests to fail

[Ryan Scott]

One thing I forgot to mention is that these test failures only seem to
occur with the `quick` build flavor, and I couldn't reproduce them with
./validate. Is -fghci-leak-check expected to have different behavior if
stage-2 GHC is built without optimization?

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

-fghci-leak-check apparently causes many tests to fail

[Ryan Scott]

I recently ran the testsuite and experienced a very large number of
testsuite failures, all of which seem to involve the new -fghci-leak-check
flag. Here is the list of tests that fail:

Unexpected failures:
   ghci/prog001/prog001.runprog001 [bad stdout] (ghci)
   ghci/prog002/prog002.runprog002 [bad stdout] (ghci)
   ghci/prog003/prog003.runprog003 [bad stdout] (ghci)
   ghci/prog010/ghci.prog010.run   ghci.prog010 [bad stdout] (ghci)
   ghci/prog013/prog013.runprog013 [bad stdout] (ghci)
   ghci/prog012/prog012.runprog012 [bad stdout] (ghci)
   ghci/prog009/ghci.prog009.run   ghci.prog009 [bad stdout] (ghci)
   ghci/scripts/ghci025.runghci025 [bad stdout] (ghci)
   ghci/scripts/ghci038.runghci038 [bad stdout] (ghci)
   ghci/scripts/ghci057.runghci057 [bad stdout] (ghci)
   ghci/scripts/T2182ghci.run  T2182ghci [bad stdout] (ghci)
   ghci/scripts/ghci058.runghci058 [bad stdout] (ghci)
   ghci/scripts/T6106.run  T6106 [bad stdout] (ghci)
   ghci/scripts/T8353.run  T8353 [bad stdout] (ghci)
   ghci/scripts/T9293.run  T9293 [bad stdout] (ghci)
   ghci/scripts/T10989.run T10989 [bad stdout] (ghci)
   ghci/should_run/T13825-ghci.run T13825-ghci [bad stdout] (ghci)
   ghci.debugger/scripts/print007.run  print007 [bad stdout] (ghci)
   ghci.debugger/scripts/break009.run  break009 [bad stdout] (ghci)
   ghci.debugger/scripts/break008.run  break008 [bad stdout] (ghci)
   ghci.debugger/scripts/break026.run  break026 [bad stdout] (ghci)
   perf/space_leaks/T4029.run  T4029 [bad stdout] (ghci)

And the full failing test output can be found here [1]. (I won't post it
inline, since it's quite large).

Are these changes expected? I'm not at all familiar with -fghci-leak-check,
so I don't know if we should accept the new output or not.

Ryan S.
-
[1]
https://gist.githubusercontent.com/RyanGlScott/f920737287049b82947e1c47cdbc2b94/raw/4fe68d47cc78675424e09cf451be556c6f430d08/gistfile1.txt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Plan for GHC 8.6.1

[Ryan Scott]

I have one major feature planned: -XDerivingVia. I haven't made a
patch yet, since the idea itself is still technically going through
the proposal process at [1]. But the feedback seems pretty positive,
so I think I'll submit it to the committee next week for final
consideration.

There is an implementation that's 99% already at [2], so there
shouldn't be much of a delay in getting it to Phabricator once the
committee gives the go-ahead.

Ryan S.
-
[1] https://github.com/ghc-proposals/ghc-proposals/pull/120
[2] https://github.com/RyanGlScott/ghc/tree/deriving-via-8.5
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC extensions

[Ryan Scott]

Hi Peter,

> What does exactly happen if an extension is needed for a certain language 
> element, but it is not present?

Generally, these manifest as runtime checks of the form (xopt
LangExt.TheLanguageExtensionName dflags). For an example, see [1],
where GHC checks if the TypeFamilyDependencies extension is enabled,
and if not, subsequently throws an error.

> Does the type checker still continue its business after encountering such an 
> error; or does it stop, and dump its the error messages?

It depends. Sometimes, GHC uses the addErrTc function to add an error
but not cause an outright failure, continuing until there is a fatal
error. The failWithTc function, on the other hand, adds an error and
causes GHC to exit, reporting all errors it's collected up to that
point. (The example in [1] does this.)

Ryan S.
-
[1] 
http://git.haskell.org/ghc.git/blob/5d76846405240c051b00cddcda9d8d02c880968e:/compiler/typecheck/TcTyClsDecls.hs#l1097
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.4.1 released

[Ryan Scott]

I've submitted a Diff [1] for this.

Ryan S.
-
[1] https://phabricator.haskell.org/D4586
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.4.1 released

[Ryan Scott]

Thanks, Ben.

It looks like the version number for base has not been bumped to
4.11.1.0, despite incorporating this commit [1] which introduces
readFieldHash to base. Currently, this makes it impossible to guard
against the existence of the readFieldHash function in a project I'm
working on.

Ryan S.
-
[1] 
http://git.haskell.org/ghc.git/commit/d5577f44eaf3b9dfdfc77828038782bf818c176a
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 8.5 build failure

[Ryan Scott]

I've just landed a commit of Ben's [1] which should fix this issue.

Ryan S.
-
[1] Specifically,
http://git.haskell.org/ghc.git/commit/54acfbbf64f5fcb108836412e9be0cfabf0d7801
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.4.1-alpha2 available

[Ryan Scott]

Forgive me if I'm stating the obvious here, but the status of libraries
like primitive, unordered-containers, and haskell-src-exts don't really
have anything to do with GHC, since they're independent libraries that
aren't shipped with GHC in any way.

If you're impatient to use the Haskell library ecosystem with GHC 8.4.1, I
highly encourage you to use a solution like head.hackage [1], as many
library authors are not as much of early adopters as we are :)

Ryan S.
-
[1] https://github.com/hvr/head.hackage
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.2.2 release candidate 2

[Ryan Scott]

I built all of Stackage with this RC the other night and didn't observe any
regressions. Hooray!

(Thanks to Doug Wilson for helping me get set up with his
https://github.com/duog/build-stackage repo.)

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

Re: [ANNOUNCE] GHC 8.2.2 release candidate 1

[Ryan Scott]

I would have guessed that it's actually due to #11963 [1], and
consequently, this [2] backported patch.

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/ticket/11963
[2]
http://git.haskell.org/ghc.git/commit/18dee8912f6afdcf13073d3d95d85513c14180e3

On Oct 1, 2017 21:19, "Ben Gamari"  wrote:

> Ryan Scott  writes:
>
> > I did a smoke test of Stackage Nightly's libraries [1] this afternoon
> using
> > GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and
> > protolude-0.2, due to a change where type signatures like `foo :: forall
> k.
> > forall (a :: k). ...` no longer compile without enabling TypeInType.
> >
> > I only mention this because the migration guide for 8.4 [2] currently
> gives
> > the impression that this TypeInType change won't land until GHC 8.4. This
> > doesn't appear to be case, though!
> >
> It sounds like you are describing #13391. If this is the case then I'm
> rather confused since I didn't merge the associated patch. Something
> else must be going on here. Perhaps some other patch made the checks a
> bit more strict inadvertently?
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC HEAD now needs extra tools to build libffi?

[Ryan Scott]

Trying to build a fresh copy of GHC HEAD (at commit [1]) today failed
for me with this error: [2]

/u/rgscott/Software/ghc4/libffi/build/missing: line 81: makeinfo:
command not found
WARNING: 'makeinfo' is missing on your system.
 You should only need it if you modified a '.texi' file, or
 any other file indirectly affecting the aspect of the manual.
 You might want to install the Texinfo package:
 
 The spurious makeinfo call might also be the consequence of
 using a buggy 'make' (AIX, DU, IRIX), in which case you might
 want to install GNU make:
 

On my Ubuntu machine, I was able to work around the issue by running:

apt-get install texinfo

But I'm not sure if the texinfo requirement was expected or an
unintended side effect of recent libffi changes. Do you know what's
happening here Moritz?

Best,
Ryan S.
-
[1] 
http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
[2] http://lpaste.net/6716863452582772736
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.2.2 release candidate 1

[Ryan Scott]

I did a smoke test of Stackage Nightly's libraries [1] this afternoon using
GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and
protolude-0.2, due to a change where type signatures like `foo :: forall k.
forall (a :: k). ...` no longer compile without enabling TypeInType.

I only mention this because the migration guide for 8.4 [2] currently gives
the impression that this TypeInType change won't land until GHC 8.4. This
doesn't appear to be case, though!

Ryan S.
-
[1] https://www.stackage.org/nightly-2017-09-29
[2]
https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4?version=7#TypeInTypeispickier
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why isn't this Typeable?

[Ryan Scott]

Trying to conclude Typeable Foo (or, if expanded with
-fprint-explicit-kinds, Typeable ((forall a. a -> Maybe a) -> Type)
Foo) is beyond GHC's capabilities at the moment, as that would require
impredicative polymorphism. This problem has arose in other contexts
too—see Trac #13895 [1] for one example.

I don't think you can conclude Typeable (Foo 'Just) either, since that
requires concluding both Typeable Foo and Typeable 'Just, so you
ultimately run into the same problem.

While there an in-the-works plan to allow a limited form of
impredicativity through explicit use of visible type application [2],
my fear is that that wouldn't be enough to address the problem you've
encountered, since there's no way to visibly apply @((forall a. a ->
Maybe a) -> Type) to Typeable at the moment. To accomplish this, you
would need visible kind application [3].

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/ticket/13895
[2] https://ghc.haskell.org/trac/ghc/ticket/11319#comment:11
[3] https://ghc.haskell.org/trac/ghc/ticket/12045
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Type-level generics

[Ryan Scott]

If you're willing to go a completely different route from
GHC.Generics, then you might be interested in the paper Generic
Programming with Multiple Parameters [1] (whose existence I just
learned of—thanks to Pedro, the author, for pointing it out to me). It
does present a single Generic class that is capable of working over
any number of type parameters, although the interface presented is
significantly more complex than the current GHC.Generics.

The only reason I mention backwards compatibility is that if we are
going to introduce a GHC.Generics 2.0 some day, it'd be nice to have a
way to subsume the old interface with the new one, and fortunately,
the aforementioned paper includes an algorithm for doing so. My hope
was that we'd be able to incorporate these ideas into a design that
also grants the ability to write Generic instances for GADTs, but I
don't think GHC has a fancy enough type system to do this
satisfactorily at the moment.

Ryan S.
-
[1] http://dreixel.net/research/pdf/gpmp_colour.pdf
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Type-level generics

[Ryan Scott]

Several good points were brought up. Let me go through them and try to
make sense of what I can:

> When I looked at it the last time, there were some apparent leftovers in the 
> form of types or type parameters never used.

Are you referring to the `p` type parameters that are found in most of
the data types in GHC.Generics? If so, they are most definitely
used—try deriving Generic1 to see this in action! It's true that in
the context of Generic (without the 1 at the end) the `p` isn't used,
but this is by design, as this allows us to share the same
representation types across Generic and Generic1.

> there is no possibility to work with types with more than one parameter.

Quite true. But I posit that engineering GHC.Generics to work with
more than one type parameter at a time is much harder than it sounds.
After all, to profitably work with even a *single* type parameter
(what Generic1 does), we must bring in three additional representation
types: Par1, Rec1, and (:.:), depending on where in the datatype the
last type parameter occurs. If we wanted to have, say, Generic2, we'd
similarly need to be able to work with many more combinations of type
parameter positions, such as:

* data Foo1 a b = Foo1 a b
* data Foo2 a b = Foo2 (Either a b)
* data Foo3 a b = Foo3 (Either b a)
* etc.

A naïve approach would be to tack on another type parameter at the end
of every representation type, and introduce more types to deal with
all the combinations of the first and second type parameter that could
arise. But this approach doesn't scale well—after all, at what number
N do you stop introducing new representation types? So extending
GHC.Generics to deal with more than one type parameter is far from
obvious to me (let alone whether it could be made backwards compatible
with the current API).

> the GHC.Generics module looks a bit unpolished and ad-hoc at the moment.

Yes, quite literally everything in GHC.Generics is one large, ad hoc
hack. But it's also a darn useful one :)

> It looks like there's still one confusing reference to Par0: "Note how Par0 
> and Rec0 both being mapped to K1 allows us to define a uniform instance here. 
> " but at least it's not tangled up in the already very confusing examples and 
> signatures.  I think that sentence can be deleted entirely now?

Indeed, an earlier part of the documentation in that module mentions
that Par0 was deprecated (and removed, in fact), so we really
shouldn't be mentioning it elsewhere. I'll remove that sentence.

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

Re: Type-level generics

[Ryan Scott]

While we're on the topic, I'll mention that at one point I attempted
to modify the singletons [1] library so that it would automatically
generate promoted (i.e., type-level) and singled versions of Generic
instances for any data type that derived Generic. I wasn't successful,
since it turns out singletons are difficult to adapt to data types
with higher-kinded types [2] and type classes with associated type
families [3], but I did manage to write some examples on a very
limited subset of GHC.Generics in this gist [4].

The promoted version of Generic (PGeneric) in that gist works pretty
much identically to Oleg's version, but with one notable difference: I
don't attempt to put the Generic laws as a superclass of PGeneric.
Instead, I make the laws class methods of the singled version of
Generic (SGeneric). I found it more convenient to do it this way since
I needed to pattern-match on these proofs directly in a generic
implementation of decidable equality, but I'm sure this isn't the only
way it could be done.

Speaking of which, it astounds me that the Generic laws aren't
documented in the Haddocks! We really should do that.

Ryan S.
-
[1] http://hackage.haskell.org/package/singletons
[2] See the extended discussion in
https://github.com/goldfirere/singletons/issues/150
[3] https://github.com/goldfirere/singletons/issues/198
[4] https://gist.github.com/RyanGlScott/daeb63be7885244d9882dcbb1bbc10cc
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: dll-split

[Ryan Scott]

Thanks for putting so much effort into this work, Tamar!

> When I do turn it on, by default you will get a large ~45min hit in compile 
> time.

Yikes, that's really bad! Bad enough that I have to wonder: would it
be worth including genlib among the other executables that we bundle
with GHC? Fortunately, us GHC developers have the foresight to know
that we should install genlib, but I imagine less informed Windows
users probably won't get the memo and will start to wonder why
compilation became so slow all of a sudden.

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

Re: Debugging inside the typechecker knot

[Ryan Scott]

> All the type-checking decisions are around the kinds of the types
floating through the system, so look there. You might want to know what
type that kind is classifying... perhaps print out the HsType before it's
lost.

In the problems I'm tackling, I don't care so much about the kind of the
TyCon I'm dealing with, but rather its type variables. Alas, I don't know
of a good way to inspect the changes that happen to these type variables
inside the knot--even printing out the *length* of tyConTyVars would result
in an infinite loop!

> Or, you could tackle #13737 and get rid of the knot altogether! :)

I didn't know about that ticket, thanks. I had noticed in some of the code
I frequently look at (TcGenGenerics, which generates Generic(1) instances)
that the generated code uses HsExpr for the generated instance methods, but
Type for the generated associated type family instances, which always felt
icky to me. Maybe I could start by trying to produce HsType in that
particular spot in the code (or does this need to be done all at once?).

Ryan S.

On Fri, Aug 4, 2017 at 7:33 AM, Richard Eisenberg 
wrote:

> My secret is that I've been annoyed by this problem, too!
>
> Perhaps a better answer is that you probably don't need the information
> you don't have. All the type-checking decisions are around the kinds of the
> types floating through the system, so look there. You might want to know
> what type that kind is classifying... perhaps print out the HsType before
> it's lost.
>
> Or, you could tackle #13737 and get rid of the knot altogether! :)
>
> Richard
>
> On Aug 3, 2017, at 6:21 PM, Ryan Scott  wrote:
>
> Recently, I've found myself wanting to make changes to code that works
> inside code where TyCons are knot-tied [1]. But I've found myself unable to
> make much progress, since my ability to debug this code is severely limited
> by the fact that I can't seem to trace anything. That is, if I try tracing
> anything that comes from a knot-tied TyCon, GHC will go into an infinite
> loop! This prevents me from learning *anything* about the types floating
> around in the code I want to fix, which is hugely annoying.
>
> How do others work around this problem? There must be *some* way to glean
> information about the types inside a typechecker knot, since others seem to
> be able to work within this space. How do you do it? And will you consider
> sharing your secrets?
>
> Ryan S.
> -
> [1] See Note [Type-checking inside the knot] at
> http://git.haskell.org/ghc.git/blob/884bd21a917f607b5a44e038e06f78
> d0b765ea63:/compiler/typecheck/TcHsType.hs#l1087
> ___
> 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