A proper subset of Haskell that compiles to JavaScript.
Fay has the following properties:
Fay monad for side effects (think of it like IO)Install Fay from hackage
cabal install cpphs # make sure cpphs is in your PATH cabal install fay fay-base
Write awesome software
{-# LANGUAGE EmptyDataDecls #-}
module Hello where
import FFI
data Event
alert :: String -> Fay ()
alert = ffi "alert(%1)"
setBodyHtml :: String -> Fay ()
setBodyHtml = ffi "document.body.innerHTML = %1"
addWindowEvent :: String -> (Event -> Fay ()) -> Fay ()
addWindowEvent = ffi "window.addEventListener(%1, %2)"
greet :: Event -> Fay ()
greet event = do
putStrLn "The document has loaded"
setBodyHtml "Hello HTML!"
main :: Fay ()
main = do
putStrLn "Hello Console!"
alert "Hello Alert!"
addWindowEvent "load" greet
Compile it
fay Hello.hs --html-wrapper
--html-wrapper generates Hello.html that includes the compiled JavaScript.
The JavaScript problem is two-fold and can be described thus:
CoffeeScript is a syntactic layer above JavaScript that does not change semantics. It adds some additional syntactic constructs, but makes no fundamental changes, you are still essentially working in JavaScript, but with more convenient syntactic features.
Fay on the other hand is a different language to JavaScript entirely, with a different semantics. It is lazy, it has partial application and currying, pattern matching for all data types, all expressions are pure and only statements in the Fay monad can be impure.
LiveScript is also a similar approach in the wave of compile-to-JS projects that have developed in recent years. LiveScript's translation is also quite readable and predictable, this is also the only thing in common with Fay.
TypeScript is another superset of JavaScript. TypeScript adds syntactic sugar for classes and lambdas, and static typing with type inference. TypeScript can be a good choice when you have a large JS code base and you can't afford to migrate it to a new language, or if you are in a team that doesn't want to switch to a new language but still want to have some static guarantees. The type system is at the moment fairly limited with generics just recently being introduced. One problem is the existence of an any type which can propagate throughout your program, it's easy to write obviously incorrect programs that still typecheck and fail at runtime.
GHCJS aims to support as much of GHC as possible. This gives you STM, concurrency, and the ability to compile large portions of Hackage. Fay's approach is to stay close to JavaScript by supporting the available types, sticking to the single threaded runtime, producing small output, and making it easy to interoperate with JS libraries and applications. A potential problem with compiling GHC packages in that the dependencies easily get out of hand. When compiling to a binary this usually doesn't matter, but on the web just a couple of megabytes can be too much to serve to users. Fay is also a much smaller compiler, and the generated output is easier to read which makes it easier to debug your own code and contribute to the compiler itself.
For more comments see this reddit thread
Roy is an approach to bring functional programming to JavaScript, it has lots of interesting features but it has different syntax and type-system semantics to Haskell.
Elm, equally, is an approach to bringing functional programming to the web, and is less generic than Roy, as it specifically focuses on web programming. It, too, borrows from Haskell and looks a bit like it, but is (consciously) different in syntax and semantics.
Idris is a strictly evaluated dependently typed language with Haskell like syntax.
All of these languages are very interesting and promising approaches. What Fay offers is to keep the existing compiler, GHC, for its battle-tested type checking and code analysis, and to use existing parsers for Haskell to support a subset of its syntax. This way, one does not have to replace the tooling infrastructure and workflow that one is used to. With the exception of actions in the Fay monad, pure functions can be type checked and run within GHCi.
Additionally, because all Fay code is Haskell code, certain modules can be shared between the ‘native’ Haskell and ‘web’ Haskell, most interestingly the types module of your project. This enables two things:
The enforced (by GHC) coherence of client-side and server-side data types. The transparent serializing and deserializing of data types between these two entities (e.g. over AJAX).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3