[Template-haskell] Reification of local names

[Kamil Skalski]

Tuesday 22 June 2004 15:36, Simon Peyton-Jones wrote:
> | > One idea: add (Maybe Type) fields to many TH syntax forms, where the
> | > type checker can record types.  That's simple and direct.
> |
> | This is actually the way how we implemented it in Nemerle. Our syntax
>
> trees
>
> | has elements like E_typed { body : Typedtree.Expr } in Parsetree.Expr
>
> or
>
> | T_typed { body : Typedtree.Type } in Parsetree.Type, so we can store
>
> typed
>
> | parts in our ASTs.
> | Our quotations support this with
> | <[  $(e : typed) ]>  where `e' is a variable holding typed tree of
>
> expression
>
> | We can also build typed trees for types with quotation like
> | <[ ttype: int ]>
>
> Interesting ... but I'm afraid I don't understand what these notations
> mean.

This corresponds strongly to way how we perform translation in compiler - 
parser gives us parsetree (tree composed of Parsetree.Expr, Parsetree.Type, 
Parsetree.Pattern, etc.), macros are mainly of type
Parsetree.Expr -> Parsetree.Expr
and later we transform parsetree to typed tree (which are separate, 
unambiguated versions of Parsetree structures)

But sometimes our macros perform task, which compiler should do - they type 
parts of given parsetree, geting Typedtree as a result. In order to not loose 
informations (type variables restrictions, etc.) obtained, we must return 
those Typedtree parts embedded in Parsetree. So we created additional element 
of Parsetree, namely Parsetree.E_typed.

Our quotations are similar to TH, they are equivalent to creating AST by hand, 
so
<[ x ]> is equivalent to Parsetree.E_ref (Name ("x"))
and we can of course splice values into quotations

<[ f ($e) ]> is equivalent to 
Parsetree.E_call (Parsetree.E_ref (Name ("f")), e)

we also support other kinds of splices
<[ $(x : int) ]> is Parsetree.E_literal (L_int (x))

so following this design, 
<[ $(te : typed) ]> is Parsetree.E_typed (te)
where E_typed (of type Parsetree.Expr) holds variable of type Typedtree.Type

>
> Suppose you want to build a data structure from the original
> constructors, by hand as it were.  (Which Template Haskell certainly
> allows you to do.)  You don't want to supply all the types!  If pattern
> match over this structure, you aren't going to see types.  So the types
> must somehow be optional.  I don't want to have two completely
> different, but similar, data structures, one with types and one without.
> Hence the 'Maybe' part.  Is that what you have?

As I understand, you have the same datastructure for Typedtree and Parsetree, 
so adding to all its elements field optionally holding real type of given 
object seems to be a good idea.

And coming back to < ttype: int ]> it is equivalent to
Parsetree.T_typed (ty_type (typingcontext, Parsetree.T_app (Name ("int"))))

ty_type is compiler's procedure performing translation Parsetree.Type -> 
Typedtree.Type, so here we again create special element of parsetree holding 
typed tree. 

This way we can for example check if parameter supplied to macro is of type 
int of bool - great feature for generating different code according to type 
of object.
So my point is, that having ability to operate on AST enriched by typing 
information, being able to ask compiler about some local typing information 
is great and useful (according to our practical expiriences).

Kamil Skalski