RE: Proposed: Language.Haskell.TH.Internal

[Simon Peyton Jones via ghc-devs]

OK with me, provided we document the thinking so that users understand the 
architecture.

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard
| Eisenberg
| Sent: 18 July 2017 13:27
| To: GHC developers <ghc-devs@haskell.org>
| Cc: Ryan Scott <ryan.gl.sc...@gmail.com>
| Subject: Proposed: Language.Haskell.TH.Internal
| 
| Hi devs,
| 
| This is a brief proposal for an internal, non-user-facing restructuring
| of the implementation of Template Haskell. It's here (instead of at ghc-
| proposals) because it's not user-facing.
| 
| When a user writes a TH quote [| foo bar baz |], GHC must desugar that
| into some Core code that builds a Q Exp. This is currently done by
| calling functions in Language.Haskell.TH.Lib, which is capable of
| building all the TH abstract syntax. However, many end-users of TH *also*
| import Language.Haskell.TH.Lib and use its functions. This means that, as
| the Haskell AST evolves, we can't reasonably evolve this Lib module, as
| it breaks user code. (There is a requisite amount of churn in TH, but we
| try to avoid gratuitous changes in Lib.) This has bitten in the past when
| we have, say, changed the representation of type families to accommodate
| closed type families, and it's biting now as we (ahem, Ryan Scott) are
| trying to merge types and kinds in TH.
| 
| I thus propose a new module Language.Haskell.TH.Internal. This will start
| out as a slimmed-down copy of Lib (slimmed-down because Lib already has a
| bunch of now-disused functions) but may evolve independently. Desugaring
| quotes will go via this new Internal module, and we will have no qualms
| about changing its interface, as it's Internal.
| 
| What do we think? Ryan has already implemented this idea in D3751.
| 
| Pros:
|  - Flexibility
|  - Separation between user-facing interface and internal interface
| 
| Cons:
|  - More stuff
|  - We already break the TH API with every release; maybe it's not so bad
| to break more of it.
| 
| Thanks,
| Richard
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs=02%7C01%7Csimonpj%40microsoft.com%7Cc77c4285ceef48c4783608d4cdd
| 8ab70%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636359777860344686
| ta=TxVVdCy2qEpZnbWDiaPOajm14EivqRDTZdIDVVIax3M%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposed: Language.Haskell.TH.Internal

[Alan & Kim Zimmerman]

This can serve as a starting point for the Trees that Grow implementation
too, I understand Shayan Najd is intending to eventually harmonise the
hsSyn AST and the TH one.

Alan

On 18 July 2017 at 14:27, Richard Eisenberg  wrote:

> Hi devs,
>
> This is a brief proposal for an internal, non-user-facing restructuring of
> the implementation of Template Haskell. It's here (instead of at
> ghc-proposals) because it's not user-facing.
>
> When a user writes a TH quote [| foo bar baz |], GHC must desugar that
> into some Core code that builds a Q Exp. This is currently done by calling
> functions in Language.Haskell.TH.Lib, which is capable of building all the
> TH abstract syntax. However, many end-users of TH *also* import
> Language.Haskell.TH.Lib and use its functions. This means that, as the
> Haskell AST evolves, we can't reasonably evolve this Lib module, as it
> breaks user code. (There is a requisite amount of churn in TH, but we try
> to avoid gratuitous changes in Lib.) This has bitten in the past when we
> have, say, changed the representation of type families to accommodate
> closed type families, and it's biting now as we (ahem, Ryan Scott) are
> trying to merge types and kinds in TH.
>
> I thus propose a new module Language.Haskell.TH.Internal. This will start
> out as a slimmed-down copy of Lib (slimmed-down because Lib already has a
> bunch of now-disused functions) but may evolve independently. Desugaring
> quotes will go via this new Internal module, and we will have no qualms
> about changing its interface, as it's Internal.
>
> What do we think? Ryan has already implemented this idea in D3751.
>
> Pros:
>  - Flexibility
>  - Separation between user-facing interface and internal interface
>
> Cons:
>  - More stuff
>  - We already break the TH API with every release; maybe it's not so bad
> to break more of it.
>
> Thanks,
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Proposed: Language.Haskell.TH.Internal

[Richard Eisenberg]

Hi devs,

This is a brief proposal for an internal, non-user-facing restructuring of the 
implementation of Template Haskell. It's here (instead of at ghc-proposals) 
because it's not user-facing.

When a user writes a TH quote [| foo bar baz |], GHC must desugar that into 
some Core code that builds a Q Exp. This is currently done by calling functions 
in Language.Haskell.TH.Lib, which is capable of building all the TH abstract 
syntax. However, many end-users of TH *also* import Language.Haskell.TH.Lib and 
use its functions. This means that, as the Haskell AST evolves, we can't 
reasonably evolve this Lib module, as it breaks user code. (There is a 
requisite amount of churn in TH, but we try to avoid gratuitous changes in 
Lib.) This has bitten in the past when we have, say, changed the representation 
of type families to accommodate closed type families, and it's biting now as we 
(ahem, Ryan Scott) are trying to merge types and kinds in TH.

I thus propose a new module Language.Haskell.TH.Internal. This will start out 
as a slimmed-down copy of Lib (slimmed-down because Lib already has a bunch of 
now-disused functions) but may evolve independently. Desugaring quotes will go 
via this new Internal module, and we will have no qualms about changing its 
interface, as it's Internal.

What do we think? Ryan has already implemented this idea in D3751.

Pros:
 - Flexibility
 - Separation between user-facing interface and internal interface

Cons:
 - More stuff
 - We already break the TH API with every release; maybe it's not so bad to 
break more of it.

Thanks,
Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs