Prettify global type variables for error messages
@croyzor is already working on this.
Since Nov 20, 2024.
Assessment
This issue has not been assessed yet.
Description
Related to #20, in that this should be triggered with a --verbose-errors flag.
Types containing global variables of the form VPar a.b.c.d.e_1 0 are useful to us, but just line noise for end users. We should try to keep track of where these variables are defined from. I suspect there's often a good name in terms of user variables.
I.e. if a user binds a type variable (:: #) as n, we should call references to it n in error messages. If a user writes succ(n), we should print out n and n + 1 as appropriate
- Dominant language
- Haskell
- Stars
- 8
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Quantinuum/brat
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Quantinuum/brat#135 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Quantinuum/brat#130 ·
-
Quantinuum/brat#129 · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Quantinuum/brat#128 ·
-
Quantinuum/brat#127 · 1 assignee ·
Similar issues
-
time-manager-0.4.0 Openfailure: bounds
Difficulty 1/5 Under an hour Newbie friendliness 72/100
commercialhaskell/stackage#8122 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
simplex-chat/simplex-chat#7547 ·
-
chore
Difficulty 1/5 Under an hour Newbie friendliness 90/100
alunduil/alunduil-chezmoi#775 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
objectionary/phino#1350 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100