[GHC] #8305: ghci macros override built-ins for command expansion

16 Sep 2013

      #8305: ghci macros override built-ins for command expansion
------------------------------------+-------------------------------------
       Reporter:  rwbarton          |             Owner:
           Type:  bug               |            Status:  new
       Priority:  highest           |         Milestone:  7.8.1
      Component:  GHCi              |           Version:  7.6.3
       Keywords:                    |  Operating System:  Unknown/Multiple
   Architecture:  Unknown/Multiple  |   Type of failure:  None/Unknown
     Difficulty:  Unknown           |         Test Case:
     Blocked By:                    |          Blocking:
Related Tickets:  #8113             |
------------------------------------+-------------------------------------
 I have a ghci macro `:tsu` from the ghc-vis package, which I installed a
 long time ago. In HEAD ghci (since the patch for #8113) this causes `:t`
 to expand to `:tsu`, rather than `:type`. That happened to result in a
 weird error the first time I tried to use `:t` (something like
 `Prelude.read: no parse`), and it took me a while to diagnose that my
 `.ghci` file was the issue!

 I don't like this new behavior because it forces me to either change my
 ghci habits (start using `:type` instead of `:t`) or avoid macros starting
 with any letter that I currently use as a single-letter ghci command. I
 set this ticket priority to highest because in any event this new behavior
 shouldn't sneak in to a GHC release unnoticed.

 Below is my proposal for how `:commands` should be interpreted now that
 built-in commands can be overridden (#8113), copied from a comment I made
 recently on that ticket.

 ----

 I suppose what I specifically want to happen when I enter a `:command` is
 an algorithm like this.

 If the name I entered is an exact match for a macro or built-in, use that
 name.

 Otherwise, try to complete the name to the name of a ''built-in'' in the
 traditional way. If this succeeds, use the resulting name.

 Otherwise, try to complete the name to the name of a macro, and use the
 resulting name if that succeeds, otherwise give up.

 In all cases where we got a name, use the ''macro'' of that name if there
 is one, and otherwise use the built-in.  (Obviously, for `::command`,
 ignore macros entirely.)

 In other words, built-ins should take precedence over macros for the
 purpose of name ''completion'', but macros should take precedence over
 built-ins for the purpose of name ''lookup''.  This is backwards-
 compatible from the perspective of the user who is not aware of the
 change—`:t` will always mean `:type`, as long as the user has no macro
 named `:t`, just like in previous versions of ghci—while still allowing
 the aware user to redefine exactly what `:type` means.  And it's flexible
 enough in that if the user really wants `:t` to complete to some other
 macro `:test` that they've written, they can always define another macro
 `:t` to expand to `:test`.

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8305
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

tags

participants (1)