Browse files

Rewrite related work and conclusion

  • Loading branch information...
1 parent 7f2ffc4 commit 554c310fe028579878f6de00fc5fce0fa4304b11 @norm2782 norm2782 committed Nov 23, 2012
Showing with 44 additions and 27 deletions.
  1. +1 −0 EHC/text/LitAdm.bib
  2. +43 −27 EHC/text/TopicJavaScriptIFL.cltex
1 EHC/text/LitAdm.bib
@@ -460,6 +460,7 @@ @misc{www07yhc-javascript
@misc{www07haskell-in-browser , eprint = {papers/www07haskell-in-browser.pdf} , title = {{Haskell in web browser}} , year = {2007} , howpublished = {\verb||}}
@misc{www07functional-javascript , eprint = {papers/www07functional-javascript.pdf} , title = {{Functional Javascript}} , author = {Steele, Oliver} , year = {2007} , howpublished = {\verb||}}
@misc{www11ghcjs-git , eprint = {papers/www11ghcjs-git.pdf} , title = {{ghcjs: Haskell to Javascript compiler (via GHC)}} , author = {Nazarov , Victor} , year = {2011} , howpublished = {\verb||}}
+@misc{www11ghcjs-new , title = {{GHCJS: Haskell to JavaScript translator}} , author = {Mackenzie, Hamish and Stegeman, Luite and Nazarov, Victor} , year = {2012} , howpublished = {\verb||}}
@inproceedings{shields01haskell-oo-overloading , eprint = {papers/shields01haskell-oo-overloading.pdf} , title = {{Object-Oriented Style Overloading for Haskell}} , author = {Shields, Mark and Peyton Jones, Simon} , booktitle = {Workshop on Multi-Language Infrastructure and Interoperability} , year = {2001}}
@misc{kiselyov05haskell-oo , eprint = {papers/kiselyov05haskell-oo.pdf} , title = {{Haskell’s overlooked object system}} , author = {Kiselyov, Oleg and L\"ammel, Ralf} , year = {2005}}
@phdthesis{jansen10phd-itasks-sapl-funcweb , eprint = {papers/jansen10phd-itasks-sapl-funcweb.pdf} , title = {{Functional Web Applications, Implementation and Use of Client-Side Interpreters}} , author = {Jansen, Jan Martin} , school = {Radboud University Nijmegen} , year = {2010} , howpublished = {\verb||}}
70 EHC/text/TopicJavaScriptIFL.cltex
@@ -862,40 +862,47 @@ where the intermediate code is more imperative in nature.
% \paragraph{Other approaches.}
The idea of running Haskell in a browser is not new. To our knowledge first
-attempts to do so using JavaScript were done in the context of the York Haskell
+attempts to do so using JavaScript were made in the context of the York Haskell
Compiler (YHC) \cite{www07yhc-javascript}. The Document Object Model (DOM)
inside a browser was accessed via wrapper code generated from HTML standard
definitions \cite{www07haskell-in-browser}. However, YHC is no longer
maintained and direct interfacing to the DOM nowadays is replaced by libraries
built on top of the multiple DOM variations.
-The idea of running functional programs in a browser even goes further back to
-the availability of Java applets. The workflow framework |iTasks|, built on top
-of the Clean system \cite{www11clean-system}, uses a minimal platform
-independent functional language, SAPL, which is interpreted in the browser by
-code written in Java. The latest interpreter incarnations are written in
+% TODO: Explicitly mention GHCJS here
+GHCJS\cite{www11ghcjs-git,www11ghcjs-new} is an attempt to use the GHC API to
+create a dedicated Haskell to JavaScript compiler. It uses the C calling
+convention, rather than a dedicated |js| calling convention. A major advantage
+of using the GHC API is that a mature, production-ready compiler, with support
+for advanced type-system features is at the programmer's disposal, solving some
+of the issues we are currently experiencing due to lack of these advanced
+features in UHC. Currently, GHCJS does not support an import system like the
+one described in this paper, so its ability to use external APIs is limited.
+GHCJS' authors remarked that adding an FEL-like import mechanism to GHCJS
+should be relatively straight-forward.
+A very recent, and very promising looking attempt at cross-compiling Haskell to
+JavaScript is the Fay language\cite{fay-lang} by Chris Doner, which aims to
+support a subset of Haskell and compile to JavaScript. It, too, makes extensive
+use of GHC, giving it a production-ready Haskell compiler and type-checker to
+build on. In designing Fay's FFI, Doner drew some inspiration from the work we
+present here, namely the FEL.
+Rather than focussing on cross-compiling, ``Functional JavaScript''
+\cite{www07functional-javascript} offers a library for a more functional style
+of programming in JavaScript. ``Haskell in JavaScript''
+\cite{www10haskellinjavascript} offers an interpreter for Haskell, written in
+The workflow framework |iTasks|, built on top of the Clean system
+\cite{www11clean-system}, uses a minimal platform independent functional
+language, SAPL, which is interpreted in the browser by code written in Java.
+The latest interpreter incarnations are written in JavaScript
Although currently a Haskell front-end exists for Clean, the use of it in a
browser seems to be tied up to the iTasks system. The intermediate language
SAPL also does not provide the facilities as provided by our Haskell FFI.
-%This limits used code to that which is generated by the iTasks system.
-Of the GHC a version exists which generates JavaScript \cite{www11ghcjs-git},
-based on the GHC API, supporting the use of primitives but not the FFI.
-Further down we elaborate on some consequences of multiple platforms and
-backends relevant for this GHC backend variant as well.
-Both ``Functional javascript'' \cite{www07functional-javascript} and ``Haskell
-in Javascript'' \cite{www10haskellinjavascript} do not use a separate Haskell
-compiler. Instead, JavaScript is used directly in a functional style,
-respectively a small compiler for a subset of Haskell has been written in
-A more recent attempt at cross-compiling Haskell to JavaScript it the Fay
-language\cite{fay-lang}, which aims to support a subset of Haskell. It shows
-promise, and even draws some inspiration from the work we present here, namely
-the FEL. % TODO: Expand on this.. Fay has matured a bit in the mean time
%\subsection{Object orientation.}
@@ -969,9 +976,19 @@ For the variant of the JCU application as implemented for this paper more info
We have shown that the UHC is capable of supporting the development of complete
client-side web applications. This opens the door to Haskell-only web
development. In the process we added the FEL to UHC and provided a library that
-exposes the \js world to Haskell.
-Better abstractions are still required to reduce the amount of code that lives
+exposes the \js world to Haskell. Considering the increasing maturity of the
+GHC-based solutions, we can conclude that our two major contributions to
+solving the JavaScript problem are the FEL, and our experimental proof that
+writing a complete, non-trivial web application, optionally using external
+JavaScript libraries is now possible in Haskell. Since UHC does not support
+advanced Haskell language features, and GHC's development is faster and more
+consistent, it remains to be seen whether our implementation in UHC can grow to
+a mature tool for developing JavaScript applications. While still keeping this
+option open, we also call on authors of GHC-based solutions to consider using
+the contributions of this paper in their work.
+When it comes to libraries for writing JavaScript applications in Haskell,
+better abstractions are still required to reduce the amount of code that lives
in the |IO| monad directly, and to give programming with the UHC JavaScript
backend a more functional feel. While in most cases performance is acceptable,
it needs to be improved if computationally heavy functions are to be run on the
@@ -981,4 +998,3 @@ the client, UHC and Cabal will need some more work as well.

0 comments on commit 554c310

Please sign in to comment.