Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,390
    • Issues 4,390
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 373
    • Merge Requests 373
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #8305

Closed
Open
Opened Sep 16, 2013 by rwbarton@trac-rwbarton

ghci macros override built-ins for command expansion

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 (closed)) 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 (closed)), 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.

Trac metadata
Trac field Value
Version 7.6.3
Type Bug
TypeOfFailure OtherFailure
Priority highest
Resolution Unresolved
Component GHCi
Test case
Differential revisions
BlockedBy
Related #8113 (closed)
Blocking
CC
Operating system
Architecture
Assignee
Assign to
7.8.1
Milestone
7.8.1 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#8305