Proposal #412: Explicit Splice Imports; rec: accept

Vladislav Zavialov (int-index)

14 Jun 2021 14 Jun '21

10:09 a.m.

Dear Committee, Proposal #412 "Explicit Splice Imports” by Matthew Pickering has been submitted for our consideration. Read it here: https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/00... Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/412 The goals of this proposal are to (1) improve parallel compilation, (2) speed up -fno-code and IDEs that rely on it, (3) reduce binary sizes or at least reduce linking overhead, (4) create phase separation useful for cross-compilation. All of the above are achieved by introducing a new form of import called a splice-import. Compare: import M import splice H Under this proposal, names imported from M can *not* be used in top-level Template Haskell splices, whereas names imported from H can be used *only* in Template Haskell splices. At this point I will note that I do not particularly like the proposed syntax, which looks as if we’re importing a splice rather than importing names for use in splices. In the “Alternatives” section, you will find several other options such as “import {-# SPLICE #-} M”, “import for splice H”, “$(import H)”, and so on. That said, let us not get bogged down in the discussion of syntax before we agree on the semantics. If we choose to accept the proposal, I will organize a vote on the syntax. Regarding the semantics, I believe the general idea behind the proposal is good, and I recommend acceptance. It provides a way for the programmer to specify the intended usage of an import (whether it is for normal programming or metaprogramming), and GHC can use this information to build the program more effectively (more parallelism, less linking). In ways that I do not entirely understand, it is allegedly good for future work on cross-compilation. Let me know what you think. - Vlad

Show replies by date

Alejandro Serrano Mena

15 Jun 15 Jun

3:01 a.m.

New subject: Proposal #412: Explicit Splice Imports; rec: accept

Dear all, I like the proposal, and I think my life will automatically improve with this. Alejandro El 14 jun 2021 16:09:06, Vladislav Zavialov (int-index) < vlad.z.4096@gmail.com> escribió:

...

Dear Committee,

Proposal #412 "Explicit Splice Imports” by Matthew Pickering has been submitted for our consideration.

Read it here: https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/00... Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/412

The goals of this proposal are to (1) improve parallel compilation, (2) speed up -fno-code and IDEs that rely on it, (3) reduce binary sizes or at least reduce linking overhead, (4) create phase separation useful for cross-compilation.

All of the above are achieved by introducing a new form of import called a splice-import. Compare:

import M import splice H

Under this proposal, names imported from M can *not* be used in top-level Template Haskell splices, whereas names imported from H can be used *only* in Template Haskell splices.

