Cannot override ghci builtin commands with :def[!]

In cabal we have a feature called "cabal repl" where it loads ghci with all the appropriate flags for the package or sandbox.

One of the nice things we want to do is extend the :reload (and related :add, :load) so that it calls out to cabal to run any pre-processors (e.g. hsc2hs, happy, alex etc).

Unfortunately the :def! command does not override builtin ghc commands. It looks like it works (:def reports the thing) but then the builtin command is still used, e.g.:

:def! reload (\_ -> print "yay" >> return "")
:def
the following macros are defined:
reload
:reload
Ok, modules loaded: none.

Related to this overriding, is that we also want a way to run the original (the builtin). Technically speaking it's possible using :undef, but then it's rather tricky to define again. You have to do something like define reload to call out to cabal, :undef reload, :reload, :def reload .... The tricky part is that last, we have to tie the knot, because that is the definition of :reload so it has to be able to access it's own code, tricky but not impossible (can load it from a file, but ugly).

So ideally we'd have something like :builtin [cmd] [args] that bypasses macros and executes the builtin command. Then we could define:

:def! reload :! cabal repl --reload ${other_stuff_here}
:builtin :reload

And similarly for the others :add, :load etc.

Trac metadata

Trac field	Value
Version	7.6.3
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	GHCi
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added GHCi Tfeature request Trac import labels

See cabal issue https://github.com/haskell/cabal/pull/1404

Fyi, while looking into implementing a :builtin <cmd> [args]-like facility I noticed it's already there, by using ::<cmd>:

   :def <cmd> <expr>           define command :<cmd> (later defined command has
                               precedence, ::<cmd> is always a builtin command)

So this leaves the issue of :def! not doing what it's expected to do (and probably to add documentation about the ::<cmd> feature to the GHC user guide, as I didn't see it mentioned there).

I've investigated a bit, the culprit seems to be 4f764d06 where the following diff fragment caused the macro-precedence to be reversed accidentally:

-      ':' : rest -> (rest, builtin_commands) -- "::" selects a builtin command
-      _ -> (str', macros ++ builtin_commands) } -- otherwise prefer macros
+      ':' : rest -> (rest, ghci_cmds) -- "::" selects a builtin command
+      _ -> (str', ghci_cmds ++ macros) } -- otherwise prefer macros

fyi, here's a working patch for GHC 7.6.3 (but it should be the same for GHC HEAD)

https://github.com/hvr/ghci-ng/commit/f480f2e444f9e225ece843f449c5f14df67adfe6

changed milestone to %7.8.1

Trac metadata

Trac field	Value
Type	FeatureRequest → Bug

added Tbug label and removed Tfeature request label

This analysis and fix look pretty plausible to me. Thanks hvr!

mentioned in commit 3229eadb

mentioned in commit 65b737fa

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

Trac metadata

Trac field	Value
Test case	→ ghci/scripts/T8113

I got caught off guard by hvr's change because I had a ghci macro :tsu I'd forgotten about which meant that every time I tried to :t something I got a weird error. Took me a while to figure out that it was my .ghci file at fault.

I suppose I could learn to use :type or ::t but I'd prefer not to have to. And I don't want to have to give up macros starting with t, and every other single-letter ghci command that I use. Can we please have macros override built-in commands, but still have :t expand to :type?

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.

mentioned in issue #8305 (closed)

Note: The builtin/custom precedence issue is continued in #8305 (closed)

Trac metadata

Trac field	Value
Related	→ #8305 (closed)

added Tfeature request label

added Pnormal label

mentioned in issue #17345 (closed)

mentioned in merge request !1934 (closed)

mentioned in commit 4798f3b9