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

[Vladislav Zavialov (int-index)]

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 <mail at joachim-breitner.de> 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
>>> <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/
>>> 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
>>> _______________________________________________
>>> 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
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee