Opened 9 years ago

Last modified 3 months ago

#1831 new bug

reify never provides the declaration of variables

Reported by: guest Owned by:
Priority: normal Milestone:
Component: Template Haskell Version: 6.8.1
Keywords: Cc: alfonso.acosta@…, eir@…, brad.larsen@…, tomberek@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


The information returned by reify when provided a variable Name is

VarI Name Type (Maybe Dec) Fixity

The Dec part, due to be nested in Maybe, is clearly optional. In fact, according to Language.Haskell.TH.Syntax:

-- Nothing for lambda-bound variables, and
-- for anything else TH can't figure out
-- E.g. [| let x = 1 in $(do { d <- reify 'x; .. }) |]

However, the typechecker (TcSplice module) always returns Nothing. So it's simply not implemented.

I suggest either implementing the feature or removing the Dec part of VarI. Either way, the type should be consistent with the features offered in TH.

Change History (15)

comment:1 Changed 9 years ago by guest

  • Cc alfonso.acosta@… added

comment:2 Changed 9 years ago by igloo

  • difficulty set to Unknown
  • Milestone set to 6.10 branch

We should look at doing one or the other for 6.10.

comment:3 Changed 9 years ago by guest

As a reminder, igloo suggested the possibility of bundling source information in interface files (through an optional flag) so that reify could then provide declarations of variables defined in external modules (as opposed to only offering Dec information if the variable was defined in current module).

That wouldn't either garantee having access to all variable declarations, but certainly would make this feature more attractive.

comment:4 Changed 8 years ago by fons

Just for the record, this haskell-cafe message [1] shows that bundling the source info in interface files can be useful for other things than Template Haskell:

Yes, an almost-universal printer would be possible now that we have data constructor names attached to info tables. I'd sort of planned to do that, and then got side-tracked. Of course, this won't be able to print functions in any helpful way, unless we attach source code information to functions as well (which may be worth doing anyway?).


comment:5 Changed 8 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:6 Changed 8 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:7 Changed 7 years ago by igloo

  • Milestone changed from 6.10 branch to _|_

comment:8 Changed 3 years ago by morabbin

  • Type of failure set to None/Unknown

Bump; noted now in TH doco as unimplemented due to lack of interest. Last interest here was 5 years since.

comment:9 Changed 3 years ago by goldfire

  • Cc eir@… added

comment:10 Changed 3 years ago by

I don't actually think there's a lack of interest in this functionality. It could finally let programmers to write TH-based translation libraries. For example, one could create javascript such that print $ javascript sort generates JS code for list sorting, effectively reusing Prelude. Also, some language extensions like Megacz's generalized arrows could become libraries.

comment:11 Changed 2 years ago by blarsen

  • Cc brad.larsen@… added

comment:12 Changed 15 months ago by tomberek

  • Cc tomberek@… added

comment:13 Changed 8 months ago by tomberek

I will +1's comments. Especially with regards to translation libraries and generalized arrows.

comment:14 Changed 8 months ago by goldfire

  • Keywords newcomer added

It strikes me that this wouldn't actually be terribly hard to do. INLINEABLE identifiers have their unfoldings available. These unfoldings are expressed in Core. But it shouldn't be very hard to translate Core to the TH AST.

Just looking at unfoldings would mean that this feature wouldn't work for identifiers declared in the same module as the reify but not declared INLINEABLE (or something that implies INLINEABLE). This would be disappointing to some people, I'm sure, but we can iteratively get better with this feature.

I'll say this is appropriate for an ambitious newcomer. I don't think you'll have to know a ton about the internals of GHC, but it's way more than a few lines to fix.

comment:15 Changed 3 months ago by thomie

  • Keywords newcomer removed
Note: See TracTickets for help on using tickets.