| 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?
GHC certainly supports new back ends. You'd probably want to replace the entire back end, and go from optimised Core to Javascript. Should be entirely feasible. I'm sure you are checking out all relevant stuff, but you don't mention: http://www.haskell.org/haskellwiki/STG_in_Javascript http://article.gmane.org/gmane.comp.lang.haskell.cafe/88970 https://plus.google.com/102016502921512042165/posts/Z7NtU4eF8Zh Difficulties may be in supporting all of GHC stuff, esp concurrency. Eg the I/O library depends heavily on concurrency, so you may need to replace it entirely. Keep us posted! Simon 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 | [email protected] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
