Proposed: Language.Haskell.TH.Internal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposed: Language.Haskell.TH.Internal

Richard Eisenberg-4
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Proposed: Language.Haskell.TH.Internal

GHC - devs mailing list
In reply to this post by Richard Eisenberg-4
OK with me, provided we document the thinking so that users understand the architecture.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:[hidden email]] On Behalf Of Richard
| Eisenberg
| Sent: 18 July 2017 13:27
| To: GHC developers <[hidden email]>
| Cc: Ryan Scott <[hidden email]>
| 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
| [hidden email]
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cc77c4285ceef48c4783608d4cdd
| 8ab70%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636359777860344686&sda
| ta=TxVVdCy2qEpZnbWDiaPOajm14EivqRDTZdIDVVIax3M%3D&reserved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Loading...