headers
Duncan Coutts | 8 Jun 2004 20:44
Picon
Picon

instance of Lift for Exp

Hi all,

the Exp type is not an instance of the Lift class. This is the sensible
thing most of the time so that you do not lift an expression when you
meant to splice it instead.

However in my experience it's sometimes useful (particularly when
writing code that generates code), so attached is a module which makes
it an instance. Like Text.Show.Functions, you should only import it if
you want it, not import it by default.

If people find this useful, I'd be quite happy to have it added to the
standard GHC TH libs. I've named it Language.Haskell.TH.LiftExp and
released it under GHC's BSD-style licence.

Issues:
      * At the moment it also exports instances for Ratio, Maybe,
        PackedString, (,) and (,,). In my opinion these instances should
        be exported from Language.Haskell.TH already in which case they
        could be deleted from this module. (Exporting the instance for
        PackedString and Ratio is not strictly necessary and perhaps not
        desirable.)
      * The encoding for unboxed integers is not pleasant. (Unboxed Ints
        are used in the definition of Name). If anyone can find a more
        straightforward encoding please tell me.

Duncan
Attachment (LiftExp.hs): text/x-haskell, 6302 bytes
(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Stefan Heimann
 | 
17 Jun 2004 16:45





Reification of local names


Hi!

I need to extract some type information from the syntax
tree. Therefore I need to reify non-global names. Take the following
example:

module A where

import Language.Haskell.TH

logQ = runIO . putStrLn

stringOfInfo (ClassI _) = "ClassI"
stringOfInfo (ClassOpI name t _ _) = "ClassOpI " ++ show name ++ " :: " ++ show t
stringOfInfo (TyConI _) = "TyConI"
stringOfInfo (DataConI name t _ _) = "DataConI " ++ show name ++ " :: " ++ show t
stringOfInfo (VarI name t _ _) = "VarI " ++ show name ++ " :: " ++ show t
stringOfInfo (TyVarI name t) = "TyVarI " ++ show name ++ " = " ++ show t

foo :: Q Exp -> Q [Dec]
foo e' = do e <- e'
            case e of
              LetE _ (VarE name) -> do info <- reify name
                                       logQ (stringOfInfo info)
            return []
---

module Main where

import A

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Simon Peyton-Jones
 | 
21 Jun 2004 18:52






Picon

Favicon

Gravatar





RE: Reification of local names


You're trying to use reify for something it's not designed for.

reify looks something up in the type environment, *at the point where
that Q computation was spliced in*.  So if I say

foo :: Q Info
foo = reify (mkName "wog")

then the reify will look up "wog" wherever I say $foo.  Not at the point
where foo is defined.

In this case, you're going to look up the name in  your syntax tree, but
you'll look it up in the type environment where $foo is spliced in --
which is the top level of module A.

The "right place" to find the type info for a given syntax tree is in
the syntax tree.  The type checker has processed your fragment 
	[| let f = \x -> x + 2 in f |]
You just want to see the types.   Currently there is no way to do that,
but people often ask for it.

One idea: add (Maybe Type) fields to many TH syntax forms, where the
type checker can record types.  That's simple and direct. 

A general question to TH aficionados: would this be useful?  Remember
that the type may not be fully precise, because it's the result of
type-checking an as-yet-unspliced fragment.

Simon


(Continue reading)






Permalink
| Reply
| 3 comments  
| 



  

  

  





headers


Duncan Coutts
 | 
21 Jun 2004 19:07






Picon

Picon





RE: Reification of local names


On Mon, 2004-06-21 at 17:52, Simon Peyton-Jones wrote:
> The "right place" to find the type info for a given syntax tree is in
> the syntax tree.  The type checker has processed your fragment 
> 	[| let f = \x -> x + 2 in f |]
> You just want to see the types.   Currently there is no way to do that,
> but people often ask for it.
> 
> One idea: add (Maybe Type) fields to many TH syntax forms, where the
> type checker can record types.  That's simple and direct. 
> 
> A general question to TH aficionados: would this be useful?  Remember
> that the type may not be fully precise, because it's the result of
> type-checking an as-yet-unspliced fragment.

I would certainly find this useful. I'm currently hacking Mark Jones's
Typing Haskell in Haskell implementation to work with TH so that I can
find the types of locally defined functions.

This obviously not an ideal long term solution (though it would be
better if TH could tell us the kinds of types and if we could ask
questions about instances of classes - eg "is this type foo (or more
generally this tuple of types) an instance of this class bar").

Duncan 






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Kamil Skalski
 | 
21 Jun 2004 19:11





Re: Reification of local names


Monday 21 June 2004 18:52, Simon Peyton-Jones wrote:
>
>
> The "right place" to find the type info for a given syntax tree is in
> the syntax tree.  The type checker has processed your fragment
> 	[| let f = \x -> x + 2 in f |]
> You just want to see the types.   Currently there is no way to do that,
> but people often ask for it.
>
> 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 ]>

For example our `if' expression is a macro checking type of condition to 
supply special error message:

 macro  <at> if (cond, e1, e2)
  syntax ("if", "(", cond, ")", e1, Optional (";"), "else", e2) 
  {
    def tcond = ty_expr (Nemerle.Macros.ImplicitCTX (), cond);
    def bool_ty = <[ ttype: bool ]>;

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Simon Peyton-Jones
 | 
22 Jun 2004 15:33






Picon

Favicon

Gravatar





RE: FW: TH quasi-quoting bug - fails on quoting	where clause inlet declcontext


Yes, same deal.  Reifying a tycoon gives you a Dec, and that could
easily be decorated with (Maybe Kind) additions. The Maybe is so that
when you construct a Dec yourself by hand, you don't have to supply the
kind information.

Simon

| -----Original Message-----
| From: Duncan Coutts [mailto:duncan.coutts <at> worcester.oxford.ac.uk]
| Sent: 22 June 2004 13:38
| To: Simon Peyton-Jones
| Subject: Re: FW: TH quasi-quoting bug - fails on quoting where clause
inlet declcontext
| 
| Cheers Simon.
| 
| BTW, Ian and I were looking the other day at how easy/difficult it
would
| be to get kind information when we reify type names. Does ghc have
that
| information readily available, or is it not so easy?
| 
| Duncan
| 
| On Tue, 2004-06-22 at 10:50, Simon Peyton-Jones wrote:
| > I don't know if I ever mentioned, but I fixed this a while back
| >
| > SImon
| >
| > -----Original Message-----

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Simon Peyton-Jones
 | 
22 Jun 2004 15:36






Picon

Favicon

Gravatar





RE: Reification of local names


| > 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.  

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?

Simon


(Continue reading)






Permalink
| Reply
| 501 comments  
| 



  

  

  





headers


Ian Lynagh
 | 
22 Jun 2004 16:26






Picon

Gravatar





Re: Reification of local names


On Mon, Jun 21, 2004 at 05:52:04PM +0100, 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. 
> 
> A general question to TH aficionados: would this be useful?  Remember
> that the type may not be fully precise, because it's the result of
> type-checking an as-yet-unspliced fragment.

I know almost nothing about views, but would they allow us to treat a
datatype with (Maybe Type)s as either one with Types or one identical to
what we currently have, at our choice?

I think there are probably cases where we will have to lose type info
when we manipulate datastructures in the second view, but overall I
think this could work well.

I don't relish the thought of having to sprinkle Nothings liberally over
my code.

Thanks
Ian






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Kamil Skalski
 | 
22 Jun 2004 17:47






Picon





Re: Reification of local names


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, 

(Continue reading)






Permalink
| Reply
| 501 comments  
| 



  

  

  

  


  





    



Gmane