On Saturday, 14 January 2017 00:38:03 UTC+7, OvermindDL1 wrote: > > But yes, translating Elm to OCaml/Bucklescript would not at all be a hard > task. :-) >
An Elm front-end to OCaml sounds interesting and I especially like the sound of "faster compilation speed" (about 400 times faster???). However, although I can write some OCaml code, I am not equipped to help on this project because I don't have your (and Hongbo's) knowledge about the inner workings of the OCaml compiler. That said, I think that there is one area of optimization where such a front-end will have problems just as BuckleScript does now: Elm's data structures are all guaranteed immutable where Ocaml/BuckleScript's are not - this means that BuckleScript needs to create closures around any captured free variables unless it does special processing to ensure that these to not mutate within the scope of use of the closure, which could be wide; Elm's data structures are guaranteed immutable and any immutability introduced will be local in scope as just for such things such as tail call optimization in turning tail calls into loops with mutable loop variables taking the place of what would normally be function arguments. My idea was just to either re-write or make improvements to the Elm back end of the current Elm compiler, which I can handle as I have enough Haskell, but although I might be able to make the resulting output JavaScript satisfactory as to run speed, this would not likely help with speed of compilation, which I assume is the result of slow steps leading from parsing to producing the AST (???). From a quick look at the code, there seem to be several passes but only one that does basic optimization before the AST is generated. Some optimizations such as inlining and the limited tail call optimizations it does are part of the back end. I suppose this general structure is common to most compilers just as for OCaml other than the number of optimization passes and other than that Elm does not have a pass plug-in capability. I'm wondering why the Elm compiler is so slow at parsing if that is where the slow-down is: There is no basic reason that Haskell code output needs to be any slower than OCaml code output; the usual reason for such a dramatic slow-down is often that the author(s) haven't paid careful enough attention to non-strict processing and have let it get away on them, which is usually seen by huge heap memory use and garbage collection taking a huge portion of the execution time. These sorts of problems can often be fixed by forcing/hinting strictness at key junctures in the code. This should be investigated, as some simple changes could make all the difference. If this could be done simply, writing an Elm pre-parser for OCaml may be overkill, although it would have the advantages of a more optimized back-end (BuckleScript) already in the works. I guess what I am saying is that I am not quite ready to give up on the current Elm compiler, and if no one else has the time to investigate this front end slowness, it seems I may have to look into it myself. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
