Opened 4 years ago

Last modified 3 years ago

#11081 new feature request

Implement Introspective Template Haskell

Reported by: goldfire Owned by:
Priority: normal Milestone:
Component: Template Haskell Version: 7.10.2
Keywords: Cc: jstolarek, lerkok, gridaphobe, alanz
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page: TemplateHaskell/Introspective

Description

This ticket is to track commentary and reactions to TemplateHaskell/Introspective, and to help the proposal not get lost. Contrary to the title of this ticket, it is not yet resolved that Introspective Template Haskell should ever be implemented. But with some of the support that it's gotten, it seemed appropriate to make a ticket.

Change History (9)

comment:1 Changed 4 years ago by jstolarek

Cc: jstolarek added

comment:2 Changed 4 years ago by lerkok

Cc: lerkok added

comment:3 Changed 4 years ago by lerkok

I think this is a great idea. In the past, I've tried both TH and haskell-src-exts to do relatively simple things, but ended-up abandoning them due to the inherent complexity of source level haskell that had very little to do with what I really cared about. Being able to get your hands on Core at the regular Haskell level would truly simplify life, and I suspect would open the flood-gates for a lot of people to develop extremely useful artifacts, making the GHC/Haskell experience even better.

comment:4 Changed 4 years ago by gridaphobe

Cc: gridaphobe added

comment:5 Changed 4 years ago by simonpj

I'm sceptical about the stuff about Core until I see more details. But that's for the future.

The fundamental idea here is to replace Language.Haskell.TH.Syntax outright with HsSyn. The advantages, of course, are (a) avoiding duplication, (b) TH stop lagging GHC.

The disadvantage is that HsSyn is designed as an internal data type for a compiler. We feel free to

  • decorate it with extra information (mostly types) as it moves down the pipeline,
  • have one constructor before type checking and a different one afterwards (eg ConPatIn and ConPatOut in HsPat
  • add elaboration info for type and dictionary applications and instantiation.

For TH programs that construct syntax trees directly (ie not using quotation) or pattern-match over them, all this extra clutter might be confusing and/or awkward.

I'm very unsure about the back-compat shim, but maybe it's possible. Yay for pattern synonyms.

comment:6 Changed 3 years ago by alanz

Cc: alanz added

comment:7 in reply to:  5 Changed 3 years ago by Iceland_jack

Replying to simonpj:

I'm very unsure about the back-compat shim, but maybe it's possible. Yay for pattern synonyms.

Could they also be used for other migrations? In Language.Haskell.TH.Lib another function instanceWithOverlapD was added to prevent breakage:

instanceD            ::                  CxtQ -> TypeQ -> [DecQ] -> DecQ
instanceWithOverlapD :: Maybe Overlap -> CxtQ -> TypeQ -> [DecQ] -> DecQ

The same could have been done with InstanceD

--      OLD: 
--  | InstanceD Cxt Type [Dec] 
    | InstanceWithOverlapD (Maybe Overlap) Cxt Type [Dec]

and like ErrorCall defining

pattern InstanceD :: Ctx -> Type -> [Dec] -> Dec
pattern InstanceD ctx ty decs = InstanceWithOverlapD Nothing ctx ty decs

which suffers from the same problem as ErrorCall.

Edit: Some Template Haskell failed to build because of that, it was quickly fixed but would have been good to do without for the same reasons as instanceWithOverlapD was added.

Last edited 3 years ago by Iceland_jack (previous) (diff)

comment:8 Changed 3 years ago by simonmar

Can this be made to work with -fexternal-interpreter? I was hoping to make that the default at some point in the future.

comment:9 Changed 3 years ago by goldfire

I think so, yes. Shayan Najd is currently completing a Summer of Haskell project (https://summer.haskell.org/) in an attempt to combine haskell-src-exts, GHC's HsSyn, and the TH AST. Serializability is a consideration, and so this should all be OK.

Note: See TracTickets for help on using tickets.