#11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bitemyapp: Old description:

After a couple hours, 30-some browser tabs, and attempting to use ghc- simple to paper over some annoyances with GHC's API (dynFlags/session- stuff, particularly), I gave up.

I then opened up haskell-src-exts and found the function I wanted in a minute or two.

{{{#!hs

import qualified Language.Haskell.Exts.Parser as P

parsePls' :: String -> IO () parsePls' s = print $ P.parseExp s }}}

This is where I got stuck:

{{{ Prelude> parsePls "1 + 1" Too late for parseStaticFlags: call it before runGhc or runGhcT }}}

This is the code I was working with before I gave up on GHC:

{{{#!hs module ParsePls where

import DynFlags import FastString import qualified GHC import qualified GhcMonad as GM import HsSyn import Lexer import Outputable import Parser import RdrName import SrcLoc import StaticFlags import StringBuffer

import qualified Language.Haskell.GHC.Simple as S import qualified Language.Haskell.GHC.Simple.Types as ST

import System.Environment

main :: IO () main = do [expr] <- getArgs parsePls expr

parsePls :: String -> IO () parsePls s = do initStaticOpts let sbuf = stringToStringBuffer s srcloc = mkRealSrcLoc (mkFastString s) 1 1 (dynflags, _) <- S.getDynFlagsForConfig ST.defaultConfig -- dynflags <- undefined -- GHC.getSessionDynFlags -- unP :: P a -> PState -> ParseResult a

-- mkPState :: DynFlags -> StringBuffer -> RealSrcLoc -> PState -- parseExpression :: P (LHsExpr RdrName) -- type LHsExpr id = Located (HsExpr id) -- Defined in ‘HsExpr’

let parseResult = unP parseExpression (mkPState dynflags sbuf srcloc) case parseResult of POk _ (L _ mdl) -> print $ showPpr dynflags mdl PFailed ss _ -> do putStrLn "Error occurred!" print ss }}}

Is there a reason it has to be this difficult?

New description: After a couple hours, 30-some browser tabs, and attempting to use ghc- simple to paper over some annoyances with GHC's API (dynFlags/session- stuff, particularly), I gave up. I then opened up haskell-src-exts and found the function I wanted in a minute or two. {{{#!hs import qualified Language.Haskell.Exts.Parser as P parsePls' :: String -> IO () parsePls' s = print $ P.parseExp s }}} This is where I got stuck: {{{ Prelude> parsePls "1 + 1" Too late for parseStaticFlags: call it before runGhc or runGhcT }}} This is the code I was working with before I gave up on GHC: {{{#!hs module ParsePls where import DynFlags import FastString import qualified GHC import qualified GhcMonad as GM import HsSyn import Lexer import Outputable import Parser import RdrName import SrcLoc import StaticFlags import StringBuffer import qualified Language.Haskell.GHC.Simple as S import qualified Language.Haskell.GHC.Simple.Types as ST import System.Environment main :: IO () main = do [expr] <- getArgs parsePls expr parsePls :: String -> IO () parsePls s = do initStaticOpts let sbuf = stringToStringBuffer s srcloc = mkRealSrcLoc (mkFastString s) 1 1 (dynflags, _) <- S.getDynFlagsForConfig ST.defaultConfig -- dynflags <- undefined -- GHC.getSessionDynFlags -- unP :: P a -> PState -> ParseResult a -- mkPState :: DynFlags -> StringBuffer -> RealSrcLoc -> PState -- parseExpression :: P (LHsExpr RdrName) -- type LHsExpr id = Located (HsExpr id) -- Defined in ‘HsExpr’ let parseResult = unP parseExpression (mkPState dynflags sbuf srcloc) case parseResult of POk _ (L _ mdl) -> print $ showPpr dynflags mdl PFailed ss _ -> do putStrLn "Error occurred!" print ss }}} Whereas with haskell-src-exts I got: {{{ Prelude> parsePls' "1 + 1" ParseOk (InfixApp (Lit (Int 1)) (QVarOp (UnQual (Symbol "+"))) (Lit (Int 1))) }}} Which was perfectly satisfactory. Is there a reason it has to be this difficult? -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11301#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bitemyapp):

