[elm-discuss] ANN: CollectionsNg 1.0.0: Stable collections with working equality

Just pushed CollectionsNg to package.elm-lang.org. CollectionsNg contain implementations of Array, Dict and Set written in pure Elm. The implementations are API compatible with their namesakes in elm-core, all you have to do to use them is to use different namespaces. These collections differ

[elm-discuss] Re: Web worker possibility? Perf concerns.

No, this won't work. 1. Webworkers cannot update the GUI, this has to be done on the UI "thread". 2. Webworkers do not share memory (not yet anyway). Which means you would need to copy the UI tree between worker and main loop. 3. Hundreds of thousands of nodes will be slow to copy between

[elm-discuss] Re: Web worker possibility? Perf concerns.

Or. It could of course be done. But neither React nor virtual-dom (which elm uses) works that way today. Chances are they won't support this any time soon either. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group

[elm-discuss] Re: How are deeply nested records updated or what alternatives are typically used?

As far as I know, this is how you must do at present. It's a recorded issue though (https://github.com/elm-lang/elm-compiler/issues/1375) so it will hopefully be fixed in a future release. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To

[elm-discuss] Should Color be a part of core?

I recently read the documentation for elm-lang/core, and was a bit puzzled to find a Color module in there. This in turn, made me come up with a series of questions. * Is Color a core concern? I would say no. In my projects (not only in Elm) I have yet to find need of a Color module (would

[elm-discuss] Re: Record update syntax

All I really want is: ```elm { model.something | more = 42 } ``` søndag 14. august 2016 02.49.07 UTC+2 skrev OvermindDL1 følgende: > > Just a passing idea to perhaps help give ideas for better methods: > > > Updating a nested record is a bit convoluted as something like: > ```elm > let >

[elm-discuss] Re: Which text editor do you prefer for Elm?

I use VSCode and I'm pretty happy with it onsdag 10. august 2016 12.47.34 UTC+2 skrev Rupert Smith følgende: > > I'm trying the Elm emacs mode, but it is pretty bad. If I select and > indent a whole file for example all the import statements and statements > within a let .. in get indented +1

[elm-discuss] Re: Should [ 1..5 ] exist?

I actually use ranges a whole lot, but it doesn't really matter much if I have special syntax or if I perform a function call. If there are advantages to removing the special syntax for ranges, then by all means do it :) -- You received this message because you are subscribed to the Google

[elm-discuss] Re: public keyword instead of exposing

..) type List = Cons | Nil expose sum : List Int -> Int sum = List.foldl (+) ``` mandag 8. august 2016 18.00.18 UTC+2 skrev Rex van der Spuy følgende: > > > > On Monday, August 8, 2016 at 3:44:30 AM UTC-4, Robin Heggelund Hansen > wrote: >> >> There's one thing that

[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

[elm-discuss] public keyword instead of exposing

There's one thing that has always bothered me with Haskell, and now also Elm, and that is how functions are exposed. My problem with the way it currently works is that you have go to the top of the file to see/alter if a function is exposed to the "outside world". In Clojure and F#, it is

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I don't understand this. Elm currently has better code output than Babel and Typescript. Choosing Elm over those gives me faster applications (though, I've never needed more speed) as well as smaller bundles. An application written with React+Immutable+Moment, will have much more code than an

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

> Actually tree shaking will do absolutely nothing for Elm code as Elm > compiles everything into a single module that all highly indirectly > references itself. It would help with bucklescript as it outputs modules, > but bucklescript already tree-shakes as part of its compiler

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

vanced optimizations that uglify does > not even come close . If you feed bad code to it , of course it won't help > too much. There are limitations to closure and its limitations are > documented unclearly, so you have to be very careful > On Wed, Jan 25, 2017 at 8:09 PM Robin Hegge

Re: [elm-discuss] Super-unimportant request for Google Closure Compiler.js compatibility

Advanced opts won't work with Elm. Check https://github.com/elm-lang/core/pull/734 Also, I'm surprised that uglify gives so bad results. As you can see in the PR, my results didn't show that big a difference. torsdag 26. januar 2017 12.53.31 UTC+1 skrev Ahmed Fasih følgende: > > On Thursday,

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

;> why >>>> it is easy to fool if you use a non-static string for the name). I've not >>>> seen any tree shaking yet that does otherwise. Although the fascinating >>>> rollup.js does a lot better by pruning functions very effectively, I need >>>>

