How does this compare performance-wise to natively compiled code?
Generally, >=
Frege – a Haskell for the JVM
31–40 of 51 posts
Re: Frege – a Haskell for the JVM
#32Hopefully this can be turned into a GHC plugin providing an additional back-end with https://ghc.haskell.org/trac/ghc/ticket/11470
Re: Frege – a Haskell for the JVM
#33How does Frege's performance compare to Haskell? The start-up time and over all.
Re: Frege – a Haskell for the JVM
#34How does this compare performance-wise to natively compiled code?
Generally, >=
Can you explain why? I'm not an expert but I know that GHC relies on some sort of stack reduction machinery. Implement something like this on top of an existing VM, and you would lose some performance, I would say.
Re: Frege – a Haskell for the JVM
#35Are 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?
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 still fairly easily define multiple instances of the same typeclass accidentally (orphan instances) and the compiler won't catch it.
Re: Frege – a Haskell for the JVM
#36How does this compare performance-wise to natively compiled code?
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)?
Re: Frege – a Haskell for the JVM
#37How 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 optimizations are certainly tailored for idiomatic Java, which includes a lot of mutation, strict evaluation, and use of object-oriented programming. Haskell in particular has unevaluated expressions everywhere (thunks) because of lazy evaluation, and heavy use of first-class and recursive functions.
Re: Frege – a Haskell for the JVM
#38So then we have Haskell with Clojure.
Does that mean we can use Haskell with datomic?
Re: Frege – a Haskell for the JVM
#39How does they compile it for JVM? To java-classes or to bytecode itself?
Re: Frege – a Haskell for the JVM
#40Are 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?
Maybe it was valueclasses you heard were not possible on the jvm? I think those are indeed possible on the CLR but not on the jvm. PS: yes I know scala has value classes, but sometimes those have to be instantiated.