It's indirectly already there:
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#t…
Possibly an additional pointer needs to be in the FAQ/things to watch out
for section.
On Tue, Dec 5, 2017 at 5:13 PM, David Feuer <david(a)well-typed.com> wrote:
> It sounds like this should be added to the GHCi documentation, even if
> it's not strictly about GHCi.
>
>
>
> David Feuer
> Well-Typed, LLP
>
> -------- Original message --------
> From: Evan Laforge <qdunkan(a)gmail.com>
> Date: 12/5/17 4:49 PM (GMT-05:00)
> To: Brandon Allbery <allbery.b(a)gmail.com>
> Cc: ghc-devs(a)haskell.org
> Subject: Re: Long standing annoying issue in ghci
>
> Here's what I use:
>
> :set prompt "\ESC[46m\STX%s>\ESC[39;49m\STX "
>
> I believe \STX is a signal to haskeline for control sequences.
> Documentation is here:
> https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt
>
> On Tue, Dec 5, 2017 at 12:57 PM, Brandon Allbery <allbery.b(a)gmail.com>
> wrote:
> > On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <
> cheater00(a)gmail.com>
> > wrote:
> >>
> >> without color coding the prompt so I can't really turn it off. It
> >> seems like a simple arithmetic issue somewhere in the readline
> >> implementation.
> >
> >
> > It's not arithmetic except in the sense that it's not doing *any* math.
> > Color codes in a terminal are necessarily implemented as character
> sequences
> > (this is pretty much the definition of a terminal interface), and
> haskeline
> > makes no effort to recognize them, so it treats them the same as
> displayed
> > character sequences and skips over them as if they were displayed
> > characters.
> >
> > GNU readline handles this by recognizing the character mode sequences as
> not
> > taking up character positions (this is more complex than you think given
> > that GNU readline doesn't assume all terminals obey the ANSI standard;
> as it
> > turns out, neither does haskeline, so it actually gets a bit nasty), and
> > recognizing the special behavior of carriage return, and providing \[ \]
> > escapes to declare the sequence inside as "invisible" to to character
> > positioning (and it's on the person crafting the prompt to insure that it
> > actually is). Beyond that, it'd actually have to implement a 'terminal
> > emulator' internally to get it right in all cases --- and i'd be on the
> user
> > to ensure their declared terminal type matches the actual one well enough
> > for the 'terminal emulator' to reflect the terminal's actual behavior, so
> > it'd be a potential source of even weirder behavior.
> >
> > So, (a) haskeline issue, not strictly ghc/ghci, and (b) not really
> fixable,
> > but partially work-around-able for common cases.
> >
> > --
> > brandon s allbery kf8nh sine nomine
> associates
> > allbery.b(a)gmail.com
> ballbery(a)sinenomine.net
> > unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs(a)haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs(a)haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
--
brandon s allbery kf8nh sine nomine associates
allbery.b(a)gmail.com ballbery(a)sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
It sounds like this should be added to the GHCi documentation, even if it's not strictly about GHCi.
David FeuerWell-Typed, LLP
-------- Original message --------From: Evan Laforge <qdunkan(a)gmail.com> Date: 12/5/17 4:49 PM (GMT-05:00) To: Brandon Allbery <allbery.b(a)gmail.com> Cc: ghc-devs(a)haskell.org Subject: Re: Long standing annoying issue in ghci
Here's what I use:
:set prompt "\ESC[46m\STX%s>\ESC[39;49m\STX "
I believe \STX is a signal to haskeline for control sequences.
Documentation is here:
https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt
On Tue, Dec 5, 2017 at 12:57 PM, Brandon Allbery <allbery.b(a)gmail.com> wrote:
> On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <cheater00(a)gmail.com>
> wrote:
>>
>> without color coding the prompt so I can't really turn it off. It
>> seems like a simple arithmetic issue somewhere in the readline
>> implementation.
>
>
> It's not arithmetic except in the sense that it's not doing *any* math.
> Color codes in a terminal are necessarily implemented as character sequences
> (this is pretty much the definition of a terminal interface), and haskeline
> makes no effort to recognize them, so it treats them the same as displayed
> character sequences and skips over them as if they were displayed
> characters.
>
> GNU readline handles this by recognizing the character mode sequences as not
> taking up character positions (this is more complex than you think given
> that GNU readline doesn't assume all terminals obey the ANSI standard; as it
> turns out, neither does haskeline, so it actually gets a bit nasty), and
> recognizing the special behavior of carriage return, and providing \[ \]
> escapes to declare the sequence inside as "invisible" to to character
> positioning (and it's on the person crafting the prompt to insure that it
> actually is). Beyond that, it'd actually have to implement a 'terminal
> emulator' internally to get it right in all cases --- and i'd be on the user
> to ensure their declared terminal type matches the actual one well enough
> for the 'terminal emulator' to reflect the terminal's actual behavior, so
> it'd be a potential source of even weirder behavior.
>
> So, (a) haskeline issue, not strictly ghc/ghci, and (b) not really fixable,
> but partially work-around-able for common cases.
>
> --
> brandon s allbery kf8nh sine nomine associates
> allbery.b(a)gmail.com ballbery(a)sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs(a)haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
ghc-devs(a)haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
(GHC newbie alert -- is this the right mailing list for these kind of
questions?)
I"m writing some code to figure out all the instances of particular
type-classes and after exploring a lot of options (hlint, haskell-src-exts,
annotations, doctests, etc), I realized that the compiler had already
figured it out and written it to disk for me!
More digging led me to
https://www.stackage.org/haddock/lts-9.0/ghc-8.0.2/LoadIface.html#v:loadSrc…
after which I got stuck. How does one call this function? Specifically:
* What is SDoc and how to construct a reasonable value for this argument?
* IsBootInterface would mostly be False, right?
* What does `Maybe FastString` represent and how does one construct it?
* Finally how does one evaluate the resulting monadic action to get access
to the underlying `ModIface`?
-- Saurabh.
Thank you for the suggestions!
Setting the -fdefer-type-errors flag is indeed a good way to do it (with
also adding Opt_DeferTypedHoles and Opt_DeferOutOfScopeVariables for
other kind of errors).
Boldizsár
2017.12.01. 4:12 keltezéssel, Christopher Done írta:
> I suppose setting -fdefer-type-errors would also be handy in this
> scenario!
>
> On Thu, 30 Nov 2017 at 15:37, Simon Peyton Jones via ghc-devs
> <ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org>> wrote:
>
> This sounds like a good project!
>
> For the most part things look good:
>
> * Most type checker errors arise from *type constraints*. The type
> checkder tries to solve these, but returns an elaborated syntax
> tree (i.e. typechecked, and annotated with types) even if
> constraint solving fails.
>
> * Some renamer errors are like this, notably out-of-scope
> variables. (They just show up as another constraint.)
>
> However there is historical baggage. Back in the beginning, most
> errors were treated by throwing an exception in the typechecker
> monad; such exceptions can be caught, so that we can get more than
> one error from the file, but no syntax tree is returned. Example
> let f = <expression> in <body>
> If there was an error in <expression> we'd throw an exception,
> catch it at the 'let', give 'f' the type
> f :: forall a. a
> and continue to typecheck <body>.
>
> The trouble with the exception stuff is that you don't get an
> elaborated syntax tree.
>
> So: I think you can get some of the way today, just by returning
> the tree anyway even if there is an error to report. But it'd
> take a bit more work to make more and more errors into things that
> don't throw an exception. (Look for failTc, failRn in thd code.)
>
> I'm not very familiar with the GHC API for this part, but others
> will be. I'm certain it can be improved, so rather than hacking
> around what is there already, do propose and implement improvements.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org
> <mailto:ghc-devs-bounces@haskell.org>] On Behalf Of Németh
> | Boldizsár
> | Sent: 30 November 2017 05:42
> | To: ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org>
> | Subject: GHC typecheck API
> |
> | Dear GHC developers,
> |
> | I'm developing a framework for development tools for Haskell. I
> use the
> | GHC API to parse and typecheck the source files. I recently
> started to
> | work on a quick-fix (automatic program correction) for Haskell
> source
> | code (correcting parenthesis problems, like 'putStrLn "xxx" ++
> show a'
> | ==> 'putStrLn ("xxx" ++ show a)'). To do that I need to get the
> typed
> | syntax tree even if the program contains type or rename errors.
> I could
> | only do this by a nasty hack, adding a new TH module finalizer
> | (tcg_th_modfinalizers) to extract the type checker's state before it
> | fails. Is there a "correct" way to do this? I would not like this
> | refactorings to be unusable if the GHC API changes.
> |
> | By the way, if you know of any similar attempt please let me know.
> |
> | Sincerely,
> | Boldizsár Németh
> | haskelltools.org <http://haskelltools.org>
> |
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org>
> |
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> | ell.org <http://ell.org>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> | devs&data=02%7C01%7Csimonpj%40microsoft.com
> <http://40microsoft.com>%7C364b8db55e064415650d08d537b
> |
> 5323f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636476173738772433&sda
> | ta=Kf5rZYwht8ZGBtGNNH6Q44wLIeefxzHn2UfDIdrNNMU%3D&reserved=0
> _______________________________________________
> ghc-devs mailing list
> ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
