Opened 6 years ago

Closed 5 years ago

Last modified 13 months ago

#8959 closed bug (fixed)

GHCi should honour UnicodeSyntax

Reported by: Fuuzetsu Owned by:
Priority: low Milestone: 8.0.1
Component: Compiler Version: 7.6.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D807
Wiki Page:

Description

When we load a module into GHCi with -XUnicodeSyntax, GHCi should default to printing information with the relevant unicode symbols.

*Communication> let a ∷ Int; a = 7
*Communication> :t a
a :: Int

Attachments (1)

ghc-print-unicode-flag.patch (3.5 KB) - added by int-e 5 years ago.
simple implementation of -fprint-unicode-syntax flag

Download all attachments as: .zip

Change History (30)

comment:1 Changed 6 years ago by hvr

What about compiler errors/warnings? Should those use UnicodeSyntax as well if enabled? What about ghc's compile messages in general?

comment:2 Changed 6 years ago by nomeata

Owner: set to nomeata

comment:3 Changed 6 years ago by Joachim Breitner <mail@…>

In 819e1f2c2e10268fe3edc8395f2707b93c9c6f4d/ghc:

Use UnicodeSyntax when printing

When printing Haskell source, and UnicodeSyntax is enabled, use the
unicode sytax characters (#8959).

comment:4 Changed 6 years ago by nomeata

That was indeed straight-forward, pushed.

comment:5 Changed 6 years ago by nomeata

Resolution: fixed
Status: newclosed

comment:6 Changed 6 years ago by hvr

Milestone: 7.10.1

comment:7 Changed 6 years ago by nomeata

Owner: nomeata deleted
Resolution: fixed
Status: closednew

I just noticed that my patch only works if -XUnicodeSyntax is passed on the command line, or set with :set. It does not work simply because you load a file with LANGUAGE UnicodeSyntax.

Should it? Other pragmas (tested it with RankNTypes) in a loaded file also don’t affect what you enter at GHCi.

Also, the pragma does not have an effect on the error message printed by the compiler in error messages from a file with UnicodeSyntax active. The dynflag passed to the pretty-printer seems to be a different one than used when type-checking.

(Reopening)

comment:8 Changed 6 years ago by Joachim Breitner <mail@…>

In b0215729214859051abf78f6cf5012805fe7d764/ghc:

Test case: GHCi uses UnicodeSyntax if the loaded file uses it.

Its marked as broken, as this does not work yet, but we are calling it a
day here soon, so I want this to be recorded (#8959).

comment:9 in reply to:  7 Changed 6 years ago by hvr

Replying to nomeata:

Should it? Other pragmas (tested it with RankNTypes) in a loaded file also don’t affect what you enter at GHCi.

Btw, the prompt is usually affected by :seti -X... rather than :set -X...

comment:10 Changed 6 years ago by nomeata

Resolution: fixed
Status: newclosed

Btw, the prompt is usually affected by :seti -X... rather than :set -X...

Yes, just read up on that in the docs. But :set is not wrong either...

So I guess there is a more general question there: If I load a module into GHCi with a * (i.e. the “inside view” with everything top-level in scope), then in a way I have “entered” that module. Shouldn’t then all language pragmas of that module hold for me as well? And as general as this question is, it has of course been discussed before. I found #5673 (which I even took part in – I need to buy better memory ;-)) which points to 3217#comment:15

So #3217 covers the remaining bits of this ticket well, closing this (again).

Last edited 6 years ago by nomeata (previous) (diff)

comment:11 Changed 6 years ago by nomeata

Sigh: #3217 is not all there is to fix.

Independent of GHCi we seem to want error messages from modules with UnicodeSyntax printed with that syntax. So we need to instrument SDoc in error messages with the settings from where the setting originated.

The dynflags passed in SDocContext does not work for this, as they are the dynflags in scope when the error is printed, i.e. outside the module scope.

There is precedence: The PrintUnqualified field of ErrMsg and later of PprUser transports information about how to pretty print stuff from the location of error to when its SDoc is rendered. I added a Bool there to indicate whether UnicodeSyntax should be used and it seems to work, but I’m not satisfied with this design.

Stored the change in the wip/T8959 branch, see 4a4e684f4/ghc.

comment:12 Changed 6 years ago by nomeata

Resolution: fixed
Status: closednew

comment:13 Changed 5 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:14 Changed 5 years ago by int-e

I'm unhappy with this change, because it uses a language extension that affects accepted input (namely, UnicodeSyntax) to modify the output of ghci. I would prefer having a ghci-specific option (say, :set +/-u or more verbosely, :set +/-unicodeoutput) instead.

This is not just cosmetics; the current behaviour broke lambdabot's :t and :k commands, which parse ghci's output.

comment:15 in reply to:  14 Changed 5 years ago by shachaf

I have the same problem with this change as int-e -- the extension previously affected only input and now silently started to affect output too. I've turned it off in my .ghci as a result. I also think that a separate output flag is the right approach -- compare -XExplicitForAll vs. -fprint-explicit-foralls.

comment:16 Changed 5 years ago by nomeata

The reference to -XExplicitForAll vs. -fprint-explicit-foralls is a good point..

But it’s already released, so any tools that are broken will likely get a fix anyways. I’m unsure on how to proceed here.

comment:17 Changed 5 years ago by int-e

I'm sorry I didn't find this while testing the release candidates. I did not expect such "simple" ghci queries to break, and besides lambdabot does not enable UnicodeSyntax by default, that's a customization for the one running on Freenode.

My current "fix" for lambdabot is to disable UnicodeSyntax for the two affected commands. This is the only sensible option because I do not want lambdabot to use the unicode symbols in its type signatures; in other words, fixing lambdabot properly (such that unicode syntax is allowed in the input) is not possible at this time.

How would you feel about keeping the current behaviour by default, but adding flags -fprint-unicode-syntax and -fno-print-unicode-syntax to override the default, regardless of whether UnicodeSyntax is enabled or not?

Last edited 5 years ago by int-e (previous) (diff)

Changed 5 years ago by int-e

simple implementation of -fprint-unicode-syntax flag

comment:18 Changed 5 years ago by int-e

I've implemented the simple semantics where -fprint-unicode-syntax determines whether printing types and kind uses unicode syntax or not. The three-state behaviour from comment 17 would require more work. In any case I'm now using this implementation with lambdabot.

(The patch is against ghc's HEAD; a patch for ghc-7.10.1 can be found in lambdabot's repository: https://github.com/lambdabot/lambdabot/blob/freenode/patches/ghc-7.10.1.patch)

comment:19 Changed 5 years ago by int-e

Differential Rev(s): Phab:D807

comment:20 in reply to:  18 Changed 5 years ago by int-e

Replying to int-e:

The three-state behaviour from comment 17 would require more work.

Perhaps more importantly, it would be more difficult to explain to users.

comment:21 Changed 5 years ago by Austin Seipp <austin@…>

In 6dd2765a300bb139b4ab67688dbc6f48de66969b/ghc:

Implement -f[no-]print-unicode-syntax flag for unicode syntax output (#8959)

There is currently no way to separate whether UnicodeSyntax is accepted
for input from the corresponding output syntax using unicode symbols.
This patch implements a separate flag for affecting ghc(i)'s output.

Signed-off-by: Bertram Felgenhauer <int-e@gmx.de>

Reviewed By: nomeata, austin

Differential Revision: https://phabricator.haskell.org/D807

GHC Trac Issues: #8959

comment:22 Changed 5 years ago by int-e

Is there a chance of getting the -fprint-unicode-syntax flag into 7.10.2?

Personally I think the chances of breaking anything are slim, but it's not an easy call to make. (I still regret that I didn't find this in the RCs)

comment:23 Changed 5 years ago by thomie

Here's another commit in the #8959 series: 6e4a75001fae1bf9251907d605b3f0b74da537cb

Author: Joachim Breitner <mail@joachim-breitner.de>
Date:   Fri Jun 6 18:07:29 2014 +0200

    Only use UnicodeSytanx pretty printing if the locale supports it
    
    using the same check as for unicode quotes.

comment:24 Changed 5 years ago by thomie

Milestone: 7.12.17.10.2
Status: newmerge

I think work is done here.

int-e is asking for a merge to 7.10.2 of 6dd2765a300bb139b4ab67688dbc6f48de66969b

comment:25 Changed 5 years ago by thoughtpolice

Hmmmm, I'm rather inclined to leave this one out I'm afraid. Does anyone have any opinions?

comment:26 Changed 5 years ago by thoughtpolice

Milestone: 7.10.27.12.1

comment:27 Changed 5 years ago by thoughtpolice

Resolution: fixed
Status: mergeclosed

After discussing it, I think we're going to punt this and just leave it to 7.12.1

comment:28 Changed 4 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:29 Changed 13 months ago by Krzysztof Gogolewski <krz.gogolewski@…>

In d555d4be/ghc:

Use unicode arrows with -fprint-unicode-syntax

Summary:
See #8959, this is one more place where we
can pretty-print Unicode syntax.

Test Plan: validate

Reviewers: nomeata, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #8959

Differential Revision: https://phabricator.haskell.org/D5439
Note: See TracTickets for help on using tickets.