[ghc-steering-committee] Proposal #412: Explicit Splice Imports; rec: accept

[Alejandro Serrano Mena]

 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> 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
> 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 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/20210615/e252d536/attachment.html>