Changes between Version 5 and Version 6 of TemplateHaskell/Annotations


Ignore:
Timestamp:
Oct 9, 2013 6:00:04 PM (7 months ago)
Author:
errge
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TemplateHaskell/Annotations

    v5 v6  
    9696 
    9797== Controversial: #8398, module list reification == 
    98 The #8397 from the previous paragraph is already useful on its own. Unfortunately, for HFlags purposes it's not enough: it only make it possible to get annotations for modules, values or types when you already know your target.  But in the case of `$initHFlags` we want to get all the flags that were defined somewhere below us in our import tree.  To do this, #8398 implements module listing.  Once we get back the module list, we can use the returned names to get the module annotations for all the modules and extract the flag data. 
     98The #8397 from the previous paragraph is already useful on its own. Unfortunately, for HFlags purposes it's not enough: it only make it possible to get annotations for modules, values or types when you already know your target.  But in the case of `$initHFlags` we want to get all the flags that were defined somewhere below us in our import tree.  To do this, #8398 implements module listing.  Once we have the module list, we can use the returned names to get the module annotations for all the modules and extract the flag data. 
    9999 
    100 The current patch is a bit controversial, it simply uses the currently loaded list of modules as a substitute for "module list of our dependencies".  This approximation is heavily used currently everywhere in GHC, but it can cause problems, as showed in #8426.  SPJ already stated (http://ghc.haskell.org/trac/ghc/ticket/7867#comment:12) that he doesn't agree to this approximation and we should work on something that is well defined.  I agree. 
     100The current patch is controversial: it simply uses the list of currently loaded modules as a substitute for "list of modules we depend on".  This approximation is used heavily in GHC, but it can cause problems, as showed in #8426.  SPJ already stated (http://ghc.haskell.org/trac/ghc/ticket/7867#comment:12) that he doesn't agree to this approximation and we should work on something that is well defined.  I agree. 
    101101 
    102102I propose to change this patch to properly construct the list of dependent modules and return that.  We would return `(pkgid, moduleid)` pairs for every module that is imported by us or imported by our imports transitively. 
    103103 
    104 **Here for sure we need design discussion, so please think about this and share your thoughts.**  This is not to say that design discussion is not welcome for the other patches, of course it is! 
     104**Here we definitely need a design discussion, so please think about this and share your thoughts.**  This is not to say that design discussion is not welcome for the other patches, of course it is!