[elm-discuss] Re: Dead code elimination and the future of elm-runtime.js

First of all, I agree with all your main points. The size and scope of the runtime should not be dictated by the number of bytes it takes up. Also, the compiler does have more flexibility if it was all in JS. However. As long as the target language is JS, I don't think DCE should be a

[elm-discuss] Re: Convincing my team that Elm isn't just going to die like CoffeeScript

I'd say that Elm is such an easy thing to learn that I wouldn't worry about hiring Elm devs. If people know React and Redux then they already know the principle of how Elm works, and so learning syntax and how functional programming works is quite easy. I also think No Red Ink hires people new

[elm-discuss] Proposal: rename foldl til foldLeft and foldr to foldRight

In Elm 0.18, primes are being removed as valid characters in a variable/function name. The reason being, which I whole heartedly agree with, that removing primes will incentivize people to write proper names, and also because the difference between model and model' isn't always easy to spot.

Re: [elm-discuss] Proposal: rename foldl til foldLeft and foldr to foldRight

fold and foldRight then? tirsdag 25. oktober 2016 11.42.00 UTC+2 skrev Wouter In t Velt følgende: > > Op dinsdag 25 oktober 2016 02:20:29 UTC+2 schreef Max Goldstein: >> >> Changing things makes upgrading harder, invalidates old code, and gives >> the larger community the impression that Elm is

Re: [elm-discuss] Proposal: rename foldl til foldLeft and foldr to foldRight

I did a lot of work in ember myself, and I feel your pain, but this is still a 0.x product, and so it should be expected that some breakage is performed while we reach the best possible state of the language. It's different for Ember, which had a lot of breakage post 1.0. tirsdag 25. oktober

Re: [elm-discuss] Proposal: rename foldl til foldLeft and foldr to foldRight

Once, that I remember, after a refactoring. But this is more to do with the ease of reading code. I've several times seen foldr and read foldl. In general, I find names that differ by only a single letter a bad thing. Like wether and whether. Sure, now that i've pointed out that there is a

[elm-discuss] Re: Proposal: rename foldl til foldLeft and foldr to foldRight

Please stay on topic. This thread is strictly about the naming of foldl and foldr, nothing else. torsdag 20. oktober 2016 19.24.47 UTC+2 skrev Ambrose Laing følgende: > > One could define fold as a generic operation that replaces the empty list > with a constant (for example an identity

[elm-discuss] Proposal: Add Debug.breakpoint to core

While I spend a lot less time debugging in Elm than in JS, sometimes it's useful to debug the generated Javascript. This would be greatly simplified, if it was possible to add a `debugger;` statement to the code. What do people think of a new function added to the Debug module of

[elm-discuss] Re: Proposal: rename foldl til foldLeft and foldr to foldRight

foldRight. This goes for both new and existing Elm developers. mandag 24. oktober 2016 13.12.53 UTC+2 skrev Rupert Smith følgende: > > On Thursday, October 20, 2016 at 3:12:57 PM UTC+1, Robin Heggelund Hansen > wrote: >> >> In Elm 0.18, primes are being removed as val

Re: [elm-discuss] Proposal: Add Debug.breakpoint to core

an you sketch out > your use case a bit more? > > On Sat, 22 Oct 2016 at 11:19 Robin Heggelund Hansen <skinn...@gmail.com > > wrote: > >> While I spend a lot less time debugging in Elm than in JS, sometimes it's >> useful to debug the generated Javascript.

Re: [elm-discuss] Proposal: Add Debug.breakpoint to core

, not a necessity. mandag 24. oktober 2016 19.34.53 UTC+2 skrev Nick H følgende: > > Don't forget, the time-travelling debug mode is coming in 0.18. Do you > think setting breakpoints like this is still going to be useful? > > On Mon, Oct 24, 2016 at 5:59 AM, Robin Heggelund H

[elm-discuss] Re: Demo project that fails Google Closure Advanced Optimizations

, 2016 at 11:16:16 AM UTC-6, Robin Heggelund Hansen > wrote: >> >> I was wondering if anyone had a project that fails to run properly when >> applied with the Advanced Optimizations of the Google Closure Compiler? >> I want to figure out what the problems are so that I can su

[elm-discuss] New implementation of elm arrays available on elm-package

Version 1.0.0 of the new elm array implementation is now available on elm-package. If you have elm 0.18 you can easily try it out by doing the following: 1) install the package with `elm package install Skinney/elm-array-exploration` 2) Use the correct namespace, `import Array.Hamt as Array`

