Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
    • Insights
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
    • Locked Files
  • Issues 3,621
    • Issues 3,621
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 209
    • Merge Requests 209
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Security & Compliance
    • Security & Compliance
    • Dependency List
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #1476

Closed
Open
Opened Jul 01, 2007 by Ian Lynagh <igloo@earth.li>@trac-igloo
  • Report abuse
  • New issue
Report abuse New issue

Template Haskell: splicing types and patterns

In http://www.haskell.org/pipermail/template-haskell/2003-February/000021.html Simon Peyton Jones writes:

We claim to allow you to write splices in (a) types and (b) patterns.
I'm very dubious about (b). Consider]
    x = 4
      
    y :: Patt 
    y = [p| ... |]

    f $y = x

Question: where is x bound?  It looks as though x can be bound by the
spliced-in pattern or by the top-level binding.  You can't tell without
knowing what $y expands to.  We argue in our paper against non-top-level
declaration splices because that would lead to ambiguity of exactly this
sort.

It turns out that it's very inconvenient to implement pattern splices in
GHC, for exactly this reason.  We can't figure out the binding structure
till we expand the splice.  We can't expand the splice till typechecking
time.  But the renamer currently fixes the binding structure before type
checking.    Changing this would be a big upheaval.

Conclusion: pattern splices are hard to implement, and dubious from a
programming point of view.  I propose to drop them, for now at least.


Type splices have some similar echoes.  Consider
      
    y :: Type 
    y = [t| a -> a |]

    f :: $y

What is f polymorphic in?   The trouble concerns Haskell's implicit
quantification.  I guess there are three possibilities:

a) $y expands to "a -> a", and that is implicitly universally quantified
to "forall a. a->a".
b) The implicit quantification happens at the [t| ...|] brackets, so
that $y expands to
    "forall a. a->a"
c) $y expands to "a -> a" with no implicit quantification anywhere.

I'm pretty sure that we should adopt (b).  After all, we want a
lexical-scoping rule for TH, so we have to say where 'a' is bound.

That would still in principle allow
      
    y :: Type
    y = return (Tvar "a" `Arrow` Tvar "a")

Since it's the renamer that does implicit quantification, it'd be quite
awkward to make the implicit quantification at the splice site "see" the
free variables 'a'.

The link with the pattern stuff is this.  If you see
    f :: $y -> b

then what are the implicit for-alls?  My answer: the implicit for-alls
are just for "b", not for any free vars of $y.

Since then, the only solution for pattern splices I recall seeing is

f ${x,z}y = x

which asserts that the splice introduces the set of identifiers {x,z}.

Trac metadata
Trac field Value
Version 6.6.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Template Haskell
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system Unknown
Architecture Unknown

Related issues

  • Discussion
  • Designs
Assignee
Assign to
7.10.1
Milestone
7.10.1
Assign milestone
Time tracking
None
Due date
None
4
Labels
bug P::low TemplateHaskell Trac import
Assign labels
  • View project labels
Reference: ghc/ghc#1476