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

[Spiwack, Arnaud]

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/
or 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>
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> 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
>>
> _______________________________________________
> 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/20210617/a4915f72/attachment.html>