[elm-discuss] Re: Structure for multiple small "apps" when using Elm with webpack (elm-webpack-loader)

I would just keep everything in one Elm app, then use a router to display the correct page. When it comes to google closure, Elm only works with SimpleOptimizations. There are two-three lines in the runtime which causes problems with AdvancedOptimizations. In any case, the difference between

Re: [elm-discuss] What is the motivation for using google groups?

Fine by me. I check Reddit as often as I check this mailing list :) lørdag 26. november 2016 03.34.07 UTC+1 skrev Richard Feldman følgende: > > We've talked in the past about moving to https://reddit.com/r/elm - in > part for threaded discussions and voting, but also more to have things more >

Re: [elm-discuss] Rename Just to Something, as the counterpart to Nothing?

hing >>>>> >>>>> > intuitive, some don't. >>>>> > >>>>> > Given that the choices is (mostly) arbitrary, it seems best to stick >>>>> with >>>>> > the status quo. >>>>> >

[elm-discuss] Re: Structure for multiple small "apps" when using Elm with webpack (elm-webpack-loader)

Define "big blob of js" React, the framework alone, is around 54kb gzipped, my elm SPA is currently half that gzipped. Also, you would load the same blob once, as it's cached in your browser. Currently, if you split your app up into multiple entry points, those would still require the Elm

[elm-discuss] Help me test the new array implementation

