#1463: Module → Package lookup in ghc-pkg?
-------------------------------+--------------------------------------------
 Reporter:  [EMAIL PROTECTED]  |          Owner:             
     Type:  feature request    |         Status:  new        
 Priority:  normal             |      Milestone:  6.10 branch
Component:  Compiler           |        Version:  6.6.1      
 Severity:  normal             |     Resolution:             
 Keywords:                     |     Difficulty:  Unknown    
 Testcase:                     |   Architecture:  Unknown    
       Os:  Unknown            |  
-------------------------------+--------------------------------------------
Comment (by simonpj):

 Replying to [comment:8 guest]:

 > i'm having a minor problem with this one: getting the info is easy
 enough, but a name might be both module and something else, so i'd like
 `:info` to check both, reporting errors only if it can't find either. but
 the error output for the existing checks seems to be hardwired deep in the
 call chain, so i don't know how to disable that for names that have
 successful module information.

 I think that `GHC.parseName` should return an empty list (with no error
 message) if it doesn't find any bindings for the specified string.  That
 way the client of the API can complain if necessary.  Once `parseName` has
 returned a list of `Names` I think they should all be lookable up (using
 `GHC.getInfo`) without errors.

 `parseName` is defined in `InteractiveEval`.  It looks to me that it can
 fail in two ways:
   * `hscParseIdentifier` can fail, printing an error message, if the name
 doesn't look like an identifier (e.g. "foo/bar").
   * Then `TcRnDriver.tcRnLookupRdrName` can fail (printing an error
 message) if the name isn't in scope.  In both cases one could return an
 `Either` instead of a `Maybe` to contain the error messages.

 In general, making the GHC API return error messages rather than print
 them is a good idea.  (I think you can set the "how to print an error
 message" hook before calling the GHC API, which might serve the same
 purpose, but it's less functional.)

 does that help?

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1463#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to