Willing to improve it, but it's very unclear what a good interface is supposed to be.

This is good: http://hackage.haskell.org/package/haskell-src-exts-1.17.1/docs/Language- Haskell-Exts-Parser.html#v:parseExp The code you posted is going to send new people running for the hills (or Rust. or OCaml). There's no documentation, no way of knowing why one would want a frontend plugin or what problem it is solving for us. Googling the error message I got earlier was quite fruitless too. We don't really have to spend a lot of time discussing the API. Just catching up the GHC API's UX to the standard set by haskell-src-exts is sufficient for my purposes. Is there a reason a parser of Haskell source code needs to emit IO? If not, then there should be types like this available: {{{#!hs parseExp :: String -> ParseResult Exp }}} even if there are nittier-grittier underlying functions/facilities available. Further, why doesn't `ParseResult` in the GHC API have a Show instance? Trying to figure out something simple like, "parse this expression from a string and print the parse tree to stdout", with GHC's API is way-way-way harder than it should be and adding "more stuff" that the user has to know-about, care-about, etc. isn't good enough. It also looks like this frontend plugin thing doesn't work for REPL use. This is also not satisfactory. I'm assuming there are serious, difficult technical reasons the API provided by GHC doesn't include a simple "just parse the damn string" function with a Showable ParseResult. Could someone please explain those reasons? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11301#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5aa29231ab7603537284eff5e4caff3a73dba6d2/ghc" 5aa29231/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5aa29231ab7603537284eff5e4caff3a73dba6d2" 'DynFlag'-free version of 'mkParserFlags' Obtaining a `DynFlags` is difficult, making using the lexer/parser for pure parsing/lexing unreasonably difficult, even with `mkPStatePure`. This is despite the fact that we only really need * language extension flags * warning flags * a handful of boolean options The new `mkParserFlags'` function makes is easier to directly construct a `ParserFlags`. Furthermore, since `pExtsBitmap` is just a footgun, I've gone ahead and made `ParserFlags` an abstract type. Reviewers: bgamari, alanz, sjakobi Reviewed By: bgamari, sjakobi Subscribers: mpickering, sjakobi, rwbarton, carter GHC Trac Issues: #11301 Differential Revision: https://phabricator.haskell.org/D5269 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11301#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"469fe6133646df5568c9486de2202124cb734242/ghc" 469fe61/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="469fe6133646df5568c9486de2202124cb734242" 'DynFlag'-free version of 'mkParserFlags' Summary: This is a fixed version of the reverted d2fbc33c4ff3074126ab71654af8bbf8a46e4e11 and 5aa29231ab7603537284eff5e4caff3a73dba6d2. Obtaining a `DynFlags` is difficult, making using the lexer/parser for pure parsing/lexing unreasonably difficult, even with `mkPStatePure`. This is despite the fact that we only really need * language extension flags * warning flags * a handful of boolean options The new `mkParserFlags'` function makes is easier to directly construct a `ParserFlags`. Furthermore, since `pExtsBitmap` is just a footgun, I've gone ahead and made `ParserFlags` an abstract type. Also, we now export `ExtBits` and `getBit` instead of defining/exporting a bunch of boilerplate functions that test for a particular 'ExtBits'. In the process, I also * cleaned up an unneeded special case for `ITstatic` * made `UsePosPrags` another variant of `ExtBits` * made the logic in `reservedSymsFM` match that of `reservedWordsFM` Test Plan: make test Reviewers: bgamari, alanz, tdammers Subscribers: sjakobi, tdammers, rwbarton, mpickering, carter GHC Trac Issues: #11301 Differential Revision: https://phabricator.haskell.org/D5405 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11301#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler