I both like what you have to say about why writing OCaml code is so much more efficient than writing Elm code (and working with Elm in the last week agree completely with you) but also despair that it is true as to all of the warts in the Elm compiler
I think everyone hangs around this and other Elm discussion forums because we love the Elm concept of a simple functional language that promises to eliminate the need to deal with JavaScript; but unfortunately, due to the compiler shortcomings, that promise is not delivered other than for the most basic of programs. I'm glad to see that Evan resists adding everyone's favourite feature to the language and actually continues to reduce syntax to a bare core of functionality. Ideally, the Elm compiler would get completely re-written to both deal with the compilation speed issues (hopefully this work on "asset management" will handle that), but also to use the available static type information in the back end to generate much more efficient JS code as does BuckleScript (in most cases). This will be even a larger project as in order to get real JS code speed improvements for some cases, the memory model will have to be completely changed to something (or exactly) that of the BuckleScript back end. Come now, test tagged JS records as the primary data structure? So (as Even said) this is a big project as changes will have to be made to pass the type information to the code generator back end ***and*** completely re-write the back end to use that type information and while we are at it may as well change the JS code memory model to use JS Array's (no text tags) as the primary data structure as does BuckleScript. This may make the resulting JS code less debuggable, but that that isn't why we want to use Elm - we hope that all debugging can be done within the Elm environment. Unfortunately and realistically, there seems to be only one major contributor to the Elm compiler and build system - Even himself - and he is under increasing pressure to do more timely updates in a variety of areas, not only as to code efficiency. Also, the plan as proposed above requires changes in at least two major parts of the compiler: the AST code builder and the back end Code Generator, so either one person needs to do both or there will be co-ordination involved. This work would precede any other necessary work on further compiler optimization passes a la BuckleScript. As you say, the easiest thing to do would be just write an Elm2OCaml stand alone program which could then easily become the "pp" front end to produce an alternative Elm compiler to so much more efficient JS code through BuckleScript, with even more BuckleScript optimizations promised in the near future (or a native code alternative back end). Again as you say, it is very easy to write minimal JS interfaces in OCaml so that there then almost needs no Native code modules at all. Unfortunately, if we do that in as short a time as you say is possible, work on the Elm compiler will likely never catch up to that effort, and Elm, the language, will become nothing but a language specification for an alternate front end to OCaml just as ReasonML is. In a way, I'd be sorry to see that happen as Elm could be an independent language force in its own right. Once Elm's core Native libraries have been re-written into the OCaml environment, the ease of use of the resulting combination will likely mean that most serious users will choose that development environment, which then splits development efforts, which was the cause of (at least near) death or many other capable languages (D comes to mind). Perhaps this is the best alternative, as then Evan and other major contributors could concentrate on refining the language spec without the drain on their limited time to also work on the implementation of the language environment. If we want to prevent this, we need more contributors to Evan's work on compiler upgrades, if that is possible, rather than an Elm front end for OCaml. It seems to me that the old rule of not optimizing early doesn't apply to compilers, at least as to choice of memory model for the code generator and as to not thinking that type information is essential for efficient (and reliable) back end code. Having to rectify those omissions now is a lot of work! In fact, Fable is going through the same output code efficiency problems made worse because its goal is to support the full more-complex-then-Elm F# language specification: its back end memory model is very similar to that of Elm and the resulting code is up to about six or seven times slower than as produced by the same algorithms for BuckleScript - something as Elm output code is; Fable also seems slow to compile. One problem that both Fable and Elm must address is a consistent way to handle argument currying: Fable does this by applying use cases, where some types of functions are always curried (with an execution time overhead) and other types are not; Elm handles this by allways pseudo-currying in using hidden wrapper JS functions to apply wrapped functions to fixed numbers of arguments at a time as determined by the program context, but again at a const in performance (although perhaps less than Fables more direct multi-level currying). On Tuesday, 17 January 2017 23:27:36 UTC+7, OvermindDL1 wrote: > > On Saturday, January 14, 2017 at 3:13:40 PM UTC-7, GordonBGood wrote: >> >> I saw that over on elm-dev, but haven't tried it because compilation >> speed isn't a problem for the Elm code I have written so far. The only >> reason I brought it up is OvermindDL1's comment >> <https://groups.google.com/d/msg/elm-discuss/Um7WIBTq9xU/JpNNGv1JAgAJ> that >> compiling a Ocaml/BucketScript code (that presumably did the same thing as >> the Elm code) took about 0.1 seconds as compared to 40 seconds with the Elm >> compiler - a 400 times speed-up! We weren't given details of the code or >> test conditions and whether one was an incremental compilation, but that >> sounds quite serious and would affect the usability of Elm. If that data >> is verifiable, a speed up of double or even quadruple doesn't begin to >> touch the difference and should be investigated. >> > > It was a rewrite of a messaging system at work, it was in elm but we had > issues that necessitated the use of too many ports, the new one written in > OCaml (transpiled to javascript by Bucklescript) does the same thing in > about the same lines of code, except no javascript was used at all. The > lines of code is hovering around 6k for both versions, a compile for both > is done just by calling elm-make or bsb respectively and those are the > output times for a clean compile (no cache for either) with both spread > across about 31 source files. I'm not sure why the elm compilation is so > slow, the compilation is happening on Windows so that could be a factor. > And sadly no, cannot release work code without consent. ;-) > > A note though, the elm code was severely hampered by the type system in > Elm (lack of HKT's or HPT's) so had to get creative with use of records and > unions, so it is entirely possible we hit a very slow case, in the OCaml > code we used some GADT's and polymorphic modules so as to not resort to > those hacks. > > > On Saturday, January 14, 2017 at 9:14:55 PM UTC-7, Richard Feldman wrote: >> >> If only there were a binary posted somewhere, based on a compiler that >> had just been rewritten to improve build times, so that someone could post >> a benchmark instead of speculation! ;) > > > I might be able to test out the new compiler, still have the old elm code > in the repo (just that chunk is unused, we are still using other parts of > Elm that are not as large and not as full-of-ports) if really curious? > > > On Sunday, January 15, 2017 at 8:21:28 PM UTC-7, Richard Feldman wrote: >> >> you need recompile that module and regenerate a monolithic js file, the >>> larger project it gets , the worse compilation time you get in elm mode. If >>> you have experience in C++, you know the bottle neck used to be linking, it >>> is quite common for a c++ project to spend 20minutes in linking. >> >> >> Considering Evan is working on asset management for the next release, I >> doubt "compile everything to one file" will be true after it lands. (That >> release is presumably still several months away; this is just speculation >> on my part.) >> > > Ooo, now that would be awesome. :-) > > > On Tuesday, January 17, 2017 at 4:25:08 AM UTC-7, Rupert Smith wrote: >> >> Yes, that is what I thought. I probably missed some context out when >> quoting, but my question was in response to OvermindDL1's suggestion that >> moving to OCaml would open up the possibility of compiling to different >> back-ends other than javascript. >> >> An alternative might be to re-write the Native modules in the Elm core in >> OCaml. There isn't a huge amount of it. >> > > Precisely this, I've already done quite a large chunk of it as a test and > it translates very easily (and becomes type safe, which Elm's is not as > I've hit 'undefined's in pure elm code before (already in the bug tracker, > but why did they happen at all?!)). I kept it identical to the Elm API as > well, though if I broke Elm's API in a couple of minor ways then I could > *substantially* reduce the number of allocations done... But yes, I've > rewrote most of Elm's native Core code as well as some third-party > libraries like navigation, all without a touch of javascript and all of it > type safe the whole way, mostly playing around but we ended up using a lot > of it at work anyway (I still need to get around to cleaning it up and > releasing it...). An Elm->OCaml transpiler is entirely possible and I've > no doubt it would take substantially less than a year to do (if I could get > my work to pay for it I'd guess probably two weeks at most, though if > everything goes well I'd guess two days for the language conversion and the > rest on filling out the rest of the API that I've not yet done so as to > remove all javascript, which would make it compileable to native code as > well once system checks were added in, another chunk of time for that but > not much). > -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
