Changes between Version 3 and Version 4 of TemplateHaskellRichKinds


Ignore:
Timestamp:
Mar 20, 2012 9:06:23 PM (3 years ago)
Author:
goldfire
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TemplateHaskellRichKinds

    v3 v4  
    99| PromotedListT [Type]    -- for types of the form '[Int, Bool] 
    1010| PromotedTupleT [Type]   -- for types of the form '(Int, 'False) 
     11| PromotedConsT           -- ': 
    1112}}} 
    1213 
     
    1718| VarK Name               -- k 
    1819| ForallK [Name] Kind     -- forall k. ... 
     20| AppK Kind Kind          -- k1 k2 
     21| ListK                   -- [] 
     22| TupleK Int              -- (), (,), ... 
     23| ConstraintK             -- Constraint 
    1924}}} 
    2025 
     
    2429 
    2530The one place TH needs to be updated to handle promoted data constructors is in the naming quote syntax. Currently, writing {{{'Foo}}} in an expression context within a splice looks {{{Foo}}} up in the expression namespace; TH will find a data constructor named {{{Foo}}} and return its {{{Name}}}. Writing {{{''Foo}}} in an expression context within a splice looks {{{Foo}}} up in the type namespace; TH will find a type constructor named {{{Foo}}} and return its name. There is currently no way to look up a promoted data constructor. The update will include a third form of quote, {{{'''Foo}}}, which gets the name of a promoted data constructor {{{Foo}}}. Though having three quotes is somewhat regrettable, it dovetails nicely with the fact that {{{'Foo}}}, when used in a type context, refers to a promoted data constructor. If we think of the first two quotes as establishing a type context, the third quote flows naturally. 
     31 
     32 
     33== Alternatives == 
     34 
     35Here are two alternatives to the above changes. They are orthogonal to each other (i.e. either can be chosen without affecting whether or not the other is chosen). 
     36 
     37=== Simpler Types === 
     38 
     39Instead of the new types above, we could have the following: 
     40 
     41{{{ 
     42| PromotedTupleT Int     -- '(), '(,), ... 
     43| PromotedNilT           -- '[] 
     44| PromotedConsT          -- ': 
     45}}} 
     46 
     47Client code could create full tuples and lists using a combination of the above constructors with a liberal sprinkling of {{{AppT}}}s. 
     48 * Pros: Matches syntax of existing {{{TupleT}}} and {{{ListT}}}. For lists, matches forms available in surface syntax. 
     49 * Cons: Believed to be harder to use in practice. The {{{PromotedTupleT}}} construct here is not available in surface syntax. This also loses the ability to write succinct lists, while the original format proposed above allows for nil as a 0-element list. 
     50 
     51It may be worth noting that {{{'(,) Int Bool}}} is ''not'' a synonym for {{{'(Int,Bool)}}}. {{{'(,) Int Bool}}} is a parse error. 
     52 
     53=== Structured Kinds === 
     54 
     55Instead of the new {{{ListK}}} and {{{TupleK}}} kinds above, we could have the following: 
     56 
     57{{{ 
     58| ListK Kind     -- [k] 
     59| TupleK [Kind]  -- (k1,k2,...) 
     60}}} 
     61 
     62 * Pros: Perhaps easier to use. Mirrors surface syntax. 
     63 * Cons: Does not match internal GHC representation, including what is printed in error messages and such. Different from the way {{{Type}}} works. 
     64 
     65It may be worth noting that, in the kind language, {{{(,) Int Bool}}} is ''not'' a synonym for {{{(Int,Bool)}}}. {{{(,) Int Bool}}} is a parse error.