Opened 4 years ago

Last modified 4 years ago

#10842 new feature request

"Reactive" Template Haskell

Reported by: MikeIzbicki Owned by:
Priority: normal Milestone:
Component: Template Haskell Version: 7.10.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #9699, #10391 Differential Rev(s):
Wiki Page:

Description

When metaprogramming, I often encounter the situation where I want GHC to do something for every definition in scope. For example, I recently posted a simple library called ifcxt that relies on defining instance IfCxt cxt for every instance cxt that gets defined (where cxt is an arbitrary class instance).

Currently, the library has a TH function that generates these IfCxt cxt instances, but it can only work for instances that already exist at the time the TH function is called. Any instances created afterward get silently ignored.

To solve this problem, I would like to be able to register TH functions with the compiler that get executed everytime the compiler adds a definition. This might take the form of a function like:

registerTH :: (Dec -> Q [Dec]) -> Q ()

When regesterTH is called, it would add the argument function to an internal list. Then, whenever the compiler defines a new declaration, it calls each function in the list on that declaration to see what new declarations should be added to the code.

AFAICT, there are two main drawbacks to this proposal. One, end users do not have to specifically invoke a TH function to get TH code to run. This would allow library authors to take over people's programs in possibly unexpected ways. So this might justify an additional extension beyond just -XTemplateHaskell to signal the potentially dangerous nature of the code, or implementing this feature by extending the compiler plugin interface. Second, it would be very easy to accidentally send the compiler into infinite loops if two registered functions don't take care to behave properly with each other.

Change History (7)

comment:1 Changed 4 years ago by goldfire

Interesting. I am worried about "spooky action at a distance" here, but perhaps this would be useful. To get more traction on this proposal, might you advertise it and see what response you get? It would be more compelling if there will be more than 1 user!

Thanks!

comment:2 Changed 4 years ago by goldfire

Component: CompilerTemplate Haskell

comment:3 Changed 4 years ago by luite

Should the callback be active for the current module or for something more? Beyond the current module would be hard to support in the presence of partial rebuilds.

Should this be called for all declarations below the point adding the callback, or just for those added by TH? If this is to be called for everything, then this could end up being problematic for new language extensions that cannot yet be converted to a TH Dec .

Also I'm a bit wary about having more higher order functions in the low-level Q API, since they're significantly harder to support in implementations where TH isn't run in the GHC address space (like GHCJS and the proposed out-of-process TH extension for stage1 (cross) compiler TH support). As far as I can tell, this particular extension would still be implementable though.

comment:4 Changed 4 years ago by dmcclean

Would this one allow you to cover most of your use cases without the "action at a distance" problem? https://ghc.haskell.org/trac/ghc/ticket/10391

comment:5 Changed 4 years ago by thomie

comment:6 Changed 4 years ago by goldfire

Just noting that I'm moving this out of my queue. If you want something like this to happen, please get others to agree, write a spec of the idea on a wiki page, beg for people to submit a patch, etc.

Sounds like an interesting idea, but it needs to be fleshed out. Thanks!

comment:7 Changed 4 years ago by kanetw

This does sound interesting! If you can flesh out the spec, I'll take a closer look at this. Extending the compiler plugin interface seems more appropriate considering how invasive this could be.

Note: See TracTickets for help on using tickets.