Re: Options for targeting Windows XP?

[Javier Neira Sanchez]

Hi all, only want to add a small note: there was (is?) a ghc fork targeting
the jvm where i had the luck to been able to contribute my two cents:
eta-lang (https://github.com/typelead/eta)
Unfortunately the startup behind it lost funds and it is stalled but i
still have the hope some day can be resurrected.

Javi Neira

El vie., 26 mar. 2021 10:42, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> escribió:

> This link gives some (old) background
>
>
> https://wiki.haskell.org/GHC/FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Moritz
> Angermann
> *Sent:* 26 March 2021 08:00
> *To:* Clinton Mead 
> *Cc:* ghc-devs 
> *Subject:* Re: Options for targeting Windows XP?
>
>
>
> I believe there is a bit of misconception about what requires a new
> backend or not. GHC is a bunch of different intermediate representations
> from which one can take off to build backends. The STG, or Cmm ones are the
> most popular. All our Native Code Generators and the LLVM code gen take off
> from the Cmm one. Whether or not that is the correct input representation
> for your target largely depends on the target and design of the
> codegenerator. GHCJS takes off from STG, and so does Csaba's GRIN work via
> the external STG I believe. IIRC Asterius takes off from Cmm. I don't
> remember the details about Eta.
>
>
>
> Why fork? Do you want to deal with GHC, and GHC's development? If not,
> fork. Do you want to have to keep up with GHC's development? Maybe not
> fork. Do you think your compiler can stand on it's own and doesn't follow
> GHC much, except for being a haskell compiler? By all means fork.
>
>
>
> Eta is a bit special here, Eta forked off, and basically started
> customising their Haskell compiler specifically to the JVM, and this also
> allowed them to make radical changes to GHC, which would not have been
> permissible in the mainline GHC. (Mainline GHC tries to support multiple
> platforms and architectures at all times, breaking any of them isn't really
> an option that can be taken lightheartedly.) Eta also started having Etlas,
> a custom Cabal, ... I'd still like to see a lot from Eta and the ecosystem
> be re-integrated into GHC. There have to be good ideas there that can be
> brought back. It just needs someone to go look and do the work.
>
>
>
> GHCJS is being aligned more with GHC right now precisely to eventually
> re-integrate it with GHC.
>
>
>
> Asterius went down the same path, likely inspired by GHCJS, but I think I
> was able to convince the author that eventual upstreaming should be the
> goal and the project should try to stay as close as possible to GHC for
> that reason.
>
>
>
> Now if you consider adding a codegen backend, this can be done, but again
> depends on your exact target. I'd love to see a CLR target, yet I don't
> know enough about CLR to give informed suggestions here.
>
>
>
> If you have a toolchain that functions sufficiently similar to a stock c
> toolchain, (or you can make your toolchain look sufficiently similar to
> one, easily), most of it will just work. If you can separate your building
> into compilation of source to some form of object code, and some form of
> object code aggregates (archives), and some form of linking (objects and
> archives into shared objects, or executables), you can likely plug in your
> toolchain into GHC (and Cabal), and have it work, once you taught GHC how
> to produce your target languages object code.
>
>
>
> If your toolchain does stuff differently, a bit more work is involved in
> teaching GHC (and Cabal) about that.
>
>
>
> This all only gives you *haskell* though. You still need the Runtime
> System. If you have a C -> Target compiler, you can try to re-use GHC's
> RTS. This is what the WebGHC project did. They re-used GHC's RTS, and
> implemented a shim for linux syscalls, so that they can emulate enough to
> have the RTS think it's running on some musl like linux. You most likely
> want something proper here eventually; but this might be a first stab at it
> to get something working.
>
>
>
> Next you'll have to deal with c-bits. Haskell Packages that link against C
> parts. This is going to be challenging, not impossible but challenging as
> much of the haskell ecosystem expects the ability to compile C files and
> use those for low level system interaction.
>
>
>
> You can use hackage overlays to build a set of patched packages, once you
> have your codegen working. At that point you could start patching ecosystem
> packages to work on your target, until your changes are upstreamed, and
> provide your user with a hackage overlay (essentially hackage + patches for
> specific packages).
>
>
>
> Hope this helps.
>
>
>
> You'll find most of us on irc.freenode.net#ghc
> 

Status of the rich errors proposal

[Javier Neira Sanchez]

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