#3858: the resolution of abbreviated commands in ghci is surprising.
---------------------------+------------------------------------------------
  Reporter:  Saizan        |          Owner:                  
      Type:  bug           |         Status:  closed          
  Priority:  normal        |      Milestone:  7.2.1           
 Component:  GHCi          |        Version:  6.12.1          
Resolution:  fixed         |       Keywords:                  
  Testcase:                |      Blockedby:                  
Difficulty:                |             Os:  Unknown/Multiple
  Blocking:                |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by batterseapower):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 I took the liberty of just pushing a fix for this:

 {{{
 commit 2a86d5c7db21b39673aa8f4ba2c6aee714719262
 Author: Max Bolingbroke <[email protected]>
 Date:   Sat Apr 2 23:59:06 2011 +0100

     Prefer builtin commands to macros in GHCi command resolution (#3858)

     Current precedence rules in GHCi are that:

      * User macros are *always* preferred in command resolution
      * User macros that are defined earlier are preferred to those that
        are defined earlier on
      * Builtin commands have lowest precedence

     However this caused user confusion because e.g. defining a macro
 beginning
     with "i" would override the standard :info command whenever the user
 typed
     the abbreviated command :i.

     The new precedence rules are based on the view that things defined
 earlier
     are always preferred to things defined later. The builtin commands are
 logic
     defined earliest of all (when GHCi starts) so they always take
 precedence.
 }}}

 Please revert if you disagree with my rationale.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3858#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to