Opened 12 years ago

Last modified 2 years 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 (16)

comment:1 Changed 12 years ago by guest

Cc: alfonso.acosta@… added

comment:2 Changed 12 years ago by igloo

difficulty: Unknown
Milestone: 6.10 branch

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

comment:3 Changed 12 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 12 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 11 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:6 Changed 11 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:7 Changed 11 years ago by igloo

Milestone: 6.10 branch_|_

comment:8 Changed 7 years ago by morabbin

Type of failure: 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 7 years ago by goldfire

Cc: eir@… added

comment:10 Changed 6 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 6 years ago by blarsen

Cc: brad.larsen@… added

comment:12 Changed 5 years ago by tomberek

Cc: tomberek@… added

comment:13 Changed 4 years ago by tomberek

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

comment:14 Changed 4 years 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 4 years ago by thomie

Keywords: newcomer removed

comment:16 Changed 2 years ago by parsonsmatt

I'd like to register interest in having this available :) My specific use case is walking the AST from a given point to capture uses of throw, throwM, throwIO, etc. and try to get a list of possible exception types that might arise from a given function. eg:

openFile' :: FilePath -> IO (Either IOException String)
openFile' f = [catch|openFile f|]

It seems like this would be useful for other sorts of static analysis, as well.

Note: See TracTickets for help on using tickets.