CompileToJS generates objects using "ctor:"... for all non-primitives.
Added special handling for lists
Might be better to have a separate tag instead of: Data "Nil"
Test case:
main_join = let f x xs = (x::xs)
in asText $ zipWith f ['c','m','t'] ["hop","ill","ape"]
before fails with "xs: undefined".
See: 14e32add30
for discussion on first attempt
Changed Librarys.hs and LoadLibraries.hs from TemplateHaskell to usafeIO.
Avoids needing to touch LoadLibraries after we change docs.json (as the file is loaded at runtime).
Also removes need for using CPP
Drawback of using unsafeIO is fairly well known/understood + this is a classic use-case.
Added error handling to LoadLibraries.hs
Setup.hs now uses "runProcess" instead of "system" to invoke elm compiler.
This allows us to set the environment variable "Elm_datadir" which is picked up by LoadLibraries and makes sure we get the just-built version in dist/data.
Also explicitly sets the RTS file to make sure we're not using one (as we're currently building it!)
Also change the folder the compiled JavaScript ends up in to dist/js. Writing to the source tree, then deleting isn't very nice + this should make it easier to find elm compilation errors. cabal clean handles the file deletion, too.
I think this fixes all the defects of the first version:
1. CPP is not needed
2. touch is not needed
3. building elm-runtime.js uses dist/data/docs.json
4. running elm after install uses the installed elm-runtime.js and docs.json
5. LoadLibraries.hs is simpler. Doesn't use CPP or TemplateHaskell. Has error handling and a decent error message
6. cabal clean && cabal install builds everything with the right data in the right order
(tested on ghc 7.4.1)
See: https://github.com/evancz/Elm/issues/120
Add build-hook to Setup.hs so that elm-doc gets build and executed before library or elm exec gets built.
Add preprocessor to Elm.cabal so LoadLibraries.hs can load docs.json from the build folder instead of installed folder
Add touch to Setup.hs otherwise LoadLibraries.hs doesn't get recompiled. This is non-portable, but I can't find a portable way (see Setup.hs for details)
cabal clean && cabal install now works
(tested on ghc 7.4.1)
Move Build.hs (which builds elm-runtime.js) into a cabal build step (in compiler folder)
The elm exec and runtime should never get out of sync
Having a separate Build.hs file also causes problems when using cabal-dev
Moving elm-runtime.js into the dist/ folder also shows that it's generated (and cabal clean will remove it)
Similar for types.json (although whether this should be part of the build step, I don't know)