A couple of weeks ago, I released a new array implementation for Elm on elm-package. Why do we need a new implementation? Well, the implementation we've got in core isn't always immutable, and sometimes it crashes at runtime (see the list of bugs here:

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

I seem to remember that the discussion to keep or remove range syntax was done here on the mailing list, and a lot of people had no hard feelings about it going away. This was very much a community decision. tirsdag 15. november 2016 16.19.54 UTC+1 skrev Andrew Radford følgende: > > I don't

[elm-discuss] Re: Why Range syntax got removed in favor of List.range

I remember Evan said that range syntax was one of the things he was asked most about from new coders. Not only "what's this?" but also "how do I make a range, I couldn't find anything in the documentation." Then one comes to realize that there are other problems with range syntax. In addition

[elm-discuss] Re: Parallelism support in Elm

What would you use it for? søndag 13. november 2016 00.53.05 UTC+1 skrev أحمد حبنكة følgende: > > according to this > > question, > Elm doesn't support parallelism yet. > > > I know that right now the idiomatic way in

[elm-discuss] Re: Why Range syntax got removed in favor of List.range

Fixing the docs could of course be done, and you're right, it's not something that's hard to understand. However, the question you should be asking is "is there any reason why range isn't a function to begin with?" søndag 13. november 2016 16.58.32 UTC+1 skrev أحمد حبنكة følgende: > > > >

[elm-discuss] Re: Open discussion about optimization of code potentially triggered very often (mousemove) ?

It's specific to the virtual dom. Events are triggered as normal, but the code that renders the view is only called with the latest state once per frame. lørdag 19. november 2016 15.51.56 UTC+1 skrev Matthieu Pizenberg følgende: > > Hi everyone, > > I am currently developing some functionality

[elm-discuss] Re: Proposal: Shorter qualified imports

Note. The `as` keyword would still be necessary for brevity is desired, and for when two modules are imported where the last part of the name is the same. søndag 20. november 2016 07.50.42 UTC+1 skrev Robin Heggelund Hansen følgende: > > I mostly try to use qualified imports i

[elm-discuss] Proposal: Shorter qualified imports

I mostly try to use qualified imports instead of exposing variables into my namespace. This leads me to using the `as` keyword often, like this: ``` import Module.B as B import Module.C as C {- etc. -} ``` In Go, accessing a namespace through the last part of it's name, is implicit. If that

[elm-discuss] Proposal: import groups

I've done some Go programming lately, and have been inspired by the way imports are handled. This is one of two proposals to make minor modifications to how imports are handled in Elm today. Imports are always written at the top of a file, after the package declaration, and after the docstring

[elm-discuss] Re: Rename Just to Something, as the counterpart to Nothing?

How about 'Some' and 'None'? Those are not longer to type than what we have today, and they should solve your initial confusion. søndag 20. november 2016 18.16.26 UTC+1 skrev Will White følgende: > > I'm talking about Maybe.Just, of course. Just has always seemed strange to > me, as if it's

[elm-discuss] Re: Proposal: import groups

My proposal, Josh's proposal, or both? mandag 21. november 2016 00.51.36 UTC+1 skrev Daniel Walker følgende: > > This seems a lot less readable than what we currently have to me. > > On Saturday, November 19, 2016 at 11:38:16 PM UTC-7, Robin Heggelund > Hansen wrote: >>

[elm-discuss] Re: Proposal: import groups

oday IMHO. > > On Sunday, November 20, 2016 at 5:25:29 PM UTC-7, Robin Heggelund Hansen > wrote: >> >> My proposal, Josh's proposal, or both? >> >> mandag 21. november 2016 00.51.36 UTC+1 skrev Daniel Walker følgende: >>> >>> This seems a lot less rea

[elm-discuss] Re: This week, we hit 5000+ users on Slack

This is awesome! Way to go, team :D mandag 17. oktober 2016 01.33.47 UTC+2 skrev Noah Hall følgende: > > From our Slack weekly update: > > > In total there are 5190 people on your team (up 210 from last week) > (that's not including 11 disabled accounts). > > I think that's pretty cool. Lots of

[elm-discuss] New array implementation has reached version 2.0.0

The new implementation of arrays in Elm has reached version 2.0.0 and is available on elm-package (http://package.elm-lang.org/packages/Skinney/elm-array-exploration/latest) This could end up being merged into core at some point in the future. Please try this implementation in your own code.

[elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I'm not saying that performance of tight loops aren't important, what I'm questioning is how much comparison and equality operators affect them. I would assume that higher-order functions and immutability has a much bigger impact on tight loops in games, graphics and intensive math

[elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Part I: Evan is already aware of this issue, you can see the full discussion in this github issue: https://github.com/elm-lang/elm-compiler/issues/1528 The short of it is that the code generator part of the compiler is not aware of type information, and adding this would be a serious

[elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

; On Tuesday, 27 December 2016 05:37:43 UTC+7, Robin Heggelund Hansen wrote: >> >> Part I: Evan is already aware of this issue, you can see the full >> discussion in this github issue: >> https://github.com/elm-lang/elm-compiler/issues/1528 >> The short of it is th

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

The barriers are already built, the recent discussion mostly revolves on how we talk about the current barriers to make things more clear for beginners. Nothing is going to prevent you from using native/kernel code in your own project. You just won't be able to share it on elm-packages (which

[elm-discuss] Re: Would Enums make a good addition to Elm?

Regarding (2), I was not aware of this. Cool =) Having a deriving-esque way to generate encoders and decoders automagically would be great, and would go a long way in solving the hassle. (2) would also make my life easier. The problem I see with both deriving-esque auto coders (DEAC, patent

[elm-discuss] Re: Systemic problem in Object Oriented languages

First of all, let's agree that both Java and Javascript are successful languages in that you can solve most, if not any, given software problems in those languages. Does that mean the languages themselves are unproblematic? What does it mean to have a problem? Does it mean you cannot get

[elm-discuss] Would Enums make a good addition to Elm?

I think most people find that Union Types are a wonderfull thing. I would argue that much of the beauty of Union Types comes from using them in a case-of statement, having the compiler complain when there is a case one haven't covered. Strings and numbers are not so wonderfull, because they

[elm-discuss] Re: The way forward for Elm Arrays

Folks, please stay on topic. If you want to have a discussion regarding special syntax for the different collection types, please start a new thread. mandag 12. juni 2017 23.52.25 UTC+2 skrev Robert Woodhead følgende: > > Maybe I'm missing something, but wouldn't this be a situation where a >

[elm-discuss] Re: The way forward for Elm Arrays

4, 8, etc. so it is faster >> to >>hop around and you get better locality. Do you recall what this was >> called >>Richard? >> >> I also think that manually recursing through lists with a case is >> relativel

[elm-discuss] The way forward for Elm Arrays

I've been doing some thinking on how to improve Arrays in Elm. The result of that thinking have been written down in this document: https://docs.google.com/document/d/1Z8IC5qk98ISQLP_xKXNOHScCfzkQ8jCVSiYd1SxObB4/edit?usp=sharing The document is quite large, but most of it are benchmark results

[elm-discuss] Re: Tour of an open-source 4,000 LoC Elm SPA

This is great Richard! I've already shown it to several people who've asked me how I structure my Elm apps :) mandag 8. mai 2017 09.59.16 UTC+2 skrev Richard Feldman følgende: > > I get asked if there are any sizeable open-source Elm SPA examples out > there...so I made one! > > Hope it's

[elm-discuss] Re: Elm with one message

; > On Thursday, August 24, 2017 at 11:31:20 AM UTC+3, Robin Heggelund Hansen > wrote: >> >> Won't this break the reactor/debugger? You can't really tell what sort of >> messages is being passed around in your application with this model, if you >> want to export mes

[elm-discuss] Re: Elm with one message

Won't this break the reactor/debugger? You can't really tell what sort of messages is being passed around in your application with this model, if you want to export message history, it would fail as well I believe. I think a better way would be to not have nested components. Keep your entire

Re: [elm-discuss] Re: Array map with start and end

Using native code in Elm isn't particularly hard (though, you cannot publish such code as an elm package). My original, and still working, array implementation uses native code (it's a "blessed" library). It's better to use that as a template for any experimentation you might want to do:

[elm-discuss] Re: Array map with start and end

Slicing isn't O(N). In the current implementation in core, slicing is O(log32n) i believe. In the next version of Elm, slicing is O(log32n) when start = 0; I'm uncertain what the big-o notation is once start > 0 though. fredag 17. november 2017 09.25.22 UTC+1 skrev Francisco Ramos følgende: >

Re: [elm-discuss] Re: Array map with start and end

Something like https://github.com/Skinney/core/blob/master/src/Elm/JsArray.elm ? It's what is used as the basis for Arrays in 0.19. It is not planned to be opened for use outside of elm-lang/core, but if it fits your usecase better, I'm sure Evan would be interested in hearing about it.

Re: [elm-discuss] Re: Array map with start and end

mportant. > That's why I'm asking. > > Thanks guys > > On Fri, Nov 17, 2017 at 1:20 PM Robin Heggelund Hansen <skinn...@gmail.com > > wrote: > >> Slicing isn't O(N). >> >> In the current implementation in core, slicing is O(log32n) i believe. In &

[elm-discuss] New and faster Dict implementation

tl;dr; * new api compatible Dict implementation: http://package.elm-lang.org/packages/Skinney/elm-dict-exploration/latest * Is a Left-Leaning Red-Black tree. * For Chrome: 8% faster reads, 171% faster inserts, 30% faster removals and 15-25% slower updates. (similar results in other browsers) *