On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote: > > 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. >
Entirely yeah, TEA is a fantastic architecture . On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote: > 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. > One of Elm's big things is 'never needing to debug the javascript' though, so I could see it doing that. On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote: > 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. > That is why I think having Elm compile to another target would save Evan a tremendous amount of work. A translation layer is quite a lot easier than a full compiler (especially the more similar the semantics already are, like Elm and OCaml very much are). He'd be free to design the language much more easily. OCaml already has fantastic error reports, although not 'quite' up to Elm's standards (but pretty close in many ways), and adding better error messages to the OCaml compiler would benefit a lot more people outside of Elm as well (plus the OCaml compiler is oddly fun to hack on, it is really well designed). On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote: > 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. > Bucklescript can already compile to OCaml. Bucklescript adds some extensions (the OCaml language is extendable via ppx's as well) to do things like platform testing, so you can make code that compiles for the web do something else when on native (like output html or no-op for event registrations), and that ppx can be added to a normal OCaml compiler via the normal `-ppx` flag to add those extensions to a native compile as well, so you get free platform detection to write platform-specific code. On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote: > 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). > Yeah that is why I definitely agree that Elm should make OCaml a first-class back-end, that way compilation via bucklescript to javascript or ocamlc to native code is both easy, with all the optimizations afforded by the OCaml compiler on both. On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote: > 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. > This is also why I've not started such a project, I do not want it to distract from Elm. The most I'll do (and am using) is my own OCaml TEA-like library for now. On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote: > 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). > Bucklescript de-curries as much as possible, however you can also force it in the type system explicitly by adding the annotation type of `[@bs]` to a function (type) definition, that enforces uncurrying at the type level and will even propagate in usage as expected to make sure accidental currying of it is not done (though you can still explicitly curry it by wrapping it in a curried type). In most cases it de-curries very well and you never need to use `[@bs]` (the only real time I've used it is on DOM callback registrations with more than one argument to make sure I do not accidentally pass a curried version to one, never used it in 'user' code as of yet). -- 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.
