How does they compile it for JVM? To java-classes or to bytecode itself?
Yes.
And, in addition, to Java source code.
Frege – a Haskell for the JVM
41–50 of 51 posts
Re: Frege – a Haskell for the JVM
#42Earlier quoted context omitted.
Generally, >=
Uh, care to explain why you think something like compiling Haskell to Java will yield better performance than writing an optimizing compiler such as GHC, with its native backend and optimizations that are tailored specifically for the types of programs written in Haskell (including things like the runtime system such as the garbage collector)?
Sorry, riscy, with >= I mean, Frege programs will take longer than native ones.
Re: Frege – a Haskell for the JVM
#43How does this compare performance-wise to natively compiled code?
You can expect performance to be no better than a full-fledged native compiler for the language, if the native compiler was somewhat mature. In this particular case, Frege is compiling to Java source code (not JVM bytecode), and Java does not give precise control over how things should be done at runtime, such as object representations. Additionally, while the main Java compiler is reasonably mature, its optimization…
You nailed it.
OTOH, one experience we did make is that the JVM is not so bad in running pure code, as far as the JIT and GC is concerned.
The biggest hurdles on the JVM are: absence of value types (e.g. tuples), the smallish, fixed stack, and lack of tailcall bytecode.
Re: Frege – a Haskell for the JVM
#44How does Frege's performance compare to Haskell? The start-up time and over all.
To counter possible misunderstandings: Frege is not positioned against Haskell in any way. To the contrary!
When you don't need the JVM, by all means, use GHC or some other native Haskell compiler! You'll have more language extensions, libraries, and your program will be faster and use less memory in most cases.
Re: Frege – a Haskell for the JVM
#45Earlier quoted context omitted.
Uh, care to explain why you think something like compiling Haskell to Java will yield better performance than writing an optimizing compiler such as GHC, with its native backend and optimizations that are tailored specifically for the types of programs written in Haskell (including things like the runtime system such as the garbage collector)?
Sorry, riscy, with >= I mean, Frege programs will take longer than native ones.
Ah, okay. :)
Re: Frege – a Haskell for the JVM
#46Earlier quoted context omitted.
The below is the projects own take on that question: "Frege gives you the opportunity to use your skills on the JVM. Most idiomatic Haskell code will run in Frege unmodified or with only minimal, obvious adaptions. Even more important: you can bring your purely functional problem solution strategies to your Java projects."
This is ridiculously optimistic. Perhaps many toy programs can be easily converted, but real programs that use libraries other than base will not be so easy to migrate. I've used the Haste compiler which IS Haskell that supports ALL GHC extensions except TemplateHaskell, supports the Cabal build tool and in practice it has its own ecosystem; most of Hackage will not compile on it. Frege doesn't implement all the lang…
> I've used the Haste compiler which IS Haskell that supports ALL GHC extensions except TemplateHaskell, supports the Cabal build tool and in practice it has its own ecosystem; most of Hackage will not compile on it.
As someone who's standing on the precipice of GHCJS, Haste and PureScript, I'm very curious to hear about your Haste experiences in this regard.
(I've been using PureScript in my side-projects for a bit. For the sake of completeness of this list, I've tried Elm and am not interested.)
Re: Frege – a Haskell for the JVM
#47Are typeclasses possible on the JVM? I'm a .NET person, and I've always heard that typclasses aren't possible on the .NET CLR, so I wonder what's different about the JVM that makes this possible?
Frege has typeclasses (Haskell 2010). Whoever told you it's impossible in .NET is probably wrong. Don't you have interfaces in C# ? But you don't even need interfaces. Strictly speaking, unless you use typeclasses with polymorphic recursion, you don't need a runtime representation for typeclasses at all.
> Whoever told you it's impossible in .NET is probably wrong.
I think brianberns is probably referring to this: https://visualstudio.uservoice.com/forums/121579-visual-stud...
Re: Frege – a Haskell for the JVM
#48Earlier quoted context omitted.
This is ridiculously optimistic. Perhaps many toy programs can be easily converted, but real programs that use libraries other than base will not be so easy to migrate. I've used the Haste compiler which IS Haskell that supports ALL GHC extensions except TemplateHaskell, supports the Cabal build tool and in practice it has its own ecosystem; most of Hackage will not compile on it. Frege doesn't implement all the lang…
> I've used the Haste compiler which IS Haskell that supports ALL GHC extensions except TemplateHaskell, supports the Cabal build tool and in practice it has its own ecosystem; most of Hackage will not compile on it. As someone who's standing on the precipice of GHCJS, Haste and PureScript, I'm very curious to hear about your Haste experiences in this regard. (I've been using PureScript in my side-projects for a bit.…
I really want to like Haste. It supports nearly all features of GHC, it works with Cabal, it produces small output that can be understood/debugged. Its runtime is only 500 lines of clean javascript. I was able to build a toy app that shared code between client and server and let me use my existing tools to work on it (Hdevtools et al.). For awhile a nice react library was in development for it.
But... its lack of support for TemplateHaskell and native code means that a lot of firewalls/shims are required to share code with likely server programs. There is no support for common library types such as Text and Aeson types - ghcjs has shims for those that build without native dependencies. react-haskell library switched to ghcjs because the Haste ecosystem/development community is non-existent. And I would probably not build a serious project with Haste for the same reason.
ghcjs is nice but...it is too big in so many ways. The runtime footprint for real programs is very large. The complexity of it seems high and it still only has a single dedicated developer. I've heard its performance demands are high - it doesn't seem like something you'd want to run on a phone. It feels too risky to me - Purescript or Typescript is probably what I would go with for a serious project.
Re: Frege – a Haskell for the JVM
#49Earlier quoted context omitted.
Scala has typeclasses. It is not strictly equal to Haskell since it relies on the usage of `implicit`. Plus it doesn't enforce that there is only one typeclass per type in the classpath (I believe I remember that Haskell enforces that I compile time).
Implicit is basically just an implementation detail. The idea of only allowing one typeclass instance per data is generally referred as confluence and you're correct in that scala doesn't attempt to enforce it. I understand the Haskell communities desire for coherent typeclasses, but I still find the newtype work around cludge to allow multiple implementation of, say, Monoid to be quasi hacky. What's worse, you can s…
Compilation is too local, but why can't a postprocess of the linker check for orphan or incoherent instances?
Re: Frege – a Haskell for the JVM
#50Earlier quoted context omitted.
22 milliseconds? Unless I'm mistaken that's blazing fast?
I believe that's 220ms. Which isn't too bad. But Clojure can usually match that if you AOT everything. It's still too slow for serious command-line utils, though, so you're back to Haskell.
Or using a long-running system daemon to host the VM