[ghc-steering-committee] Proposal #412: Explicit Splice Imports; rec: accept
Richard Eisenberg
lists at richarde.dev
Mon Jul 19 20:26:08 UTC 2021
I support acceptance of the proposal.
RIchard
> On Jun 17, 2021, at 9:13 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> 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-gets-right/ <http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/> 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 <trupill at gmail.com <mailto:trupill at 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) <vlad.z.4096 at gmail.com <mailto:vlad.z.4096 at 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/0000-splice-imports.rst <https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/0000-splice-imports.rst>
> 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 at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210719/b94cf7b0/attachment-0001.html>
More information about the ghc-steering-committee
mailing list