At this point I will note that I do not particularly like the proposed syntax, which looks as if we’re importing a splice rather than importing names for use in splices. In the “Alternatives” section, you will find several other options such as “import {-# SPLICE #-} M”, “import for splice H”, “$(import H)”, and so on. That said, let us not get bogged down in the discussion of syntax before we agree on the semantics. If we choose to accept the proposal, I will organize a vote on the syntax.

Regarding the semantics, I believe the general idea behind the proposal is good, and I recommend acceptance. It provides a way for the programmer to specify the intended usage of an import (whether it is for normal programming or metaprogramming), and GHC can use this information to build the program more effectively (more parallelism, less linking). In ways that I do not entirely understand, it is allegedly good for future work on cross-compilation.

Let me know what you think.

- Vlad _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Spiwack, Arnaud

17 Jun 17 Jun

9:13 a.m.

New subject: Proposal #412: Explicit Splice Imports; rec: accept

I agree with the sentiment so far: this is a well constructed proposal which makes a good case for the fine details of the proposed specification. The goal is also quite desirable (it has been brought up by other before, such as http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-g... or https://github.com/ghc-proposals/ghc-proposals/pull/243 ). On Tue, Jun 15, 2021 at 9:02 AM Alejandro Serrano Mena wrote:

...

Dear all, I like the proposal, and I think my life will automatically improve with this.

Alejandro

El 14 jun 2021 16:09:06, Vladislav Zavialov (int-index) < vlad.z.4096@gmail.com> escribió:

...
Dear Committee,

Proposal #412 "Explicit Splice Imports” by Matthew Pickering has been submitted for our consideration.

Read it here: https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/00... Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/412

The goals of this proposal are to (1) improve parallel compilation, (2) speed up -fno-code and IDEs that rely on it, (3) reduce binary sizes or at least reduce linking overhead, (4) create phase separation useful for cross-compilation.

All of the above are achieved by introducing a new form of import called a splice-import. Compare:

import M import splice H

Under this proposal, names imported from M can *not* be used in top-level Template Haskell splices, whereas names imported from H can be used *only* in Template Haskell splices.

At this point I will note that I do not particularly like the proposed syntax, which looks as if we’re importing a splice rather than importing names for use in splices. In the “Alternatives” section, you will find several other options such as “import {-# SPLICE #-} M”, “import for splice H”, “$(import H)”, and so on. That said, let us not get bogged down in the discussion of syntax before we agree on the semantics. If we choose to accept the proposal, I will organize a vote on the syntax.

Regarding the semantics, I believe the general idea behind the proposal is good, and I recommend acceptance. It provides a way for the programmer to specify the intended usage of an import (whether it is for normal programming or metaprogramming), and GHC can use this information to build the program more effectively (more parallelism, less linking). In ways that I do not entirely understand, it is allegedly good for future work on cross-compilation.

Let me know what you think.

- Vlad _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Richard Eisenberg

19 Jul 19 Jul

4:26 p.m.

New subject: Proposal #412: Explicit Splice Imports; rec: accept

I support acceptance of the proposal. RIchard

...

On Jun 17, 2021, at 9:13 AM, Spiwack, Arnaud wrote:

I agree with the sentiment so far: this is a well constructed proposal which makes a good case for the fine details of the proposed specification. The goal is also quite desirable (it has been brought up by other before, such as http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-g... http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-g... or https://github.com/ghc-proposals/ghc-proposals/pull/243 https://github.com/ghc-proposals/ghc-proposals/pull/243 ).

On Tue, Jun 15, 2021 at 9:02 AM Alejandro Serrano Mena mailto:trupill@gmail.com> wrote: Dear all, I like the proposal, and I think my life will automatically improve with this.

Alejandro

El 14 jun 2021 16:09:06, Vladislav Zavialov (int-index) mailto:vlad.z.4096@gmail.com> escribió: Dear Committee,

Proposal #412 "Explicit Splice Imports” by Matthew Pickering has been submitted for our consideration.

Read it here: https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/00... https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/00... Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/412 https://github.com/ghc-proposals/ghc-proposals/pull/412

The goals of this proposal are to (1) improve parallel compilation, (2) speed up -fno-code and IDEs that rely on it, (3) reduce binary sizes or at least reduce linking overhead, (4) create phase separation useful for cross-compilation.

All of the above are achieved by introducing a new form of import called a splice-import. Compare:

import M import splice H

Under this proposal, names imported from M can *not* be used in top-level Template Haskell splices, whereas names imported from H can be used *only* in Template Haskell splices.

At this point I will note that I do not particularly like the proposed syntax, which looks as if we’re importing a splice rather than importing names for use in splices. In the “Alternatives” section, you will find several other options such as “import {-# SPLICE #-} M”, “import for splice H”, “$(import H)”, and so on. That said, let us not get bogged down in the discussion of syntax before we agree on the semantics. If we choose to accept the proposal, I will organize a vote on the syntax.

Regarding the semantics, I believe the general idea behind the proposal is good, and I recommend acceptance. It provides a way for the programmer to specify the intended usage of an import (whether it is for normal programming or metaprogramming), and GHC can use this information to build the program more effectively (more parallelism, less linking). In ways that I do not entirely understand, it is allegedly good for future work on cross-compilation.

Let me know what you think.

- Vlad _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

14 Sep 14 Sep

3:51 a.m.

New subject: Proposal #412: Explicit Splice Imports; rec: accept

Hi, It looks like we have consensus, but I see there is was some more discussion after that on the Github trail. Back to revision? Or can we accept as it is? Cheers, Joachim Am Montag, dem 19.07.2021 um 20:26 +0000 schrieb Richard Eisenberg:

...

I support acceptance of the proposal.

RIchard

...
On Jun 17, 2021, at 9:13 AM, Spiwack, Arnaud wrote:

I agree with the sentiment so far: this is a well constructed proposal which makes a good case for the fine details of the proposed specification. The goal is also quite desirable (it has been brought up by other before, such as http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-g... or https://github.com/ghc-proposals/ghc-proposals/pull/243 ).

On Tue, Jun 15, 2021 at 9:02 AM Alejandro Serrano Mena wrote:

...
Dear all, I like the proposal, and I think my life will automatically improve with this.

Alejandro

El 14 jun 2021 16:09:06, Vladislav Zavialov (int-index) escribió:

...
Dear Committee,

Proposal #412 "Explicit Splice Imports” by Matthew Pickering has been submitted for our consideration.

Read it here: https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/00... Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/412

The goals of this proposal are to (1) improve parallel compilation, (2) speed up -fno-code and IDEs that rely on it, (3) reduce binary sizes or at least reduce linking overhead, (4) create phase separation useful for cross-compilation.

All of the above are achieved by introducing a new form of import called a splice-import. Compare:

import M import splice H

Under this proposal, names imported from M can *not* be used in top-level Template Haskell splices, whereas names imported from H can be used *only* in Template Haskell splices.

At this point I will note that I do not particularly like the proposed syntax, which looks as if we’re importing a splice rather than importing names for use in splices. In the “Alternatives” section, you will find several other options such as “import {-# SPLICE #-} M”, “import for splice H”, “$(import H)”, and so on. That said, let us not get bogged down in the discussion of syntax before we agree on the semantics. If we choose to accept the proposal, I will organize a vote on the syntax.

Regarding the semantics, I believe the general idea behind the proposal is good, and I recommend acceptance. It provides a way for the programmer to specify the intended usage of an import (whether it is for normal programming or metaprogramming), and GHC can use this information to build the program more effectively (more parallelism, less linking). In ways that I do not entirely understand, it is allegedly good for future work on cross-compilation.

Let me know what you think.

- Vlad _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

Vladislav Zavialov (int-index)

5:56 a.m.

New subject: Proposal #412: Explicit Splice Imports; rec: accept

I sent it back for revision until the author decides whether we want quote imports or not. This is still on the trajectory to acceptance, though. - Vlad

...

On 14 Sep 2021, at 10:51, Joachim Breitner wrote:

Hi,

It looks like we have consensus, but I see there is was some more discussion after that on the Github trail. Back to revision? Or can we accept as it is?

Cheers, Joachim

Am Montag, dem 19.07.2021 um 20:26 +0000 schrieb Richard Eisenberg:

...
I support acceptance of the proposal.

RIchard

...
On Jun 17, 2021, at 9:13 AM, Spiwack, Arnaud wrote:

I agree with the sentiment so far: this is a well constructed proposal which makes a good case for the fine details of the proposed specification. The goal is also quite desirable (it has been brought up by other before, such as http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-g... or https://github.com/ghc-proposals/ghc-proposals/pull/243 ).

On Tue, Jun 15, 2021 at 9:02 AM Alejandro Serrano Mena wrote:

...
Dear all, I like the proposal, and I think my life will automatically improve with this.

Alejandro

El 14 jun 2021 16:09:06, Vladislav Zavialov (int-index) escribió:

...
Dear Committee,

Proposal #412 "Explicit Splice Imports” by Matthew Pickering has been submitted for our consideration.

Read it here: https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/00... Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/412

The goals of this proposal are to (1) improve parallel compilation, (2) speed up -fno-code and IDEs that rely on it, (3) reduce binary sizes or at least reduce linking overhead, (4) create phase separation useful for cross-compilation.

All of the above are achieved by introducing a new form of import called a splice-import. Compare:

import M import splice H

Under this proposal, names imported from M can *not* be used in top-level Template Haskell splices, whereas names imported from H can be used *only* in Template Haskell splices.

At this point I will note that I do not particularly like the proposed syntax, which looks as if we’re importing a splice rather than importing names for use in splices. In the “Alternatives” section, you will find several other options such as “import {-# SPLICE #-} M”, “import for splice H”, “$(import H)”, and so on. That said, let us not get bogged down in the discussion of syntax before we agree on the semantics. If we choose to accept the proposal, I will organize a vote on the syntax.

Regarding the semantics, I believe the general idea behind the proposal is good, and I recommend acceptance. It provides a way for the programmer to specify the intended usage of an import (whether it is for normal programming or metaprogramming), and GHC can use this information to build the program more effectively (more parallelism, less linking). In ways that I do not entirely understand, it is allegedly good for future work on cross-compilation.

Let me know what you think.

- Vlad _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

6:49 a.m.

New subject: Proposal #412: Explicit Splice Imports; rec: accept

| This is still on the trajectory to acceptance, though. In the light of Matthew's comment "it's not clear to me now how splice imports should work" (and the issues he describes in that post) the proposal has become less attractive to me. I'm no longer sure it's on a "trajectory to acceptance". Let's just look at the revision with fresh eyes. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com will cease to work. Use simon.peytonjones@gmail.com instead. (For now, it just forwards to simonpj@microsoft.com.) | -----Original Message----- | From: ghc-steering-committee On Behalf Of Vladislav Zavialov (int-index) | Sent: 14 September 2021 10:56 | To: Joachim Breitner | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Proposal #412: Explicit Splice | Imports; rec: accept | | I sent it back for revision until the author decides whether we want | quote imports or not. | | This is still on the trajectory to acceptance, though. | | - Vlad | | > On 14 Sep 2021, at 10:51, Joachim Breitner wrote: | > | > Hi, | > | > It looks like we have consensus, but I see there is was some more | > discussion after that on the Github trail. Back to revision? Or can | we | > accept as it is? | > | > Cheers, | > Joachim | > | > Am Montag, dem 19.07.2021 um 20:26 +0000 schrieb Richard Eisenberg: | >> I support acceptance of the proposal. | >> | >> RIchard | >> | >>> On Jun 17, 2021, at 9:13 AM, Spiwack, Arnaud | >>> wrote: | >>> | >>> I agree with the sentiment so far: this is a well constructed | >>> proposal which makes a good case for the fine details of the | >>> proposed specification. The goal is also quite desirable (it has | >>> been brought up by other before, such as | >>> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblo | >>> g.ezyang.com%2F2016%2F07%2Fwhat-template-haskell-gets-wrong-and- | rack | >>> et-gets- | right%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C27792c | >>> | 35c4544a26508c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C | >>> | 0%7C637672103914375977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | >>> | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jMMrN | >>> rwrmy4u6Tb6sq73iDU7SfCGYm49BkPdgXa%2BYfU%3D&reserved=0 | >>> or | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F243&data=04%7C01%7Csimonpj%40microsoft.com%7C27 | 792c35c4544a26508c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C637672103914375977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pdti7z6 | 4DefvJfsFeC9MWvln962hfuruh9zZQs4%2FI%2Fg%3D&reserved=0 ). | >>> | >>> On Tue, Jun 15, 2021 at 9:02 AM Alejandro Serrano Mena | >>> wrote: | >>>> Dear all, | >>>> I like the proposal, and I think my life will automatically | improve | >>>> with this. | >>>> | >>>> Alejandro | >>>> | >>>> El 14 jun 2021 16:09:06, Vladislav Zavialov (int-index) | >>>> escribió: | >>>> | >>>>> Dear Committee, | >>>>> | >>>>> Proposal #412 "Explicit Splice Imports" by Matthew Pickering has | >>>>> been submitted for our consideration. | >>>>> | >>>>> Read it here: | >>>>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F | >>>>> github.com%2Fmpickering%2Fghc-proposals%2Fblob%2Fsplice- | imports%2F | >>>>> proposals%2F0000-splice- | imports.rst&data=04%7C01%7Csimonpj%40m | >>>>> | icrosoft.com%7C27792c35c4544a26508c08d97765e7cf%7C72f988bf86f141af | >>>>> | 91ab2d7cd011db47%7C1%7C0%7C637672103914375977%7CUnknown%7CTWFpbGZs | >>>>> | b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn | >>>>> | 0%3D%7C1000&sdata=Cl4DNgqIPcjr9hBRrNNiVS40v8Guwd47PZ0p9AdFkQQ% | >>>>> 3D&reserved=0 | >>>>> Discussion here: | >>>>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F | >>>>> github.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F412&data=0 | >>>>> | 4%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a26508c08d97765e7c | >>>>> | f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672103914375977% | >>>>> | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi | >>>>> | I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pEUWmUUICGVirnVpY13lHtAi | >>>>> xYqLW11guSwLvf30mk0%3D&reserved=0 | >>>>> | >>>>> The goals of this proposal are to (1) improve parallel | >>>>> compilation, (2) speed up -fno-code and IDEs that rely on it, | >>>>> (3) reduce binary sizes or at least reduce linking overhead, | >>>>> (4) create phase separation useful for cross-compilation. | >>>>> | >>>>> All of the above are achieved by introducing a new form of | import | >>>>> called a splice-import. Compare: | >>>>> | >>>>> import M | >>>>> import splice H | >>>>> | >>>>> Under this proposal, names imported from M can *not* be used in | >>>>> top-level Template Haskell splices, whereas names imported from | H | >>>>> can be used *only* in Template Haskell splices. | >>>>> | >>>>> At this point I will note that I do not particularly like the | >>>>> proposed syntax, which looks as if we're importing a splice | rather | >>>>> than importing names for use in splices. In the "Alternatives" | >>>>> section, you will find several other options such as "import {-# | >>>>> SPLICE #-} M", "import for splice H", "$(import H)", and so on. | >>>>> That said, let us not get bogged down in the discussion of | syntax | >>>>> before we agree on the semantics. | >>>>> If we choose to accept the proposal, I will organize a vote on | the | >>>>> syntax. | >>>>> | >>>>> Regarding the semantics, I believe the general idea behind the | >>>>> proposal is good, and I recommend acceptance. It provides a way | >>>>> for the programmer to specify the intended usage of an import | >>>>> (whether it is for normal programming or metaprogramming), and | GHC | >>>>> can use this information to build the program more effectively | >>>>> (more parallelism, less linking). In ways that I do not entirely | >>>>> understand, it is allegedly good for future work on | >>>>> cross-compilation. | >>>>> | >>>>> Let me know what you think. | >>>>> | >>>>> - Vlad | >>>>> _______________________________________________ | >>>>> ghc-steering-committee mailing list | >>>>> ghc-steering-committee@haskell.org | >>>>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F | >>>>> mail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | com | >>>>> | mittee&data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a | >>>>> | 26508c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | >>>>> | 7672103914375977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | >>>>> | joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BQsupcr | >>>>> 1P1EVbPn24sSKAKmsb7PtqBwsr5sXw9OvYRE%3D&reserved=0 | >>>>> | >>>> _______________________________________________ | >>>> ghc-steering-committee mailing list | >>>> ghc-steering-committee@haskell.org | >>>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm | >>>> ail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | commi | >>>> | ttee&data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a265 | >>>> | 08c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672 | >>>> | 103914385971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2 | >>>> | luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yNaMf3apYlBi9 | >>>> gOrWjPKa%2B%2FIsBtdQFZMrFeLLx61UWQ%3D&reserved=0 | >>> _______________________________________________ | >>> ghc-steering-committee mailing list | >>> ghc-steering-committee@haskell.org | >>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | >>> il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committ | >>> | ee&data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a26508c | >>> | 08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376721039 | >>> | 14385971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI | >>> | iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yNaMf3apYlBi9gOrWjP | >>> Ka%2B%2FIsBtdQFZMrFeLLx61UWQ%3D&reserved=0 | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai | >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee | >> | &data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a26508c08d | >> | 97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63767210391438 | >> | 5971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB | >> | TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yNaMf3apYlBi9gOrWjPKa%2B% | >> 2FIsBtdQFZMrFeLLx61UWQ%3D&reserved=0 | > | > -- | > Joachim Breitner | > mail@joachim-breitner.de | > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | > oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C277 | > | 92c35c4544a26508c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7 | > | C0%7C637672103914385971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC | > | JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wg9N5%2F | > zQwRWTCtFqswzUVIqqQBo%2Fts7wgKsPP4N1X1E%3D&reserved=0 | > | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&a | > | mp;data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a26508c08d977 | > | 65e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672103914385971 | > | %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I | > | k1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yNaMf3apYlBi9gOrWjPKa%2B%2FIsBt | > dQFZMrFeLLx61UWQ%3D&reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a2 | 6508c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376721 | 03914385971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yNaMf3apYlBi9gOrWjPK | a%2B%2FIsBtdQFZMrFeLLx61UWQ%3D&reserved=0

1344

Age (days ago)

1436

Last active (days ago)

List overview

Download

6 comments

6 participants

participants (6)

Alejandro Serrano Mena
Joachim Breitner
Richard Eisenberg
Simon Peyton Jones
Spiwack, Arnaud
Vladislav Zavialov (int-index)