4 ms·

This might be helpful: * https://github.com/typelead/eta/blob/master/docs/source/faq.rst#how-is-eta-different-from-frege https://github.com/typelead/eta/blob/m

• paulddraper 10y ago
  tl;dr Freda uses a modified version of GHC and doesn't have a lot of commonly used extensions.
  • dualogy 10y ago
    I'd hope Eta "just" focuses on compiling GHC's core (not Core) intermediate-representation STG (or C--) into Java bytecode: then, no need to forever catch up re-implementing the ever-evolving language extensions, plus this just gets you all the desugaring / Core-to-Core optimization/simplification roundtrips, custom rewrite-rules, type checking / verification etc pp from GHC. In fact no need for any great checks and verifications, "just" (probably highly intricate in the end) a series of code format transformations.. in theory ;) GHC's various intermediate representations are pretty brilliant and thus I think should be leveraged as much as possible when it comes to new compilation targets and transpilation. Fun fact, seems as of 2002 there was for a while an STG-to-JVM backend. Now there's issues with this approach too! You'd end up with a massively convoluted set of mappings of Haskell's factory defaults to the JVM's. We're talking the equivalents of `Prelude` module, `base` package, the RTS (garbage collector and much more.. ouch!), and for each and every individual instance deciding where to draw the line between Java's built-ins' semantics and GHC's would be a massive challenge. What's with GHC's existing LLVM backend, does LLVM not have their own Java byte-code backend(s)? (OTOH, additional major dependencies always kinda bite..)
    • rahulmutt 10y ago
      Eta in fact only deals with STG code -> Java bytecode transformation. I agree that the intermediate transformations are brilliant, so I am very careful about playing around with the frontend bit of the GHC codebase. Eta currently implements almost all of GHC's primitive operations faithfully. I have taken extreme care in preserving semantics. In some obscure cases though, I just gave up since there are no platform-independent ways of implementing certain things (like vectorised instructions).
      • dualogy 10y ago
        Now that's awesome to hear! Can't wait to give this a go for making an Android app on the next occasion that pops up
        • sbare109 10y ago
          Frege already has an Android library on the works. You could try that.
        • sbare109 10y ago
          Frege already has an Android library on the works. You could try that.
        • rahulmutt 10y ago
          GHC 8 will take some time. The current position is to prioritize those new extensions which start creeping up in Hackage libraries. There were significant changes to the codebase in 8 and I want to wait until it's stabilized. Eventually, yes.
          • dualogy 10y ago
            I thought most extensions "just provide sugar" and are gone by the STG stage.. guess not =)
            • rahulmutt 10y ago
              No, you're right. I just don't want to swap out the frontends right now (again, stability). I'll definitely be cherry picking bug fixes and non-pervasive changes once I get a solid test/benchmark suite setup.
      • dualogy 10y ago
        But then GHC v8 compatibility should surely be on the horizon, right?