UHC-like JavaScript backend in GHC
Hi all, Last year, I worked on improving the Utrecht Haskell Compiler (UHC) JavaScript backend[1] up to the point where it is now possible to write complete JavaScript applications with it. Alessandro Vermeulen then ported one of my web applications to the UHC JS backend, and we've started using the result of that in production afterwards. The result of these efforts were presented at IFL 2012 and HIW 2012 by Alessandro and Atze Dijkstra respectively. One of the most powerful new features of this backend, in addition to the customised RTS, is the small subset of JS we can use when importing JavaScript functions with the js calling convention. For example, we can import the push() method for arrays using (roughly) the following import declaration: foreign import js %1.push(%2) push :: JSArray a - a - IO (JSArray a) Here, we write a small expression in the import declaration, in which the object and arguments are numbered. The object argument, %1, corresponds to the `JSArray a` in the type signature of `push`, while the method argument %2 corresponds with the `a` in the type signature. Chris Done drew inspiration from this calling convention in designing the FFI for his Fay programming language[2]. One of UHC's nice features is that it is very easy to extend it, due to its heavy use of attribute grammars and its sophisticated variability management. Working on, and extending the UHC JavaScript backend was relatively easy because of this. One of UHC's downsides, however, is that it lags behind on supporting advanced language features, such as GADTs, functional dependencies, type families, etc. As a result, only a limited number of packages from Hackage can be compiled with UHC. In addition, some code requires additional workarounds and explicit type signatures, which would be redundant if, e.g., fundeps would be available. In an ideal situation, we can have both the js calling convention from UHC's JavaScript backend, and GHC's more advanced language support. Combined, we can use most libraries on Hackage, we don't have to worry about the lack of language support while designing our JS applications, and we don't have to use explicit type annotations in scenarios where, e.g. fundeps, would un-ambiguate the situation quite easily. In the near future (i.e. after I have finished my MSc thesis), I would like to get started with getting more familiar with GHC's internals. In particular, I would like to see if it is possible to implement the js calling convention in GHC and have GHC spit out JavaScript, much like UHC is currently doing. Before I get started: does the GHC architecture currently allow for adding a new calling convention which departs from the conventional C FFIs and introduces a custom RTS? If not, where are the current major bottlenecks? And would it be possible to remove these bottlenecks, without significantly affecting the compilation times, and without affecting the performance of generated native code (when the JS backend is not used)? Any input on this is appreciated :) Cheers, Jurriën [1] http://uu-computerscience.github.com/uhc-js/ [2] http://fay-lang.org ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use `trace` while debuging GHC
On Mon, Nov 12, 2012 at 5:15 AM, Richard Eisenberg e...@cis.upenn.edu wrote: I've recently used the conveniently-typed (pprTrace :: String - SDoc - a - a) for this purpose. You have to compile with -DDEBUG, but it works great. Richard To use pprTrace you don't actually need to compile with -DDEBUG, it only checks if -dno-debug-output has been specified on the command line: http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/src/Outputable.html#pprTrace http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/src/StaticFlags.html#opt_NoDebugOutput Cheers, Michal ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
Did you try -fpedantic-bottoms? Cheers, Simon On 08/11/2012 19:16, Edward Z. Yang wrote: It looks like the optimizer is getting confused when the value being evaluated is an IO action (nota bene: 'evaluate m' where m :: IO a is pretty odd, as far as things go). File a bug? Cheers, Edward Excerpts from Albert Y. C. Lai's message of Thu Nov 08 10:04:15 -0800 2012: On 12-11-08 01:01 PM, Nicolas Frisby wrote: And the important observation is: all of them throw A if interpreted in ghci or compiled without -O, right? Yes. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building GHC for BB10 (QNX)
On 10/11/2012 19:53, Stephen Paul Weber wrote: Hey all, I'm interesting in trying to get an initial port for BlackBerry 10 (QNX) going. It's a POSIXish environment with primary interest in two architechtures: x86 (for simulator) and ARMv7 (for devices). I'm wondering if http://hackage.haskell.org/trac/ghc/wiki/Building/Porting is fairly up-to-date or not? Is there a better place I should be looking? One big difference (which may turn out to be a problem) is that the readily-available QNX compilers (gcc ports) are cross-compilers. I realise that GHC has no good support to act as a cross-compiler yet, and anticipate complications arising from trying to build GHC using a cross-compiler for bootstrapping (since that implies GHC acting as a cross-compiler at some point in the bootstrapping). Any suggestions would be very welcome. Cross-compilation is the way to port GHC at the moment, although unfortunately our support for cross-compilation is currently under development and is not particularly robust. Some people have managed to port GHC using this route in recent years (e.g. the iPhone port). For the time being, you will need to be able to diagnose and fix problems yourself in the GHC build system to get GHC ported. Ian Lynagh is currently looking into cross-compilation and should be able to tell you more. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
On 12-11-12 11:34 AM, Simon Marlow wrote:
Did you try -fpedantic-bottoms?
Interesting option. And furthermore its doc refers to -fno-state-hack, too.
import Control.DeepSeq
import Control.Exception
main = do
evaluate (('a' : error A) `deepseq` putStrLn hi)
throwIO (userError B)
-O -fpedantic-bottoms = B
-O -fno-state-hack = A
-O both = A
7.4.2, linux 32-bit x86
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using DeepSeq for exception ordering
Did you try -fpedantic-bottoms?
I just tried. The exception (or seq?) is still optimized away.
Here is what I tried:
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
main = evaluate (('a' : undefined) `deepseq` return () :: IO ())
$ ghc -fforce-recomp -fpedantic-bottoms -O Foo.hs ./Foo echo bar
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
Linking Foo ...
bar
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
