[elm-discuss] Re: Elm Generated Files are Quite Large

Yes, I know. I was just commenting on the fact that the two are often(not always) intertwined. If you are careful in the way you go about it you can implement dead code elimination in such a way that you also get dead code identification almost for free. On Monday, August 8, 2016 at 8:59:22 PM

[elm-discuss] Re: Elm Generated Files are Quite Large

Let me be clear that dead code identification can be useful for code within the module you are writing. Dead code elimination means using one function in the String module doesn't include the source for all string functions in the compiled code. -- You received this message because you are su

[elm-discuss] Re: Elm Generated Files are Quite Large

Dead code elimination also implies dead code identification which can help in adding compiler warnings for dead code. This is of course a completely seperate discussion, but dead code identification can be immensely useful as a compiler feature. On Monday, August 8, 2016 at 9:52:44 PM UTC-7, Ro

[elm-discuss] Re: Elm Generated Files are Quite Large

Dead code removal aka tree shaking would be done with knowledge of Elm's type system and call graph. This is knowledge that uglify and similar programs don't have access to. That's why people are hoping it will make a difference, although there's no definitive evidence yet because the feature h

[elm-discuss] Re: Elm Generated Files are Quite Large

I know I've told this to you earlier. But the Elm compiler generates code in such a way that makes it VERY easy for Uglify to remove most (if not all) unused code (especially libraries). I'm working on an Elm app right now which has a bunch of libraries, and the size of the app is way smaller t

[elm-discuss] Re: Elm Generated Files are Quite Large

Yep! Preliminary work for dead code elimination has been done for awhile , but finishing it has never been justifiable as the next priority. I honestly doubt it'll be worth prioritizing in the next few months either...the t