Translation to JS fails

[tobi512]

Hi Atze,
after successfully installing UHC (thanks again for #62), I tried to translate a mid-complex program to JavaScript and ran into multiple error that fail the process.

A simple HelloWorld can be translated without problems and produces very little JavaScript code, which makes UHC very interesting for me. I translated HelloWorld with GHCJS and Fay, both give you an extreme overhead of code...

Error log:
uhc -tjs Ambiguity.hs ParseRE.hs [1/2] Compiling Haskell Ambiguity (Ambiguity.hs) Parse (Haskell syntax) of module 'Ambiguity' *** ERROR *** Ambiguity.hs(1,1): Expecting : CloseBrace or pImportDeclaration or pTopDeclaration or (Symbol symbol ; or Nothing expected ...)* Repaired by: deleting: Symbol symbol {-# at line 1, column 1 of file "Ambiguity.hs" *** ERROR *** Ambiguity.hs(1,20): Expecting : Symbol symbol :: or pPatternConSuffix or pRhs or qconop or varop_no_bang or (pPatternBaseCon ...)* Repaired by: deleting: Symbol symbol #-} at line 1, column 20 of file "Ambiguity.hs" *** ERROR *** Ambiguity.hs(3,1): Expecting : Symbol symbol :: or pRhs or varop_no_bang Repaired by: deleting: SemiColon *** ERROR *** Ambiguity.hs(3,1): Expecting : Symbol symbol :: or pRhs or varop_no_bang Repaired by: deleting: Symbol symbol import at line 3, column 1 of file "Ambiguity.hs" *** ERROR *** Ambiguity.hs(3,8): Expecting : Symbol symbol :: or pRhs or varop_no_bang Repaired by: deleting: Symbol upper case qualified identifier System.Environment at line 3, column 8 of file "Ambiguity.hs" ... and more errors

The first few lines of the file Ambiguity.hs look like this:
{-# LANGUAGE GADTs #-} import System.Environment import Data.List import Data.Maybe import ParseRE

I can send you the 2 files if you want to have a closer look.

System.Environment is used to call getArgs when running the program from the command line, could be changes if this import is a problem.
GADTs are frequently used, is that supported in UHC?!

Many thanks in advance, nice project and great support in here! 😃

Sincerely,
Tobias

[atzedijkstra]

Tobias,

regretfully GADTs are not (yet) implemented, actually work is underway to rewrite the type system (which would then include GADTs) but this is far from finished. UHC supports almost all of Haskell2010, some additional stuff, but the wide range of extensions GHC offers, so making existing libraries work usually means you have to put some work in getting rid of the part using such extensions, if at all possible of course.

It seems that the parsing errors are caused by the absence of a module header. The haskell report (and GHC docs) itself specifies that file header pragmas should be before the module keyword, but state not what happens if that keyword is absent (https://downloads.haskell.org/~ghc/7.2.2/docs/html/users_guide/pragmas.html https://downloads.haskell.org/~ghc/7.2.2/docs/html/users_guide/pragmas.html, https://www.haskell.org/definition/haskell2010.pdf https://www.haskell.org/definition/haskell2010.pdf pg 152). Apparently GHC is more relaxed in this than UHC :-).

As for the size of resulting code, you might also consider using the option -Operwholecore which links all modules in an early compile phase into a whole program, compilation takes a bit longer but overall size shrinks as only the part is drawn in which is actually used.

Currently the JS backend is not worked on (because of the abovementioned work), and also because alternatives like GHCJS exist for which much more active maintenance and development work is going on. However, if you stumble upon problems with the UHC JS backend, let me know, some of them might be easily fixable.

cheers,
Atze

On 8 Dec, 2015, at 16:46 , Tobias Fuss [email protected] wrote:

Hi Atze,
after successfully installing UHC (thanks again for #62 #62), I tried to translate a mid-complex program to JavaScript and ran into multiple error that fail the process.

A simple HelloWorld can be translated without problems and produces very little JavaScript code, which makes UHC very interesting for me. I translated HelloWorld with GHCJS and Fay, both give you an extreme overhead of code...

Error log:
uhc -tjs Ambiguity.hs ParseRE.hs
[1/2] Compiling Haskell Ambiguity (Ambiguity.hs)
Parse (Haskell syntax) of module 'Ambiguity'
*** ERROR ***
Ambiguity.hs(1,1):
Expecting : CloseBrace or pImportDeclaration or pTopDeclaration or (Symbol symbol ; or Nothing expected ...)*
Repaired by: deleting: Symbol symbol {-# at line 1, column 1 of file "Ambiguity.hs"
*** ERROR ***
Ambiguity.hs(1,20):
Expecting : Symbol symbol :: or pPatternConSuffix or pRhs or qconop or varop_no_bang or (pPatternBaseCon ...)*
Repaired by: deleting: Symbol symbol #-} at line 1, column 20 of file "Ambiguity.hs"
*** ERROR ***
Ambiguity.hs(3,1):
Expecting : Symbol symbol :: or pRhs or varop_no_bang
Repaired by: deleting: SemiColon
*** ERROR ***
Ambiguity.hs(3,1):
Expecting : Symbol symbol :: or pRhs or varop_no_bang
Repaired by: deleting: Symbol symbol import at line 3, column 1 of file "Ambiguity.hs"
*** ERROR ***
Ambiguity.hs(3,8):
Expecting : Symbol symbol :: or pRhs or varop_no_bang
Repaired by: deleting: Symbol upper case qualified identifier System.Environment at line 3, column 8 of file "Ambiguity.hs"
... and more errors

The first few lines of the file Ambiguity.hs look like this:
{-# LANGUAGE GADTs #-}
import System.Environment
import Data.List
import Data.Maybe
import ParseRE

I can send you the 2 files if you want to have a closer look.

System.Environment is used to call getArgs when running the program from the command line, could be changes if this import is a problem.
GADTs are frequently used, is that supported in UHC?!

Many thanks in advance, nice project and great support in here!

Sincerely,
Tobias

—
Reply to this email directly or view it on GitHub #66.

[tobi512]

Hi Atze,
thanks a lot, we removed the GADTs and were able to compile successfully. 😃

However we're now one step further and try to make use of the resulting JavaScript-program which brings a couple new problems up. Would be great if you could shortly tell us your opinion on them:

In general we struggle with data in- and output. We have a simple program with one Haskell-function we'd like to use via browser (input: string output: maybe [string]) and therefore translated to JS. For output we wanted to use a simple alert, but we couldn't make your demo (https://utrechthaskellcompiler.wordpress.com/2012/09/13/compiling-haskell-to-compact-javascript-programs/) work. Everything compiles fine but we get no alert after opening the HTML-file...

For input we're not sure what to use, maybe simple textfield and button that triggers the function with the textfield-value? We tried this via jQuery and UHC-JS main = do button <- jQuery "input#test" let handler = alert "Test clicked!" bind button Click handler but there seems to be a syntax problem with the bind-function...

In Language.UHC.JS.JQuery.JQuery.bind button Language.UHC.JS.JQuery.JQuery.Click handler': ... Inhandler':
Main.hs:9:27:
Type clash:
failed to fit: UHC.Base.IO ()
<= Language.UHC.JS.JQuery.JQuery.EventHandler
problem with : UHC.Base.IO <= -> Language.UHC.JS.JQuery.JQuery.JQuery

Any other idea on how to do the import/export on this simple program? 😄

Something like JCU (http://uu-computerscience.github.io/JCU/) would perfectly do the job for us, but it's not obvious how JCU was created and is linked with jQuery etc., do you have any further knowledge on this? Would help us a lot...

Thanks in advance!
Tobias

[tobi512]

@atzedijkstra Any advice? Would really help us to finish our project successfully

[atzedijkstra]

Hi Tobias,

The jQuery code you mention has been made (as part of the uhc-js library) by two students (Alessandro, Jurrien) who I have CC-ed. Both have gone off doing other things now, but it might be that they have a quick answer for you. Further, I have looked at the uhc-js repo, it seems it is not updated w.r.t. changed commandline flags and slightly different FFI syntax. I have patched and tried this for the simplest alert example, which works now after the mods I have pushed to the repo. I'll look into it later and discuss with Alessandro and Jurrien what needs to be further fixed.

all the best,
Atze

On 21 Jan, 2016, at 19:42 , Tobias Fuss [email protected] wrote:

@atzedijkstra https://github.com/atzedijkstra Any advice? Would really help us to finish our project successfully

—
Reply to this email directly or view it on GitHub #66 (comment).

[atzedijkstra]

Hi all,

Atze is the one to talk to wrt. the changes in the FFI syntax, but I'll try to answer questions about the JCU app as best I can.

The JCU app is built on top of (a now old version of) Snap Framework [1]. It uses BlazeHTML [2] in order to generate the application's HTML. The JCU.Templates module [3] shows how this is done. In particular, the header function imports "hjs/jcu.js". This jcu.js file needs to be generated from the JCU module [4] using the UHC's JS backend. The rest of the application needs to be compiled with cabal and GHC. There's a "JCU.cabal" [5] file for that.

Since the code is now almost 3 years old, this all might not work out of the box anymore, so you might need to patch it here and there. Pull requests are welcome, of course ;)

Hopefully this helps. Let me know if you have more questions.

Gr, Jurriën

[1] http://snapframework.com/
[2] https://hackage.haskell.org/package/blaze-html
[3] https://github.com/UU-ComputerScience/JCU/blob/master/src/JCU/Templates.hs
[4] https://github.com/UU-ComputerScience/JCU/blob/master/resources/static/hjs/jcu.hs
[5] https://github.com/UU-ComputerScience/JCU/blob/master/JCU.cabal

On 22 Jan 2016, at 09:02, Atze Dijkstra [email protected] wrote:

Hi Tobias,

The jQuery code you mention has been made (as part of the uhc-js library) by two students (Alessandro, Jurrien) who I have CC-ed. Both have gone off doing other things now, but it might be that they have a quick answer for you. Further, I have looked at the uhc-js repo, it seems it is not updated w.r.t. changed commandline flags and slightly different FFI syntax. I have patched and tried this for the simplest alert example, which works now after the mods I have pushed to the repo. I'll look into it later and discuss with Alessandro and Jurrien what needs to be further fixed.

all the best,
Atze

On 21 Jan, 2016, at 19:42 , Tobias Fuss [email protected] wrote:

@atzedijkstra Any advice? Would really help us to finish our project successfully

—
Reply to this email directly or view it on GitHub.

[tobi512]

Hi Atze and Jurriën,
thanks for your detailed answer and patches regarding the alert-dialog. It really helps us a lot with our university project, since only a working webapp-prototype is missing! 👍 We'll give it a try soon and tell you how it goes...

Regards,
Tobias