Re: Status of the rich errors proposal

[Richard Eisenberg]

Ben Gamari is, I believe, leading the effort with that proposal. It continues 
to get attention but has not yet blossomed to something we're ready to debate 
widely. This is a hard nut to crack, and we'd like to get it right. So I guess 
all there is to say right now is that the effort is ongoing, but we don't have 
anything concrete to report at the moment.

Richard

> On Oct 23, 2019, at 7:52 AM, Javier Neira Sanchez  
> wrote:
> 
> Hi, lately i am being collaborated in the haskell-ide-engine (hie) repo and 
> one of the issues i get to fix was related with the parsing of ghc errors.
> It turns out that delimiters of terms in errors are different in windows 
> (`term') and *nix (‘term’) systems and that drive to parse errors.
> Quite code actions and diagnostics are based in parsing them and they were 
> broken in windows.
> I am afraid that the code is very brittle and close to human readable error 
> messages. the actual code look like this:
> 
> -- | Extract a term from a compiler message.
> -- It looks for terms delimited between '‘' and '’' falling back to '`' and 
> '\''
> -- (the used ones in Windows systems).
> extractTerm :: T.Text -> T.Text
> extractTerm txt =
>   case extract '‘' '’' txt of
> ""  -> extract '`' '\'' txt -- Needed for windows
> term -> term
>   where extract b e = T.dropWhile (== b)
> . T.dropWhileEnd (== e)
> . T.dropAround (\c -> c /= b && c /= e)
> 
> 
> or
> 
> extractImportableTerm :: T.Text -> Maybe (T.Text, SymbolImport SymbolType)
> extractImportableTerm dirtyMsg = do
>   (n, s) <- extractedTerm
>   let n' = T.strip n
>   return (n', s)
>   where
> importMsg = S.headMay
>   -- Get rid of the rename suggestion parts
>   $ T.splitOn "Perhaps you meant "
>   $ T.replace "\n" " "
>   -- Get rid of trailing/leading whitespace on each individual line
>   $ T.unlines
>   $ map T.strip
>   $ T.lines
>   $ T.replace "* " "" -- Needed for Windows
>   $ T.replace "• " "" dirtyMsg
> extractTerm prefix symTy =
>   importMsg
>   >>= T.stripPrefix prefix
>   >>= \name -> Just (name, Import symTy)
> extractType b =
>   extractTerm ("Not in scope: type constructor or class " <> b) Type
> extractedTerm = asum
>   [ extractTerm "Variable not in scope: " Symbol
>   , extractType "‘"
>   , extractType "`" -- Needed for windows
>   , extractTerm "Data constructor not in scope: " Constructor]
> 
> It is clearly unsatisfactory but hard to improve without changing the 
> messages to make it more structured.
> Moreover any legitimate change on errors to make it better will likely break 
> it.
> 
> After exposing my worries in the hie irc channel, @mpickering pointed out 
> that it is already a proposal to improve error messages:
> 
> https://github.com/bgamari/ghc-proposals/blob/rich-errors-proposal/proposals/-rich-errors-proposal.rst
>  
> 
> 
> that nicely will improve the state of things.
> 
> Otoh there are already a way to output ghc errors as json (see 
> https://gitlab.haskell.org/ghc/ghc/issues/13190 
> ). It contains valuable info 
> about the error in specific fields but the message itself is in plain text.
> So merging both features will let tools to handle compiler errors without use 
> the ghc api directly if needed.
> 
> what is the status of the proposal? hie an other tooling developers will 
> welcome it very heartly.
> 
> Thanks in advance!
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Simplifier bug fixed in GHC 8.8.1?

[Alexis King]

Wonderful, thank you for the investigation! (Well, maybe not so wonderful if it 
isn’t actually fixed yet, but your followup comment in the issue gives me hope 
it is.) I’ll take the discussion over there, then.

> On Oct 28, 2019, at 05:06, Sebastian Graf  wrote:
> 
> Hi Alexis,
> 
> I think the fact that it looks like it's fixed is only a coincidence. See 
> https://gitlab.haskell.org/ghc/ghc/issues/17409 
> , where I go into a bit more 
> detail.
> 
> Cheers
> Sebastian
> 
> Am Mo., 28. Okt. 2019 um 07:16 Uhr schrieb Alexis King  >:
> Hi all,
> 
> I have an odd question: I’ve bumped into a clear simplifier bug, and although 
> it only happens on GHC 8.6.5, not 8.8.1, I’d like to locate the change that 
> fixed it. My library’s test suite currently fails on GHC 8.6.5 due to the 
> bug, and I’d rather not force all my users to upgrade to 8.8 if I can help 
> it, so I’m hoping to find a workaround.
> 
> The minimal test case I’ve found for the bug is this program:
> 
> {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving, TypeFamilies 
> #-}
> 
> import Control.Exception
> import Control.Monad.IO.Class
> import Control.Monad.Trans.Identity
> import Control.Monad.Trans.Reader
> 
> class Monad m => MonadFoo m where
>   foo :: m a -> m a
> instance MonadFoo IO where
>   foo m = onException m (pure ())
> instance MonadFoo m => MonadFoo (ReaderT r m) where
>   foo m = ReaderT $ \r -> foo (runReaderT m r)
> deriving instance MonadFoo m => MonadFoo (IdentityT m)
> 
> type family F m where
>   F m = IdentityT m
> 
> newtype FT m a = FT { runFT :: F m a }
>   deriving (Functor, Applicative, Monad, MonadIO, MonadFoo)
> 
> main :: IO ()
> main = run (foo (liftIO (throwIO (IndexOutOfBounds "bang"
>   where
> run :: ReaderT () (FT (ReaderT () IO)) a -> IO a
> run = flip runReaderT () . runIdentityT . runFT . flip runReaderT ()
> 
> Using GHC 8.6.5 on macOS 10.14.5, compiling this program with optimizations 
> reliably triggers the -fcatch-bottoms sanitization:
> 
> $ ghc -O -fcatch-bottoms weird.hs && ./weird
> [1 of 1] Compiling Main ( weird.hs, weird.o )
> Linking weird ...
> weird: Bottoming expression returned
> 
> What goes wrong? Somehow the generated core for this program includes the 
> following:
> 
> lvl_s47B :: SomeException
> lvl_s47B = $fExceptionArrayException_$ctoException lvl_s483
> 
> m_s47r :: () -> State# RealWorld -> (# State# RealWorld, () #)
> m_s47r
>   = \ _ (eta_B1 :: State# RealWorld) -> raiseIO# lvl_s47B eta_B1
> 
> main_s2Ww :: State# RealWorld -> (# State# RealWorld, () #)
> main_s2Ww
>   = \ (eta_a2wK :: State# RealWorld) ->
>   catch# (case m_s47r `cast`  of { }) raiseIO# eta_a2wK
> 
> This core is completely bogus: it assumes that m_s47r is bottom, but m_s47r 
> is a top-level function! The program still passes -dcore-lint, unfortunately, 
> as it is still well-typed. (Also, in case it helps: 
> -ddump-simplifier-iterations shows that the buggy transformation occurs in 
> the first iteration of the very first simplifier pass.)
> 
> I’ve been trying to figure out what change might have fixed this so that I 
> can assess if it’s possible to work around, but I haven’t found anything 
> obvious. I’ve been slowly `git bisect`ing to look for the commit that 
> introduced the fix, but many of the commits I’ve tested cause unrelated 
> panics on my machine, which has been exacerbating the problem of the slow 
> recompilation times. I’m a little at wits’ end, but opening a bug report 
> hasn’t felt right, since the bug does appear to already be fixed.
> 
> Does this issue ring any bells to anyone on this list? Is there a particular 
> patch that landed between GHC 8.6.5 and GHC 8.8.1 that might have fixed this 
> problem? If not, I’ll keep trying with `git bisect`, but I’d appreciate any 
> pointers.
> 
> Thanks,
> Alexis
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> 

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Debugging specialization

[Richard Eisenberg]

Inspection Testing by Joachim Breitner may be of interest: 
https://arxiv.org/abs/1803.07130

> On Oct 25, 2019, at 5:34 PM, Alexis King  wrote:
> 
>> On Oct 25, 2019, at 04:07, Simon Peyton Jones  wrote:
>> 
>> |  I’ve noticed that Specialise.hs has handful of pprTrace calls sprinkled
>> |  about, but they are all commented out. Is the recommended method to just
>> |  uncomment these calls and rebuild GHC?
>> 
>> That's what I do.
> 
> Thanks, I did indeed end up doing this, and it was enough to diagnose my 
> problem.
> 
>> But it would be better to stand back a bit and ask "what information would I 
>> really like to see?" and then design some logging mechanism to show it.  I'd 
>> be happy to advise.
> 
> It would be nice to have a -dspecialise-check in the same vein as the 
> existing -dinline-check/-drule-check flags, which seems probably not too hard 
> to add. I unfortunately can’t dedicate the time to add it myself right now, 
> as I’ve solved my immediate problem and probably already sunk more time into 
> this than I ought to, but if it comes up again and I can spare the time I 
> might give it a shot.
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Handling source locations in HsSyn via TTG

[Richard Eisenberg]

A nice property of Solution D (and I think this is a new observation) is that 
we could accommodate both located source and unlocated. For example:

> data GhcPass (c :: Pass)   -- as today
> data Pass = MkPass Phase HasLoc
> data Phase = Parsed | Renamed | Typechecked
> data HasLoc = YesLoc | NoLoc
> 
> type instance WrapL (GhcPass (MkPass p YesLoc)) f = Located (f (GhcPass 
> (MkPass p YesLoc)))
> type instance WrapL (GhcPass (MkPass p NoLoc)) f = f (GhcPass (MkPass p 
> NoLoc))

I don't actually think this is a good idea, as it would mean making a bunch of 
functions polymorphic in the HasLoc parameter, which is syntactically annoying. 
But the existence of this approach suggests that the design scales.

Regardless of what you think of this new idea, I'm in favor of Solution D. I 
like my types to stop me from making errors, and I'm willing to put up with the 
odd type error asking me to write `unLoc` as I work in order to avoid errors.

Richard

> On Oct 28, 2019, at 10:30 AM, Vladislav Zavialov  
> wrote:
> 
>> Are you arguing for Solution D?  Or are you proposing some new solution E?  
>> I can't tell.
> 
> I suspect that I’m arguing for Solution B, but it’s hard to tell because it’s 
> not described in enough detail in the Wiki.
> 
>> Easy
>> 
>>  type instance WrapL ToolPass t = ...
>> 
>> What am I missing?
> 
> 
> This assumes that `WrapL` is an open type family. In this case, there’s no 
> problem. The merge request description has the following definition of WrapL:
> 
> type instance WrapL p (f :: * -> *) where
>  WrapL (GhcPass p) f = Located (f (GhcPass p))
>  WrapL p   f =  f p
> type LPat p = WrapL p Pat
> 
> That wouldn’t be extensible. However, if WrapL is open, then Solution D 
> sounds good to me.
> 
> - Vlad 
> 
>> On 28 Oct 2019, at 13:20, Simon Peyton Jones  wrote:
>> 
>> Vlad
>> 
>> Are you arguing for Solution D?  Or are you proposing some new solution E?  
>> I can't tell.
>> 
>> 
>> | As to merge request !1970, it isn’t good to special-case GhcPass in a
>> | closed type family, making other tools second-class citizens. Let’s say I
>> | have `MyToolPass`, how would I write an instance of `WrapL` for it?
>> 
>> Easy
>> 
>>  type instance WrapL ToolPass t = ...
>> 
>> What am I missing?
>> 
>> Simon
>> 
>> | -Original Message-
>> | From: Vladislav Zavialov 
>> | Sent: 28 October 2019 10:07
>> | To: Simon Peyton Jones 
>> | Cc: ghc-devs@haskell.org
>> | Subject: Re: Handling source locations in HsSyn via TTG
>> | 
>> | I care about this, and I maintain my viewpoint described in
>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
>> | kell.org%2Fpipermail%2Fghc-devs%2F2019-
>> | February%2F017080.html&data=02%7C01%7Csimonpj%40microsoft.com%7C06c859
>> | d8bc0f48c73cb208d75b8e895c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
>> | 7078540055975603&sdata=FhkqfWGXaNX%2Fz4IiCcvoVCyzVsSAlyz6Y1dxEGUjX9I%3
>> | D&reserved=0
>> | 
>> | I’m willing to implement this.
>> | 
>> | As to merge request !1970, it isn’t good to special-case GhcPass in a
>> | closed type family, making other tools second-class citizens. Let’s say I
>> | have `MyToolPass`, how would I write an instance of `WrapL` for it?
>> | 
>> | - Vlad
>> | 
>> | > On 28 Oct 2019, at 12:31, Simon Peyton Jones via ghc-devs > | d...@haskell.org> wrote:
>> | >
>> | > Friends
>> | >
>> | > As you know
>> | >
>> | >  • We are trying to use “Trees That Grow” (TTG) to move HsSyn towards
>> | a situation in which GHC is merely a client of a generic HsSyn data type
>> | that can be used by clients other than GHC.
>> | >  • One sticking point has been the question of attaching source
>> | locations.  We used to have a “ping-pong” style, in which very node is
>> | decorated with a source location, but that’s a bit more awkward in TTG.
>> | >  • This wiki page outlines some choices, while ticket #15495 has a
>> | lot of discussion.
>> | >  • HEAD embodies Solution A.  But it has the disadvantage that the
>> | type system doesn’t enforce locations to be present at all.   That has
>> | undesirable consequences (eg ticket #17330)
>> | >  • The proposal is to move to Solution D on that page; you can see
>> | how it plays out in MR !1970.
>> | >  • (I think Solutions B and C are non-starters by comparison.)
>> | > If you care, please check out the design and the MR.   We can change
>> | later, of course, but doing so changes a lot of code, including client
>> | code, so we’d prefer not to.
>> | >
>> | > Let’s try to converge by the end of the week.
>> | >
>> | > Thanks
>> | >
>> | > Simon
>> | >
>> | >
>> | >
>> | >
>> | >
>> | > ___
>> | > ghc-devs mailing list
>> | > ghc-devs@haskell.org
>> | >
>> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
>> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
>> | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C06c859d8bc0f48c73cb208d7
>> | 5b8e895c%7C72f988bf86f141af91ab2d7cd011db

Re: Handling source locations in HsSyn via TTG

[Vladislav Zavialov]

> Are you arguing for Solution D?  Or are you proposing some new solution E?  I 
> can't tell.

I suspect that I’m arguing for Solution B, but it’s hard to tell because it’s 
not described in enough detail in the Wiki.

> Easy
> 
>   type instance WrapL ToolPass t = ...
> 
> What am I missing?


This assumes that `WrapL` is an open type family. In this case, there’s no 
problem. The merge request description has the following definition of WrapL:

type instance WrapL p (f :: * -> *) where
  WrapL (GhcPass p) f = Located (f (GhcPass p))
  WrapL p   f =  f p
type LPat p = WrapL p Pat

That wouldn’t be extensible. However, if WrapL is open, then Solution D sounds 
good to me.

- Vlad 

> On 28 Oct 2019, at 13:20, Simon Peyton Jones  wrote:
> 
> Vlad
> 
> Are you arguing for Solution D?  Or are you proposing some new solution E?  I 
> can't tell.
> 
> 
> | As to merge request !1970, it isn’t good to special-case GhcPass in a
> | closed type family, making other tools second-class citizens. Let’s say I
> | have `MyToolPass`, how would I write an instance of `WrapL` for it?
> 
> Easy
> 
>   type instance WrapL ToolPass t = ...
> 
> What am I missing?
> 
> Simon
> 
> | -Original Message-
> | From: Vladislav Zavialov 
> | Sent: 28 October 2019 10:07
> | To: Simon Peyton Jones 
> | Cc: ghc-devs@haskell.org
> | Subject: Re: Handling source locations in HsSyn via TTG
> | 
> | I care about this, and I maintain my viewpoint described in
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
> | kell.org%2Fpipermail%2Fghc-devs%2F2019-
> | February%2F017080.html&data=02%7C01%7Csimonpj%40microsoft.com%7C06c859
> | d8bc0f48c73cb208d75b8e895c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> | 7078540055975603&sdata=FhkqfWGXaNX%2Fz4IiCcvoVCyzVsSAlyz6Y1dxEGUjX9I%3
> | D&reserved=0
> | 
> | I’m willing to implement this.
> | 
> | As to merge request !1970, it isn’t good to special-case GhcPass in a
> | closed type family, making other tools second-class citizens. Let’s say I
> | have `MyToolPass`, how would I write an instance of `WrapL` for it?
> | 
> | - Vlad
> | 
> | > On 28 Oct 2019, at 12:31, Simon Peyton Jones via ghc-devs  | d...@haskell.org> wrote:
> | >
> | > Friends
> | >
> | > As you know
> | >
> | >   • We are trying to use “Trees That Grow” (TTG) to move HsSyn towards
> | a situation in which GHC is merely a client of a generic HsSyn data type
> | that can be used by clients other than GHC.
> | >   • One sticking point has been the question of attaching source
> | locations.  We used to have a “ping-pong” style, in which very node is
> | decorated with a source location, but that’s a bit more awkward in TTG.
> | >   • This wiki page outlines some choices, while ticket #15495 has a
> | lot of discussion.
> | >   • HEAD embodies Solution A.  But it has the disadvantage that the
> | type system doesn’t enforce locations to be present at all.   That has
> | undesirable consequences (eg ticket #17330)
> | >   • The proposal is to move to Solution D on that page; you can see
> | how it plays out in MR !1970.
> | >   • (I think Solutions B and C are non-starters by comparison.)
> | > If you care, please check out the design and the MR.   We can change
> | later, of course, but doing so changes a lot of code, including client
> | code, so we’d prefer not to.
> | >
> | > Let’s try to converge by the end of the week.
> | >
> | > Thanks
> | >
> | > Simon
> | >
> | >
> | >
> | >
> | >
> | > ___
> | > ghc-devs mailing list
> | > ghc-devs@haskell.org
> | >
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C06c859d8bc0f48c73cb208d7
> | 5b8e895c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078540055975603&a
> | mp;sdata=CRYEYmjuAYYIhoAeTPbi%2FctCiWmkIjL6pKUTBgVBwo8%3D&reserved=0
> 

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Handling source locations in HsSyn via TTG

[Vladislav Zavialov]

> Note that the MR description is a little misleading and I should update it: 
> I'm using an open type family, really. 

Ah, that’s good to know. In this case, I’m in support.

- Vlad

> On 28 Oct 2019, at 13:13, Sebastian Graf  wrote:
> 
> Hi Vlad,
> 
> Note that the MR description is a little misleading and I should update it: 
> I'm using an open type family, really. See the section for solution D on the 
> wiki page that shows how to extend the approach to Haddock (which needs 
> SrcLocs, too).
> If I understand correctly, you're advocating solution B. If you can think of 
> any more Pros and Cons (comparing to solution D, in particular), feel free to 
> edit the wiki page.
> 
> Sebastian
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Handling source locations in HsSyn via TTG

[Simon Peyton Jones via ghc-devs]

Vlad

Are you arguing for Solution D?  Or are you proposing some new solution E?  I 
can't tell.


| As to merge request !1970, it isn’t good to special-case GhcPass in a
| closed type family, making other tools second-class citizens. Let’s say I
| have `MyToolPass`, how would I write an instance of `WrapL` for it?

Easy

type instance WrapL ToolPass t = ...

What am I missing?

Simon

| -Original Message-
| From: Vladislav Zavialov 
| Sent: 28 October 2019 10:07
| To: Simon Peyton Jones 
| Cc: ghc-devs@haskell.org
| Subject: Re: Handling source locations in HsSyn via TTG
| 
| I care about this, and I maintain my viewpoint described in
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
| kell.org%2Fpipermail%2Fghc-devs%2F2019-
| February%2F017080.html&data=02%7C01%7Csimonpj%40microsoft.com%7C06c859
| d8bc0f48c73cb208d75b8e895c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
| 7078540055975603&sdata=FhkqfWGXaNX%2Fz4IiCcvoVCyzVsSAlyz6Y1dxEGUjX9I%3
| D&reserved=0
| 
| I’m willing to implement this.
| 
| As to merge request !1970, it isn’t good to special-case GhcPass in a
| closed type family, making other tools second-class citizens. Let’s say I
| have `MyToolPass`, how would I write an instance of `WrapL` for it?
| 
| - Vlad
| 
| > On 28 Oct 2019, at 12:31, Simon Peyton Jones via ghc-devs  wrote:
| >
| > Friends
| >
| > As you know
| >
| > • We are trying to use “Trees That Grow” (TTG) to move HsSyn towards
| a situation in which GHC is merely a client of a generic HsSyn data type
| that can be used by clients other than GHC.
| > • One sticking point has been the question of attaching source
| locations.  We used to have a “ping-pong” style, in which very node is
| decorated with a source location, but that’s a bit more awkward in TTG.
| > • This wiki page outlines some choices, while ticket #15495 has a
| lot of discussion.
| > • HEAD embodies Solution A.  But it has the disadvantage that the
| type system doesn’t enforce locations to be present at all.   That has
| undesirable consequences (eg ticket #17330)
| > • The proposal is to move to Solution D on that page; you can see
| how it plays out in MR !1970.
| > • (I think Solutions B and C are non-starters by comparison.)
| > If you care, please check out the design and the MR.   We can change
| later, of course, but doing so changes a lot of code, including client
| code, so we’d prefer not to.
| >
| > Let’s try to converge by the end of the week.
| >
| > Thanks
| >
| > Simon
| >
| >
| >
| >
| >
| > ___
| > ghc-devs mailing list
| > ghc-devs@haskell.org
| >
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7C06c859d8bc0f48c73cb208d7
| 5b8e895c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078540055975603&a
| mp;sdata=CRYEYmjuAYYIhoAeTPbi%2FctCiWmkIjL6pKUTBgVBwo8%3D&reserved=0

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Handling source locations in HsSyn via TTG

[Sebastian Graf]

Hi Vlad,

Note that the MR description is a little misleading and I should update it:
I'm using an open type family, really. See the section for solution D on
the wiki page

that shows how to extend the approach to Haddock (which needs SrcLocs, too).
If I understand correctly, you're advocating solution B. If you can think
of any more Pros and Cons (comparing to solution D, in particular), feel
free to edit the wiki page.

Sebastian


Am Mo., 28. Okt. 2019 um 11:07 Uhr schrieb Vladislav Zavialov <
vladis...@serokell.io>:

> I care about this, and I maintain my viewpoint described in
> https://mail.haskell.org/pipermail/ghc-devs/2019-February/017080.html
>
> I’m willing to implement this.
>
> As to merge request !1970, it isn’t good to special-case GhcPass in a
> closed type family, making other tools second-class citizens. Let’s say I
> have `MyToolPass`, how would I write an instance of `WrapL` for it?
>
> - Vlad
>
> > On 28 Oct 2019, at 12:31, Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
> >
> > Friends
> >
> > As you know
> >
> >   • We are trying to use “Trees That Grow” (TTG) to move HsSyn
> towards a situation in which GHC is merely a client of a generic HsSyn data
> type that can be used by clients other than GHC.
> >   • One sticking point has been the question of attaching source
> locations.  We used to have a “ping-pong” style, in which very node is
> decorated with a source location, but that’s a bit more awkward in TTG.
> >   • This wiki page outlines some choices, while ticket #15495 has a
> lot of discussion.
> >   • HEAD embodies Solution A.  But it has the disadvantage that the
> type system doesn’t enforce locations to be present at all.   That has
> undesirable consequences (eg ticket #17330)
> >   • The proposal is to move to Solution D on that page; you can see
> how it plays out in MR !1970.
> >   • (I think Solutions B and C are non-starters by comparison.)
> > If you care, please check out the design and the MR.   We can change
> later, of course, but doing so changes a lot of code, including client
> code, so we’d prefer not to.
> >
> > Let’s try to converge by the end of the week.
> >
> > Thanks
> >
> > Simon
> >
> >
> >
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Simplifier bug fixed in GHC 8.8.1?

[Sebastian Graf]

Hi Alexis,

I think the fact that it looks like it's fixed is only a coincidence. See
https://gitlab.haskell.org/ghc/ghc/issues/17409, where I go into a bit more
detail.

Cheers
Sebastian

Am Mo., 28. Okt. 2019 um 07:16 Uhr schrieb Alexis King <
lexi.lam...@gmail.com>:

> Hi all,
>
> I have an odd question: I’ve bumped into a clear simplifier bug, and
> although it only happens on GHC 8.6.5, not 8.8.1, I’d like to locate the
> change that fixed it. My library’s test suite currently fails on GHC 8.6.5
> due to the bug, and I’d rather not force all my users to upgrade to 8.8 if
> I can help it, so I’m hoping to find a workaround.
>
> The minimal test case I’ve found for the bug is this program:
>
> {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving,
> TypeFamilies #-}
>
> import Control.Exception
> import Control.Monad.IO.Class
> import Control.Monad.Trans.Identity
> import Control.Monad.Trans.Reader
>
> class Monad m => MonadFoo m where
>   foo :: m a -> m a
> instance MonadFoo IO where
>   foo m = onException m (pure ())
> instance MonadFoo m => MonadFoo (ReaderT r m) where
>   foo m = ReaderT $ \r -> foo (runReaderT m r)
> deriving instance MonadFoo m => MonadFoo (IdentityT m)
>
> type family F m where
>   F m = IdentityT m
>
> newtype FT m a = FT { runFT :: F m a }
>   deriving (Functor, Applicative, Monad, MonadIO, MonadFoo)
>
> main :: IO ()
> main = run (foo (liftIO (throwIO (IndexOutOfBounds "bang"
>   where
> run :: ReaderT () (FT (ReaderT () IO)) a -> IO a
> run = flip runReaderT () . runIdentityT . runFT . flip runReaderT
> ()
>
> Using GHC 8.6.5 on macOS 10.14.5, compiling this program with
> optimizations reliably triggers the -fcatch-bottoms sanitization:
>
> $ ghc -O -fcatch-bottoms weird.hs && ./weird
> [1 of 1] Compiling Main ( weird.hs, weird.o )
> Linking weird ...
> weird: Bottoming expression returned
>
> What goes wrong? Somehow the generated core for this program includes the
> following:
>
> lvl_s47B :: SomeException
> lvl_s47B = $fExceptionArrayException_$ctoException lvl_s483
>
> m_s47r :: () -> State# RealWorld -> (# State# RealWorld, () #)
> m_s47r
>   = \ _ (eta_B1 :: State# RealWorld) -> raiseIO# lvl_s47B eta_B1
>
> main_s2Ww :: State# RealWorld -> (# State# RealWorld, () #)
> main_s2Ww
>   = \ (eta_a2wK :: State# RealWorld) ->
>   catch# (case m_s47r `cast`  of { }) raiseIO# eta_a2wK
>
> This core is completely bogus: it assumes that m_s47r is bottom, but
> m_s47r is a top-level function! The program still passes -dcore-lint,
> unfortunately, as it is still well-typed. (Also, in case it helps:
> -ddump-simplifier-iterations shows that the buggy transformation occurs in
> the first iteration of the very first simplifier pass.)
>
> I’ve been trying to figure out what change might have fixed this so that I
> can assess if it’s possible to work around, but I haven’t found anything
> obvious. I’ve been slowly `git bisect`ing to look for the commit that
> introduced the fix, but many of the commits I’ve tested cause unrelated
> panics on my machine, which has been exacerbating the problem of the slow
> recompilation times. I’m a little at wits’ end, but opening a bug report
> hasn’t felt right, since the bug does appear to already be fixed.
>
> Does this issue ring any bells to anyone on this list? Is there a
> particular patch that landed between GHC 8.6.5 and GHC 8.8.1 that might
> have fixed this problem? If not, I’ll keep trying with `git bisect`, but
> I’d appreciate any pointers.
>
> Thanks,
> Alexis
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Handling source locations in HsSyn via TTG

[Vladislav Zavialov]

I care about this, and I maintain my viewpoint described in 
https://mail.haskell.org/pipermail/ghc-devs/2019-February/017080.html

I’m willing to implement this.

As to merge request !1970, it isn’t good to special-case GhcPass in a closed 
type family, making other tools second-class citizens. Let’s say I have 
`MyToolPass`, how would I write an instance of `WrapL` for it?

- Vlad

> On 28 Oct 2019, at 12:31, Simon Peyton Jones via ghc-devs 
>  wrote:
> 
> Friends
> 
> As you know
> 
>   • We are trying to use “Trees That Grow” (TTG) to move HsSyn towards a 
> situation in which GHC is merely a client of a generic HsSyn data type that 
> can be used by clients other than GHC.
>   • One sticking point has been the question of attaching source 
> locations.  We used to have a “ping-pong” style, in which very node is 
> decorated with a source location, but that’s a bit more awkward in TTG.
>   • This wiki page outlines some choices, while ticket #15495 has a lot 
> of discussion.
>   • HEAD embodies Solution A.  But it has the disadvantage that the type 
> system doesn’t enforce locations to be present at all.   That has undesirable 
> consequences (eg ticket #17330)
>   • The proposal is to move to Solution D on that page; you can see how 
> it plays out in MR !1970.
>   • (I think Solutions B and C are non-starters by comparison.)
> If you care, please check out the design and the MR.   We can change later, 
> of course, but doing so changes a lot of code, including client code, so we’d 
> prefer not to.
> 
> Let’s try to converge by the end of the week.
> 
> Thanks
> 
> Simon
> 
>  
> 
>  
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Quick Q: do all FFI (non-primop) calls involve State# and RealWorld?

[Christopher Done]

Hi all,

I tried compiling this file:

{-# LANGUAGE NoImplicitPrelude #-}-- | Demonstrate various use of the
FFI.module Foreign whereimport Foreign.Cforeign import ccall "math.h
sin" sin :: CDouble -> CDoubleit :: CDoubleit = sin 1

And I’ve noticed that the annotated type given for this foreign op in Core,
is (# State# RealWorld, CDouble #), whereas I would have expected e.g.
CDouble.

Meanwhile, the foreign op call is passed a RealWorld argument.

Additionally, code that consumes the result of this foreign call expects a (#
CDouble #) as a return value.

So there are some assumptions I put in my interpreter to test this FFI call
out:

   1. Despite claiming to return the real world in a tuple, it actually
   should just return an unboxed tuple of the value.
   2. It should ignore the RealWorld argument entirely.

I assume, if I were to lift this function into returning IO, that I should
indeed return the RealWorld argument given. So the lesson is:

All FFI functions accept a RealWorld, and may return a 2-tuple of State#
RealWorld *if* it’s impure, else it’ll return a 1-tuple of the value.
Correct?

Can someone confirm that my observations are right? Also, if so, is there
somewhere I can read more about this?

Cheers

Chris
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Handling source locations in HsSyn via TTG

[Simon Peyton Jones via ghc-devs]

Friends
As you know

  *   We are trying to use "Trees That 
Grow" 
(TTG) to move HsSyn towards a situation in which GHC is merely a client of a 
generic HsSyn data type that can be used by clients other than GHC.
  *   One sticking point has been the question of attaching source locations.  
We used to have a "ping-pong" style, in which very node is decorated with a 
source location, but that's a bit more awkward in TTG.
  *   This wiki 
page
 outlines some choices, while ticket 
#15495 has a lot of discussion.
  *   HEAD embodies Solution A.  But it has the disadvantage that the type 
system doesn't enforce locations to be present at all.   That has undesirable 
consequences (eg ticket #17330)
  *   The proposal is to move to Solution D on that page; you can see how it 
plays out in MR !1970.
  *   (I think Solutions B and C are non-starters by comparison.)
If you care, please check out the design and the MR.   We can change later, of 
course, but doing so changes a lot of code, including client code, so we'd 
prefer not to.
Let's try to converge by the end of the week.
Thanks
Simon


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs