Opened 6 years ago

Last modified 5 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@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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 (10)

comment:1 Changed 6 years ago by guest

  • Cc alfonso.acosta@… added

comment:2 Changed 6 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 6 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 6 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?).

[1] http://www.haskell.org/pipermail/glasgow-haskell-users/2008-April/014638.html

comment:5 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:6 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:7 Changed 5 years ago by igloo

  • Milestone changed from 6.10 branch to _|_

comment:8 Changed 15 months 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 15 months ago by goldfire

  • Cc eir@… added

comment:10 Changed 5 months ago by polkovnikov.ph

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.

Note: See TracTickets for help on using tickets.