Best way to build a GHC backend?
Venerable Haskell Hackers, I love Haskell and think it should run everywhere. Now supposing I would like to build another backend for GHC, perhaps for Java Bytecode, .Net CIL, or JavaScript, What would be the best way to approach that? I can think of a few options: 1. Produce External Core with -fext-core and compile that with a completely separate compiler 2. Use the GHC apis to build a compiler that reuses a load of GHC's code, but has it's own backend 3. Add a new backend directly into GHC Any other options? While I'm on the subject, why has Haskell not been ported to the likes of the JVM, .NET CLR, or JavaScript? Are Haskell's non-strict semantics just too different from the semantics of these other platforms? SPJ is known for saying that Haskell's plan for world domination is support for many parallelism/concurrency idioms. I believe running on many platforms is just as important. From my point of view, languages that cannot run on one of the 3 aforementioned platforms will become irrelevant. (with the exception of C, of course). Thoughts? --J Arthur
As to your porting of Haskell to the JVM question; the JVM would be unable
to perform all the optimizations that GHC can do. There is really not much
point in running slow code.
JavaScript is interesting since the JIT compiler gets better all the time.
On Sat, Jul 7, 2012 at 10:02 PM, Jonathan Geddes
Venerable Haskell Hackers,
I love Haskell and think it should run everywhere. Now supposing I would like to build another backend for GHC, perhaps for Java Bytecode, .Net CIL, or JavaScript, What would be the best way to approach that? I can think of a few options:
1. Produce External Core with -fext-core and compile that with a completely separate compiler 2. Use the GHC apis to build a compiler that reuses a load of GHC's code, but has it's own backend 3. Add a new backend directly into GHC
Any other options?
While I'm on the subject, why has Haskell not been ported to the likes of the JVM, .NET CLR, or JavaScript? Are Haskell's non-strict semantics just too different from the semantics of these other platforms?
SPJ is known for saying that Haskell's plan for world domination is support for many parallelism/concurrency idioms. I believe running on many platforms is just as important. From my point of view, languages that cannot run on one of the 3 aforementioned platforms will become irrelevant. (with the exception of C, of course).
Thoughts?
--J Arthur
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- -- Regards, KC
2012/7/8 Jonathan Geddes
Venerable Haskell Hackers,
I love Haskell and think it should run everywhere. Now supposing I would like to build another backend for GHC, perhaps for Java Bytecode, .Net CIL, or JavaScript, What would be the best way to approach that? I can think of a few options:
1. Produce External Core with -fext-core and compile that with a completely separate compiler 2. Use the GHC apis to build a compiler that reuses a load of GHC's code, but has it's own backend 3. Add a new backend directly into GHC
Any other options?
You can target LLVM bitcode and transform that. And there probably is an LLVM backend for your favourite target already.
While I'm on the subject, why has Haskell not been ported to the likes of the JVM, .NET CLR, or JavaScript? Are Haskell's non-strict semantics just too different from the semantics of these other platforms?
http://www.haskell.org/haskellwiki/GHC/FAQ#Why_isn.27t_GHC_available_for_.NE... "It would make a lot of sense to give GHC a .NET or JVM back end, and it's a question that comes up regularly. The reason that we haven't done it here, at GHC HQ, is because it's a more substantial undertaking than might at first appear (see below). Furthermore, it'd permanently add a complete new back-end platform for us to maintain. Given our rather limited development effort, we have so far not bitten the bullet, and we have no immediate plans to do so." The big problem seems to be to create a sensible interop to an object-orientated framework.
SPJ is known for saying that Haskell's plan for world domination is support for many parallelism/concurrency idioms. I believe running on many platforms is just as important. From my point of view, languages that cannot run on one of the 3 aforementioned platforms will become irrelevant. (with the exception of C, of course).
Thoughts?
Javascript (or a possiible common browser VM) seems essential. Server-side nobody knows or cares what you run on. It would be nice to be able to interop with Java or dotnet though.
--J Arthur
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
* Niklas Larsson:
http://www.haskell.org/haskellwiki/GHC/FAQ#Why_isn.27t_GHC_available_for_.NE... "It would make a lot of sense to give GHC a .NET or JVM back end, and it's a question that comes up regularly. The reason that we haven't done it here, at GHC HQ, is because it's a more substantial undertaking than might at first appear (see below). Furthermore, it'd permanently add a complete new back-end platform for us to maintain. Given our rather limited development effort, we have so far not bitten the bullet, and we have no immediate plans to do so."
The big problem seems to be to create a sensible interop to an object-orientated framework.
I think this is completely backwards. The hard part is porting the STG machine to the JVM in such a way that performance (speed and memory consumption) is acceptable. A toy port is probably not that hard if you know you way around in GHC, but its performance will be horrible. Useful Java interop is easy once you run on the JVM. There are already bindings for large OO code bases with their own object systems, so it's definitely possible to access OO code. Seemless interop is very difficult, but I don't think it's necessary.
I agree that the Raison d'être for a .NET or JVM backend is interop. Perhaps that's not worth the effort of an entirely new backend. JavaScript is a different beast, however. I said before:
From my point of view, languages that cannot run on one of the 3 aforementioned platforms will become irrelevant. (with the exception of C, of course).
I'll take that one step further and say that for web applications it is becoming increasingly difficult to justify using a language that WILL NOT run both client and server. JavaScript (with NodeJS), Clojure (with ClojureScript), and Dart are just a few examples. I really believe that with a solid JavaScript backend, Haskell would be an ideal web application language. Am I alone in that belief? What can I do to get the ball rolling on that? --J Arthur
On Sun, Jul 08, 2012 at 09:21:08AM -0600, Jonathan Geddes wrote:
I agree that the Raison d'être for a .NET or JVM backend is interop. Perhaps that's not worth the effort of an entirely new backend. JavaScript is a different beast, however. I said before:
From my point of view, languages that cannot run on one of the 3 aforementioned platforms will become irrelevant. (with the exception of C, of course).
I'll take that one step further and say that for web applications it is becoming increasingly difficult to justify using a language that WILL NOT run both client and server. JavaScript (with NodeJS), Clojure (with ClojureScript), and Dart are just a few examples.
I really believe that with a solid JavaScript backend, Haskell would be an ideal web application language. Am I alone in that belief? What can I do to get the ball rolling on that?
I should point out that the ball already IS rolling -- ranging from EDSLs that compile to JavaScript [1,2] to macro systems [3] to more serious full-featured efforts [4,5]. There's even a wiki page listing all these and more [6]. The yesod developers share your view that Haskell would benefit from some sort of JavaScript backend; see [7] as well as the ensuing discussion on Reddit [8]. See also Elm [9], which compiles to HTML+CSS+JavaScript and has some Haskell integration [10]. Rather than trying to start yet another effort, what about contributing to one of these ongoing ones? -Brent [1] http://www.ittc.ku.edu/csdlblog/?p=88 [2] http://www.ittc.ku.edu/csdl/fpg/node/125 [3] http://www.haskell.org/haskellwiki/JMacro [4] http://uu-computerscience.github.com/uhc-js/ [5] https://github.com/ghcjs/ghcjs [6] http://www.haskell.org/haskellwiki/The_JavaScript_Problem [7] http://www.yesodweb.com/blog/2012/04/client-side [8] http://www.reddit.com/r/haskell/comments/sm72n/client_side_yesod_an_frpinspi... [9] http://elm-lang.org/ [10] http://www.reddit.com/r/haskell/comments/uugne/announcing_elm_02_haskell_int...
Thanks for all the Info, Brent! I wasn't aware of many of those projects.
I agree that contributing to an existing project is a better idea than
doing something new. I suppose I was hoping there would be an official GHC
JavaScript backend so that it would be clear which of the efforts to
contribute to (and use).
-J Arthur
On Mon, Jul 9, 2012 at 8:38 AM, Brent Yorgey
On Sun, Jul 08, 2012 at 09:21:08AM -0600, Jonathan Geddes wrote:
I agree that the Raison d'être for a .NET or JVM backend is interop. Perhaps that's not worth the effort of an entirely new backend. JavaScript is a different beast, however. I said before:
From my point of view, languages that cannot run on one of the 3 aforementioned platforms will become irrelevant. (with the exception of C, of course).
I'll take that one step further and say that for web applications it is becoming increasingly difficult to justify using a language that WILL NOT run both client and server. JavaScript (with NodeJS), Clojure (with ClojureScript), and Dart are just a few examples.
I really believe that with a solid JavaScript backend, Haskell would be an ideal web application language. Am I alone in that belief? What can I do to get the ball rolling on that?
I should point out that the ball already IS rolling -- ranging from EDSLs that compile to JavaScript [1,2] to macro systems [3] to more serious full-featured efforts [4,5]. There's even a wiki page listing all these and more [6]. The yesod developers share your view that Haskell would benefit from some sort of JavaScript backend; see [7] as well as the ensuing discussion on Reddit [8]. See also Elm [9], which compiles to HTML+CSS+JavaScript and has some Haskell integration [10].
Rather than trying to start yet another effort, what about contributing to one of these ongoing ones?
-Brent
[1] http://www.ittc.ku.edu/csdlblog/?p=88 [2] http://www.ittc.ku.edu/csdl/fpg/node/125 [3] http://www.haskell.org/haskellwiki/JMacro [4] http://uu-computerscience.github.com/uhc-js/ [5] https://github.com/ghcjs/ghcjs [6] http://www.haskell.org/haskellwiki/The_JavaScript_Problem [7] http://www.yesodweb.com/blog/2012/04/client-side [8] http://www.reddit.com/r/haskell/comments/sm72n/client_side_yesod_an_frpinspi... [9] http://elm-lang.org/ [10] http://www.reddit.com/r/haskell/comments/uugne/announcing_elm_02_haskell_int...
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 9 July 2012 15:38, Brent Yorgey
I should point out that the ball already IS rolling -- ranging from EDSLs that compile to JavaScript [1,2] to macro systems [3] to more serious full-featured efforts [4,5].
Also, a JavaScript backend has recently been developed for Clean, the other major lazy functional language.
participants (6)
-
Brent Yorgey -
Florian Weimer -
Jonathan Geddes -
KC -
Niklas Larsson -
Stephen Tetley