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

[Robin Heggelund Hansen]

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: https://github.com/Skinney/elm-array-exploration

torsdag 23. november 2017 11.48.46 UTC+1 skrev Matthieu Pizenberg følgende:
>
> Do you need to rebuild the compiler for this?
>>
>
> I'm not familiar with so called "native" elm 0.18 code. So I wanted to use 
> the example given by Robin with `Elm/JsArray.elm` and 
> `Elm/Kernel/JsArray.js` from elm master branch to try the same thing with 
> `JsArrayBuffer.[elm/js]`. Since this is code in the master branch only, 
> which is 0.19 syntax (`elm.json`, "kernel" js code, ...), I cannot compile 
> it with elm-make from 0.18 branch.
>
> But it's ok, this need no rush, will try when I have a little more time.
>

-- 
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.

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

[Robin Heggelund Hansen]

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.

(JsArray is a thin wrapper over javascript arrays. Any operation that 
modifies the underlying structure causes a complete copy, but get and folds 
are very fast. Slicing when start === 0 is still going to be faster using 
Elm Arrays as it is a tree structure. On the other hand, it should be 
fairly easy to create a "view" instead of slicing, but that might give you 
problems with space leaks.)

tirsdag 21. november 2017 11.24.09 UTC+1 skrev Rupert Smith følgende:
>
> On Monday, November 20, 2017 at 5:29:25 PM UTC, Francisco Ramos wrote:
>>
>> Ultimately, I'd like to rewrite NumElm using the elm-ndarray. Not sure 
>> how I'm gonna do this without writing kernel code. Linear algebra 
>> operations such as Inverse, Pseudo-inverse, Singular value 
>> decomposition, Eigenvalues and eigenvectors, etc... I simply have no idea 
>> how I'm gonna implement this. Need to have a look at solutions in 
>> Haskell for inspiration.
>>
>
> I suspect you are up against a tough impedance mismatch between immutable 
> arrays for functional languages, and fast flat arrays for pure number 
> crunching.
>
> The tree structured arrays for functional languages are designed to allow 
> a new version to be created from an existing array, without copying the 
> entire array. Well, a balance between copying the least amount whilst 
> keeping the tree fairly shallow for fast access.
>
> Arrays of floats for number crunching ideally just want to be stored flat 
> in RAM, so you can point an optimized for-loop at them or your GPU.
>
> You could also look at Java nio.Buffer for some inspiration? These allow 
> off-heap 'direct' buffers to be created, but have an interface on the Java 
> language side to manipulate them. You can for example take a 'slice' of 
> such a buffer, and it give you a so-called flyweight object as the result, 
> that is, a start offset and length into the original buffer, but sharing 
> the same data. 'slice' therefore is a very efficient operation.
>
> This scheme won't translate into immutable functional data structures 
> without modification. For example, to modify such a buffer in an immutable 
> way, would mean copying the entire thing. I just mention it as a possible 
> source of inspiration to help you think about your design.
>
> Perhaps this is already what you have in mind for ndarray? A structure 
> that is more efficient for your use case, but that is wrapped in an 
> immutable functional API to make it play nicely with the host language.
>

-- 
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.

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

[Robin Heggelund Hansen]

It using Array.prototype.slice under the hood, but the way Arrays in Elm is 
implemented is by using trees. I suggest you watch my talk from Elm Europe, 
where I explain how the different data structures work in detail =)

https://www.youtube.com/watch?v=mmiNobpx7eI

fredag 17. november 2017 13.34.08 UTC+1 skrev Francisco Ramos følgende:
>
> That was a good observation, Rupert. Well, it doesn't return Nothing if 
> the indexes are out of the bounds, but if start < 0 then start = 0, and end 
> >= length then end = length -1... I could actually use Array.get and 
> implement my own map like you mention.
>
> Thanks Robin for that correction. I thought Array.slice is using under the 
> hood Array.prototype.slice, which as far as I know, the C++ implementation, 
> it's O(N). If there is a new implementation with such complexity, then 
> happy days.
>
> Was just curious to know what ideas there are out there about this 
> problem. I'm aware of the fact that 2 * O(N) is still O(N), but my arrays 
> might be dealing with millions of entries. Imagine a 5000px by 5000px by 3 
> color channels. That's 75 millions. So performance is very important. 
> 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 
>> 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:
>>>
>>> Hi there,
>>>
>>> Was wondering how I can map over an array with a start and end indexes. 
>>> I know I could slice the array and then map, but performance is a concern 
>>> and slicing is O(N) where N = end - start, plus the actual mapping, another 
>>> O(N).
>>>
>>> Maybe there is another way where I just loop once over the array?
>>>
>>> Thanks a lot,
>>> Fran
>>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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.

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

[Robin Heggelund Hansen]

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:
>
> Hi there,
>
> Was wondering how I can map over an array with a start and end indexes. I 
> know I could slice the array and then map, but performance is a concern and 
> slicing is O(N) where N = end - start, plus the actual mapping, another 
> O(N).
>
> Maybe there is another way where I just loop once over the array?
>
> Thanks a lot,
> Fran
>

-- 
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.

[elm-discuss] New and faster Dict implementation

[Robin Heggelund Hansen]

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)
* Less code. (643 vs 917 lines of javascript after compilation)
* Needs testing. Please try it out and report bugs.

More information is available on elm-dev.

-- 
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.

[elm-discuss] Re: Elm with one message

[Robin Heggelund Hansen]

You can use the Elm debugger just fine with, say, webpack. Just pass in the 
`debugger: true` flag and you're good to go.

søndag 27. august 2017 10.16.08 UTC+2 skrev Vlad GURDIGA følgende:
>
> Hey Robin! 
>
> Thank you for checking and thinking about my exploration here! 
>
> 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 message history, it would fail as well I believe.
>>
>
> If by “break” you mean that I won’t be able to tell by looking at the 
> message history in the Debugger window, then you’re right: there is only 
> one kind of message, and you can’t really tell much just by looking at 
> that. 
>
> The reason it wasn’t an issue for me is that I didn’t use the Debugger and 
> stopped using the Reactor as soon as I brought in ports. I don’t know how 
> to plug in the JS that I call through ports, without having a separate 
> index.html 
> <https://github.com/gurdiga/xo.elm/blob/9fe9bd1b9f7cb13b6653ec55d9e873033e8930ed/index.html>
>  
> in which I plug the external library 
> <https://github.com/gurdiga/xo.elm/blob/9fe9bd1b9f7cb13b6653ec55d9e873033e8930ed/index.html#L13>
> , the bundle coming out of Elm 
> <https://github.com/gurdiga/xo.elm/blob/9fe9bd1b9f7cb13b6653ec55d9e873033e8930ed/index.html#L14>,
>  
> and then the bits of glue code 
> <https://github.com/gurdiga/xo.elm/blob/9fe9bd1b9f7cb13b6653ec55d9e873033e8930ed/index.html#L21-L22>
>  
> to tie them together. 
>
> I’m wondering if anyone has experience with having ports working with the 
> Elm Reactor. 樂
>  
>
>> I think a better way would be to not have nested components. Keep your 
>> entire message hierarchy, and model structure, flat.
>>
>
> Yeah, this is the default recommendation that I hear in the Elm community. 
> I’ve heard Richard Feldman mentioning that they also have a flat structure 
> for their production app at NoRedInk, but I think I just can’t imagine how 
> would that look like, and then, as I guess every other mortal, I fallback 
> to ways that I know. 
>
> One other reason why I went hierarchical is that I’m used to seeing domain 
> models as hierarchies, and in My Ideal World®✨ the code follows the domain 
> as close as possible. 
>
> I’m definitely open to hearing, or — even better — *seeing* examples of 
> large apps that use a flat structure. 邏
>

-- 
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.

[elm-discuss] Re: Elm with one message

[Robin Heggelund Hansen]

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 message hierarchy, and model structure, flat.

torsdag 24. august 2017 09.10.07 UTC+2 skrev Vlad GURDIGA følgende:
>
> Hey Elm-guys and Elm-gals! 
>
> I have this toy-project 
> 
>  
> where I’m getting my feet wet with Elm, and I’ve found an approach to 
> compose view function that’s a bit different than what The Elm Architecture 
> recommends. 邏
>
> Because I found message transformation (mapping 
> ) 
> between nested components to be counterintuitive, I left out messages, for 
> the most part. I only have one 
> 
>  
> for the whole app: 
>
> type Msg
> = Update Model (Cmd Msg) (Sub Msg)
>
> update : Msg -> Model -> ( Model, Cmd Msg )update msg model =
> case msg of
> Update model cmd sub ->
> ( { model | subscription = sub }, cmd )
>
>
> Only the top component references it 
> ,
>  
> and from then on I use callback-style functions 
> 
>  
> for wiring up the nested components:
>
> view : Dosar -> (Dosar -> Cmd msg -> Sub msg -> msg) -> Html msgview (Dosar 
> data) callback =
> let
> c data =
> callback (Dosar data)
> in
> div []
> [ h1 [] [ text "Dosar nou" ]
> , Temei.view data.temei (\v -> c { data | temei = v })
> , DocumentExecutoriu.view data.documentExecutoriu (\v -> c { data 
> | documentExecutoriu = v } Cmd.none Sub.none)
> , Actiune.view data.actiune (\v -> c { data | actiune = v })
> ]
>
>
> and also for event handlers 
> 
> :
>
> unlabeledTextField : String -> (String -> msg) -> List (Html 
> msg)unlabeledTextField defaultValue callback =
> [ input
> [ value defaultValue
> , onInput callback
> ]
> []
> ]
>
>
> It seems to work well so far, and coming from JS I find this style a bit 
> more familiar conceptually: I only have functions and values. 邏
>
> I am at about 184K of Elm now, and I’m wondering if anyone else have tried 
> to do it this way and maybe found some gotchas that I should be aware of. 
> In particular, with regards to how the code compiles to JS and maybe other 
> Elm’s inner workings. 樂
>
> Cheers! 鸞
>
> (NOTE: If you want to browse the code, please use this revision: 
> https://github.com/gurdiga/xo.elm/tree/9fe9bd1. After that I’m bringing 
> in elm-mdl , 
> and the code will probably get too noisy for the purpose of this 
> conversation. )
>

-- 
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.

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

[Robin Heggelund Hansen]

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 
pending) and comparable union types, is the difficulty of implementation. 
DEAC's seem like an advanced language feature that will take a while to get 
into the language. Does a union type require that all fields/members are 
comparable as well? Or will it only work for member-less/valueless union 
types? As a reader, how easy is it to tell if a union type is comparable, 
and is it obvious when one is lesser than another? It's not straight 
forward from a design perspective.

Enums have very clear encoding/decoding and comparability semantics, which 
is why I think they would be a good addition.

Of course, it could be that DEAC's and comparable union types is the better 
way (TM) and one should wait for that instead.

torsdag 3. august 2017 01.32.14 UTC+2 skrev Richard Feldman følgende:
>
> However, strings and numbers still need to be used in production apps for 
>> several reasons:
>> 1) Union Types is not supported in Json, so one needs to convert to/from 
>> strings or numbers for communicating with other systems.
>> 2) Union Types are not comparable, and so cannot be used as keys in Sets 
>> or Dicts.
>>
>
> Worth noting that (1) could also be fixed by having a deriving-esque way 
> to generate encoders and decoders automatically, so long as it worked for 
> union types as well as records. (Granted, the serialized format is less 
> obvious with union types compared to records.)
>
> Also worth noting that (2) is already slated to be fixed directly. It's a 
> lower priority than other things in the hopper right now, but it'd probably 
> still be higher priority than adding an enum feature. 
>

-- 
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.

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

[Robin Heggelund Hansen]

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 span essentially 
unlimited values, so case-of statements become less valuable.

However, strings and numbers still need to be used in production apps for 
several reasons:
1) Union Types is not supported in Json, so one needs to convert to/from 
strings or numbers for communicating with other systems.
2) Union Types are not comparable, and so cannot be used as keys in Sets or 
Dicts.

So a server might send me some json where the current user language is 
represented by an Int (0  and 1, norwegian and english) and the current 
game being played is a string ("chess", "checkers", "reversi"). It would be 
great to have some compiler help for these values (say, you forgot the case 
statement for "reversi"), AND it would be great to avoid writing 
encoders/decoders for the union types and converting back and forth several 
places.

Enums would help with this.

The way I imagine this to work is that an enum essentially represents a 
restricted set of String or Number. Once the compiler sees that you're 
working with an enum, it could help you out in case statements. And since 
an enum is just a string, or just a number, they can be used in the same 
places where one would normally use them, like as a value in a select.

One would need a way to check that a string/number matches the values of an 
enum though. Something like `Enum.matches : MyStringEnum -> Maybe (Enum 
MyStringEnum)`.

The one thing I can think of which makes this a bad addition to Elm, is 
that it might be a bit confusing for beginners when to use enum and when to 
use unions... maybe.

Anyway, what do people think of this?

-- 
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.

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

[Robin Heggelund Hansen]

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 anything done? Or could you still write a very successful program 
despite those problems. Cold you, in fact, have a problem without 
considering it one?

What constitutes a problem is highly subjective. It's good to keep in mind 
in this discussion.

So, the line in the docs is not wrong. "this" effectively combines logic 
and data, and Elm does maintain a separation there. The systemic problem 
being referenced, is the comingling of data and logic, not that you can 
write "this".

So why is this is a problem?

We've already defined that it is not a problem which prevents you from 
solving problems, in fact, very few thing in Javascript or Java or any 
other functional language pose such a problem. But there are some downsides 
that is worth considering:

1. What is "this"?
In a single class, "this" is a very easy thing. It refers to this instance 
of a class. But what does "this" mean in a context where the class is a 
child? Does "this" refer to this instance, or a parent instance, or a 
parent parent instance? This might not be conceived as a problem, since we 
got fancy IDE's helping us keep track of things, but I would argue that 
having "this" in any non-trivial piece of code makes it difficult to 
understand such code if you're reading it for the first time. Avoiding 
"this" makes code, IMHO, easier to read.

2. What's the downside of coupling data and logic?
Let's say we have the two following classes:

class Person { public int age; }
class Animal { public int age; }

Why can't we store both of these in an array? They look the same, the carry 
the same information, but they are different. If I write a function which 
operates on the age field, why do I need to write this twice for both 
classes? I can of course write a `Ageable` interface which declares a 
`getAge` function, but why is that necessary? What benefit do we get here 
by combining logic with data?

In Elm, you would define these as type aliases, meaning every function 
would work on one or the other, and you could store them in Lists or what 
not. You can also easily create extendable types if you only care about one 
or more fields.

Another downside: I need a function that works on all integers. Why do I 
have a create a static class for this? Why can't I just have a free 
function for this? What is the benefit of having it this way?

These aren't big things. But for me, combining logic and data makes it 
harder to understand code and to re-use it. There also doesn't seem to be 
any benefit in that combination.

Note: Javascript can avoid all these functions quite easily, but that's 
because javascript really is just as functional as it is object-oriented.

I'd also like to leave this link here, great talk on the 
subject: https://www.youtube.com/watch?v=-6BsiVyC1kM

torsdag 20. juli 2017 09.55.54 UTC+2 skrev Dave Ford følgende:
>
> There is a line from the docs that I am trying to understand: "Elm 
> encourages a strict separation of data and logic, and the ability to say 
> this is primarily used to break this separation. This is a systemic 
> problem in Object Oriented languages that Elm is purposely avoiding."
>
> What is the systemic problem being reference? Is it the [lack of] "separation 
> of data and logic" or "the ability to say this"?
>
> I have been programming in Java (an OO language) for a long time. I can 
> name dozens of systemic problems in the language. But the ability to say 
> "this" is not one of them. Nor is it the commingling of data and logic. 
>
> Please help me to understand what the author is talking about.
>
> Thanks.
>
> Side note: "this" *is* a problem in JavaScript. But not in OO generally.
>

-- 
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.

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

[Robin Heggelund Hansen]

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 
> little syntactic sugar in the compiler would make the medicine go down?
>
> For example, let's say that := meant "assign with conversion" in Elm.
>
> In the expression:
>
> a := b
>
> the compiler knows the types of a and b, and it knows if there is a 
> function x of type b -> a, so it could just make the substitution (or throw 
> an error if a suitable function can't be found).
>
> So if a is a Dict Int String and b is a List (Int String) then the 
> compiler would find Dict.fromList
>

-- 
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.

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

[Robin Heggelund Hansen]

Excellent points. I'll take a look at the links you posted. Maybe there's 
something in there I can't help but pursue :)

mandag 12. juni 2017 07.24.10 UTC+2 skrev Evan følgende:
>
> Oh, and a few more notes. I recently did two pull requests on a framework 
> comparison benchmark to improve the Elm implementation:
>
>- Start using lazy 
><https://github.com/krausest/js-framework-benchmark/pull/192> - This 
>made the Elm version significantly faster than before.
>- Get rid of List => Array => List conversion 
><https://github.com/krausest/js-framework-benchmark/pull/194> - This 
>actually had *no significant impact* on the results. With random 
>noise, it actually got slower in the run they chose. Touching the DOM is 
> so 
>expensive that it tends to overshadow any other concern, and I had the 
> same 
>experience converting TodoMVC to use a Dict rather than List.
>
> In looking for these, I also found this PR 
> <https://github.com/krausest/js-framework-benchmark/pull/195> that does 
> another optimization which should help a bit. The fact that you can now 
> remove without changing event handlers in all subsequent entries should 
> provide a decent speed boost, but we'll see when the results are out!
>
> This is all to say: it is important to contextualize these ideas in the 
> performance characteristics of real programs, and those characteristics can 
> be quite surprising given how the DOM works.
>
>
> On Monday, June 12, 2017 at 6:08:50 AM UTC+1, Evan wrote:
>>
>> Very interesting, thank you for sharing!
>>
>> I wanted to add a couple notes and ideas that I've had separately.
>>
>>
>> Syntax
>>
>> I was formerly somewhat keen on having special syntax for other 
>> collections. For example, OCaml allows you to say [| 1, 2, 3 |] to create 
>> an array. Hassan made a really nice proposal 
>> <https://github.com/elm-lang/elm-plans/issues/12> to have it be #[ 1, 2, 
>> 3 ] back in 2015. Since then I realized you can do the following:
>>
>> a = Array.fromList
>> s = Set.fromList
>> d = Dict.fromList
>>
>> array =
>>   (a[ 1, 2, 3 ])
>>
>> set =
>>   (s[ 1, 2, 3 ])
>>
>> dict =
>>   (d[ 1 => "Tom", 2 => "Sue", 3 => "Jane" ])
>>
>> (=>) = (,)
>>
>> This is 1 or 2 characters off all the proposals out there, and it is 
>> visually much nicer in my opinion.
>>
>> With that knowledge, the case for special syntax seems significantly 
>> weaker. I can also imagine detecting when a list is converted to something 
>> else and doing something more clever in the compiler. That path seems 
>> better overall to me.
>>
>>
>> List performance of map, foldl, and foldr
>>
>> I shared this blog post 
>> <https://blogs.janestreet.com/optimizing-list-map/> about optimizing 
>> List.map in OCaml a while ago, and Fred did some excellent work on this 
>> <https://github.com/elm-lang/core/pull/707>! I have not had a chance to 
>> fully assess the impact on generated code size, so I have not merged it in 
>> yet. That trick can likely be very helpful for foldl and foldr, but no one 
>> has looked into it.
>>
>> I suspect there are many creative things we can do if some focused energy 
>> was applied to lists. I have not taken a comprehensive look at this after 
>> Elm got TCO, and I suspect we can do better!
>>
>>
>> Alternate Implementations of List
>>
>> Another thing to consider before switching to some other data structure 
>> is that we can change the performance profile of List using various 
>> techniques behind the scenes. For example:
>>
>>- Skip Lists <https://en.wikipedia.org/wiki/Skip_list>
>>- Finger Trees <https://en.wikipedia.org/wiki/Finger_tree> that maybe 
>>do some sort of "compression" on older leaves
>>- I believe there's one that immutable.js does for their lists? 
>>Richard told me about something like this. Where "old" nodes grow 
>>exponentially in size so the nodes are 1, 2, 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 
>> relatively common, at least in my experience, so I think it'd be good to 
>> explore concrete bottlenecks in Elm code and see if there are not creative 
>> things we can do to improve the performance profile of List without 
>> ch

[elm-discuss] The way forward for Elm Arrays

[Robin Heggelund Hansen]

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 comparing 
Arrays and Lists.

There are some questions at the bottom of the document that I would love to 
get feedback on.

-- 
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.

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

[Robin Heggelund Hansen]

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 useful: https://dev.to/rtfeldman/tour-of-an-open-source-elm-spa
>

-- 
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.

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

[Robin Heggelund Hansen]

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 
is still the case today).

torsdag 23. mars 2017 21.15.51 UTC+1 skrev Simon følgende:
>
> On elm-dev I get the impression that bigger barriers are being built to 
> towards javascript interop.
>
> I think building the barriers before the webapi is provided in Elm is the 
> wrong way around, but that's not the only case where practical needs are at 
> risk.
>
> Consider msgpack - a sort of compressed json. It's well specified but 
> today not much used. No one has written a library for it in Elm, but there 
> is a well-tested JS one. The encoding is simply calculations, so in the 
> normal run of things this should be a synchronous operation. If ports 
> returned Tasks this would not be a huge issue, but they return Commands and 
> thus force you back around the update loop (and the creation of an extra 
> Msg, which makes code intent less transparent).
>
> The work around is a native file along the lines of (or see this NoRedInk 
> library 
> ):
>
> ```
> var _user$project$Native_Msgpack = function() {
>
> function encode(k) {
> return msgpack.encode(k.kwd);
> }
> }
> ```
>
> It's pretty clear that these practices are frowned upon, but the shift to 
> 'kernel' sounds like a plan to squeeze the pragmatic programmer's options 
> further. I hope that's not the case.
>
>

-- 
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.

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

[Robin Heggelund Hansen]

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, January 26, 2017 at 3:30:25 AM UTC-5, Peter Damoc wrote:
>>
>> You need the --assume_function_wrapper flag. 
>>
>  
> Thank you Peter!!! That was all that was necessary, no need for the 
> compiler to emit anything special. I updated the build script and am 
> proceeding happily.
>
> I am hearing what you’re saying about the relative importance of 
> compression vs light minification vs aggressive compilation. I’m actually 
> more hopeful about optimizations. I had a somewhat math- and SVG-intensive 
> app in ClojureScript (where the Google Closure Compiler is baked into the 
> most minimalistic workflow) and the framerate improvement between 
> whitespace-only minification and advanced compilation was very pleasant. 
> Alas my current tiny app is network-bound, so no noticeable speed 
> improvements .
>
> Again, many thanks for pointing out this flag !
>

-- 
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.

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

[Robin Heggelund Hansen]

I was mostly talking about size. I know Closure very well, and I'm well 
aware of what code must look like in order to get the most out of advanced 
opts. The way Elm is compiled makes it easy for uglify to get the same 
results in mangling and dead-code elimination, but of course it won't do 
inlining. Still, there is a very small difference between uglify and google 
closure with advanced_opts. If Elm had been compiled into modules, then 
uglify would have done much worse.

torsdag 26. januar 2017 02.37.59 UTC+1 skrev Bob Zhang følgende:
>
> Not really, closure has very very advanced 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 Heggelund Hansen <skinn...@gmail.com 
> > wrote:
>
>> Uglify essentially removes functions that are not added to objects (how 
>> you export functions from "namespaces"). Since Elm adds all functions to a 
>> single local-scope, and then only exports ports and the main function, it's 
>> very easy for uglify to see what functions are unused, and can therefore 
>> remove them. Google Closure can do the same thing but, as you said, breaks 
>> on advanced compilation. Fortunately, advanced optimization doesn't give 
>> you that much in Elm due to the way it compiles to JS. The difference 
>> between uglify and google closure (w/advanced opts) was perhaps 3-4kb last 
>> I checked. Advanced opts breaks because of four lines in Elm's runtime that 
>> checks for a specific key in certain cases (string tagging). More 
>> information here: https://github.com/elm-lang/core/pull/734
>>
>>
>> onsdag 25. januar 2017 16.56.12 UTC+1 skrev OvermindDL1 følgende:
>>>
>>> I use browserify for some code via brunch, rollup for others, I run both 
>>> of those through uglify + closure when building a 'prod' release. 
>>>  browserify and rollup and both blazing fast in compile time with very 
>>> large bases of code, but rollup prunes based on functions called (meaning 
>>> it can break on dynamic name access, but that is rare) and browserify just 
>>> prunes based on module importing (which can break on dynamic module name 
>>> access, but that is also rare).  uglify is just a minimizer but it does few 
>>> optimizations but runs fast, however Google's closure runs *very* slow, but 
>>> optimizes well, however higher optimization levels will ruin any code that 
>>> does any kind of dynamic key access that is not dict-like (it breaks elm 
>>> pretty hard last I tried it, but it works on my bucklescript code 'so far').
>>>
>>>
>>> On Wednesday, January 25, 2017 at 8:45:12 AM UTC-7, GordonBGood wrote:
>>>>
>>>>
>>>>
>>>> On Wednesday, 25 January 2017 22:25:39 UTC+7, OvermindDL1 wrote:
>>>>>
>>>>> Sent too soon.
>>>>>
>>>>> Also, uglify is a minimizer, it does a *lot* more than tree shaking.
>>>>>
>>>>>
>>>>> On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote:
>>>>>>
>>>>>> Tree Shaking as implemented by Brunch and Webpack default setups at 
>>>>>> least only prune based on if a module is accessed or not (which is also 
>>>>>> 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 
>>>>>> to try that one with Elm.  :-)
>>>>>>
>>>>>>
>>>>>> On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund 
>>>>>> Hansen wrote:
>>>>>>>
>>>>>>>
>>>>>>> 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 
>>>>>>>> optimizations 
>>>>>>>> anyway.
>>>>>>>>
>>>>>>>
>>>>>>> This is

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

[Robin Heggelund Hansen]

Uglify essentially removes functions that are not added to objects (how you 
export functions from "namespaces"). Since Elm adds all functions to a 
single local-scope, and then only exports ports and the main function, it's 
very easy for uglify to see what functions are unused, and can therefore 
remove them. Google Closure can do the same thing but, as you said, breaks 
on advanced compilation. Fortunately, advanced optimization doesn't give 
you that much in Elm due to the way it compiles to JS. The difference 
between uglify and google closure (w/advanced opts) was perhaps 3-4kb last 
I checked. Advanced opts breaks because of four lines in Elm's runtime that 
checks for a specific key in certain cases (string tagging). More 
information here: https://github.com/elm-lang/core/pull/734

onsdag 25. januar 2017 16.56.12 UTC+1 skrev OvermindDL1 følgende:
>
> I use browserify for some code via brunch, rollup for others, I run both 
> of those through uglify + closure when building a 'prod' release. 
>  browserify and rollup and both blazing fast in compile time with very 
> large bases of code, but rollup prunes based on functions called (meaning 
> it can break on dynamic name access, but that is rare) and browserify just 
> prunes based on module importing (which can break on dynamic module name 
> access, but that is also rare).  uglify is just a minimizer but it does few 
> optimizations but runs fast, however Google's closure runs *very* slow, but 
> optimizes well, however higher optimization levels will ruin any code that 
> does any kind of dynamic key access that is not dict-like (it breaks elm 
> pretty hard last I tried it, but it works on my bucklescript code 'so far').
>
>
> On Wednesday, January 25, 2017 at 8:45:12 AM UTC-7, GordonBGood wrote:
>>
>>
>>
>> On Wednesday, 25 January 2017 22:25:39 UTC+7, OvermindDL1 wrote:
>>>
>>> Sent too soon.
>>>
>>> Also, uglify is a minimizer, it does a *lot* more than tree shaking.
>>>
>>>
>>> On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote:
>>>>
>>>> Tree Shaking as implemented by Brunch and Webpack default setups at 
>>>> least only prune based on if a module is accessed or not (which is also 
>>>> 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 
>>>> to try that one with Elm.  :-)
>>>>
>>>>
>>>> On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund 
>>>> Hansen wrote:
>>>>>
>>>>>
>>>>> 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 
>>>>>> optimizations 
>>>>>> anyway.
>>>>>>
>>>>>
>>>>> This is false. You are correct that Elm compiles everything into a 
>>>>> single module, but this means that tree-shaking becomes *easier*, not 
>>>>> harder. It also makes name-mangling much easier, as everything is 
>>>>> local-scope. With Elm code, tree-shaking can be done with Uglify.js. Just 
>>>>> tell uglify to warn you when it removes a function, and you'll see it 
>>>>> removes *a lot* of code.
>>>>>
>>>>
>> I see there is the old Google Web Compiler, Browserify, Uglify, Rollup 
>> and I don'e know how many others.  Has anyone compared them all and has any 
>> recommendations on which to use?  If some such as Uglify and Rullup do so 
>> much more than just Tree Shaking, what are the disadvantages in their use, 
>> speed of "compilation"?
>>
>

-- 
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.

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

[Robin Heggelund Hansen]

> 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 optimizations 
> anyway.
>

This is false. You are correct that Elm compiles everything into a single 
module, but this means that tree-shaking becomes *easier*, not harder. It 
also makes name-mangling much easier, as everything is local-scope. With 
Elm code, tree-shaking can be done with Uglify.js. Just tell uglify to warn 
you when it removes a function, and you'll see it removes *a lot* of code. 

-- 
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.

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

[Robin Heggelund Hansen]

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 equivalent Elm application, it will also be much slower unless you 
have steel discipline and are willing to write more code. Elm's compiler is 
also faster than both Babel and Typescript, and compiler speed will get 
*much* faster in the next release. In my experience, Elm is already better 
than Javascript in every conceivable way, and that's before taking static 
typing into account. True, I don't write games, but if I did I probably 
wouldn't do it in an immutable language due to garbage collector concerns. 
Depending on the game, I wouldn't even write it in a javascript environment 
due to the lack of threads.

Why would you want arrays instead of tagged-objects as the primary 
data-structure? Just because Bucklescript does it doesn't make it faster. 
Try benchmarking it yourself. I did. Depending on the browser, accessing 
and/or changing an array isn't necessarily faster than accessing/altering a 
javascript object.

Finally, many people today are using Elm in production. There isn't a 
general consensus amongst Elm's users that the language is too slow, 
outputs too much code or is slow to compile (a cold compile of my app takes 
~9seconds. That is NOTHING compared to an equivalent typescript application 
I'm working on, and isn't noticed in practice because of incremental 
compiles). The problem with Elm (if you indeed could call it a problem) is 
the lack of features. Many people would like better asset management, which 
is why Evan is working on it. Personally, I would like some sort of 
reflection support, as well as nested record syntax. Actually, I would 
gladly take release of the local-storage module before any of those, and 
re-connect notifications in elm-websockets.

The short of it is, the problems you're mentioning in this thread aren't 
problems for the vast majority of Elm developers. Had it been, they 
would've been addressed. Personally, I'm glad Evan isn't focused on the 
things you've proposed. There are other things I want that I'm glad is 
having a higher priority.

mandag 23. januar 2017 18.52.12 UTC+1 skrev GordonBGood følgende:
>
> 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 

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

[Robin Heggelund Hansen]

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. It should have less bugs 
than the current version in core. For some operations (slicing and append) 
it is slower, for other operations (equality and push) it is faster. I'd 
love to hear feedback :)

This new version makes the Array type opaque (breaking change). It also 
delivers performance improvements in the range of 1.25-5x for certain 
operations.

-- 
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.

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

[Robin Heggelund Hansen]

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 applications.

mandag 26. desember 2016 18.44.49 UTC+1 skrev GordonBGood følgende:
>
> *Synopsis:*  Some, including  Evan, maintain that Elm can be "faster than 
> JavaScipt".  While that may be true for some use cases including use of 
> perhaps more efficient UI updates due to compartmentalized use of 
> VirtualDOM, the actaul Javascript code generated by the compiler  is not 
> very efficient for many/most tight code cases.  The reason is often 
> unnecessary nested function calls that could easily be eliminated by making 
> full use of the type information that the Elm compiler has.
>
> Part I
>
> *An example;*  The following tight loop doesn't really do anything, so 
> should therefore compile into the very tightest of code (and I'm not 
> expecting the Elm compiler to recognize that the result is actually known 
> at compile time):
>
> range : Int
> range = 10
>
> testProg : Int -> Int
> testProg n = -- do some work
>   let lmt = min (n + 1) range in
>   let loop i =
> if i >= lmt then i else
> loop (i + 1) in loop n
>
> which compiles to the following JavaScript:
>
> var _user$project$Temp1482759649866537$range = 10;
> var _user$project$Temp1482759649866537$testProg = function (n) {
> var lmt = A2(_elm_lang$core$Basics$min, n + 100, 
> _user$project$Temp1482759649866537$range);
> var loop = function (i) {
> loop:
> while (true) {
> if (_elm_lang$core$Native_Utils.cmp(i, lmt) > -1) {
> return i;
> } else {
> var _v0 = i + 1;
> i = _v0;
> continue loop;
> }
> }
> };
> return loop(n);
> };
> All right, the code looks fairly good, and we can see that for the inner 
> `loop` function that the compiler used its new capability to do tail call 
> optimization and turn it into a while loop.  Also, one might expect that 
> any decent JIT compiler such as Chrome V8 will use constant folding and get 
> rigd of the `_v0 variable.  However, the real limitation of this loop is 
> the call to the `Native_Utils.cmp` function.  Function calls are expensive 
> at 10's of CPU clock cycles each!
>
> The pertinent JavaScript for `Native_Utils.cmp` is as follows:
>
> var LT = -1, EQ = 0, GT = 1;
>
> function cmp(x, y)
> {
> if (typeof x !== 'object')
> {
> return x === y ? EQ : x < y ? LT : GT;
> }
> ...
>
> Note that there are three native branches here (in addition to the 
> enclosing one):  one for the check to see it the arguments are objects 
> (which of course they are not in the case of Int's as here or Float's as 
> the compiler well knows), one to check if they are equal. and (given that 
> generally they won't be equal most of the time) one to see which is 
> greater.  Now these conditions are not so bad by themselves as they are 
> very predictable for modern CPU's branch prediction (i is almost always < 
> lmt), so that will cost at most a few CPU cycles; However, the call to the 
> function in the first place will cost 10's of CPU clock cycles!
>
> Given that the compiler already knows and strictly enforces that the 
> arguments are both Int's or Float's (which are both just Numbers in 
> JavaScript), there is no reason that it cannot directly output (i >= lmt) 
> instead of the function call and make the whole inner loop take only a few 
> CPU clock cycles (on a JavaScript engine such as Chrome V8).  If the 
> compiler were consistent in applying this specialization rule, there would 
> be no need for the `Native_Utils.cmp` function to do the check if the 
> arguments are objects, but for safety's sake and considering that one extra 
> check in the case of objects is likely negligible compare to the object 
> processing, it may as well be left in for its true best use case of 
> comparing objects of the various kinds.
>
> *The Elm Compiler only deals with two primitive types:  Int and Float 
> (which are both actual Number/Float to JavaScript), which makes direct use 
> of primitive operands very easy*
>
> *Part II*
>
> In a similar way, the definition of the Bitwise library to emulate 
> Haskell's definition of the Data.Bits library was silly for only five Int 
> functions, made even worse by a name collision with the Bool `xor` 
> operator.  Because these are library functions, there is at least one level 
> of function call for every use.
>
> *Just as for the above function call for known primitive types (in this 
> case only for Int), these functions should be added to the Basics library 
> as operators with appropriate infix levels and with the names `&&&`, `|||`, 
> `^^^` , `<<<`, and `>>>` just as for F# (which Elm emulates more and more), 
> with the Elm compiler directly substituting the equivalent primitive 
> JavaScript operators.  The Bitwise library, which should never have 

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

[Robin Heggelund Hansen]

I was the one who raised the original issue. The reason there is only a 20% 
performance in the given example is because the comparison operator isn't 
the bottleneck of the code, which tests retrieving an object from an 
immutable array with 10.000 elements. What you are testing is essentially 
only measuring the overhead of a comparison operation. Still, my benchmark 
is able to run at 7,5 million ops per second, running on a macbook air from 
2013. This is fast enough for most web apps, and this brings me to my next 
point.

Elm is, at least currently, a language to make web applications. How often 
are you going to run calculations in tight loops where the performance 
impact of comparison or equality operators gives a noticeable performance 
impact for the end user in a web browser?

I'm not saying that the proposed optimisation isn't worthwhile, it is. But 
Elm, being a 0.x language still, has a lot more important things to improve 
on before it turns its attention back to performance, which is already very 
good. Things like hot-code reloading, improved package manager and bug 
fixes.

tirsdag 27. desember 2016 03.41.29 UTC+1 skrev GordonBGood følgende:
>
>
>
> 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 that the code generator part of the compiler is not 
>> aware of type information, and adding this would be a serious undertaking. 
>> It will probably come at some point, as there are interesting optimizations 
>> that can be made, like the one mentioned
>>
>
> Although it is good to see that Even is aware of the issue, it is 
> discouraging to learn that the type information is not retained by the code 
> generator and therefore this improvement is part of a "huge project"; thus 
> the linked issue has been closed.  The person who raised the original issue 
> developed some timing results that showed only about a 20% speed 
> improvement for the particular code use.  However, when I compare the above 
> tight loop written directly in JavaScript, the difference here is about 
> 700%!  Of course, real use cases won't be quite this large, but I could see 
> a fairly tight loop being 300% (+/- 100%) faster.
>  
>
>>
>> Part II: Bitwise operators are inlined in 0.18, which gave a noticable 
>> performance boost in libraries like Skinney/elm-array-exploration and 
>> mgold/random-pcg. Having it available as a function (just like +, -, * 
>> etc.) allows more flexibility like currying.
>>
>
>  I checked and you are right that these functions are now inlined.
>
> The only other thing they should also have is infix for those with two 
> operands for better (conventional) clarity of code, but this is no biggy.
>
> It turns out that the huge slowdown as compared to equivalent JavaScript 
> code is another instance of the Part I problem as it is caused by a *call 
> to `Native_Utils.eq` which is even less efficient than `Native_Utils.*
> *cmp`* resulting in about a 1500% slowdown compared to JavaScript for the 
> following code:
>
> import Bitwise as Bw
>
> testProg : Int -> Int
> testProg n = -- do some work
>   let loop i =
> if Bw.and i 0x3FFF == 0x3FFF then i else
> loop (i + 1) in loop n
>
> which compiles to:
>
> var _user$project$Temp1482804013226255$testProg = function (n) {
> var loop = function (i) {
> loop:
> while (true) {
> if (_elm_lang$core$Native_Utils.eq(i & 1073741823, 1073741823)) {
> return i;
> } else {
> var _v0 = i + 1;
> i = _v0;
> continue loop;
> }
> }
> };
> return loop(n);
> };
>
> with  `Native_Utils.eq` defined as:
>
> function eq(x, y)
> {
> var stack = [];
> var isEqual = eqHelp(x, y, 0, stack);
> var pair;
> while (isEqual && (pair = stack.pop()))
> {
> isEqual = eqHelp(pair.x, pair.y, 0, stack);
> }
> return isEqual;
> }
>
>
> function eqHelp(x, y, depth, stack)
> {
> if (depth > 100)
> {
> stack.push({ x: x, y: y });
> return true;
> }
>
> if (x === y)
> {
> return true;
> }
> ...
>
> For this use case, there are a succession of conditions which won't cost 
> that much as explained in the opening post, but it is twice as slow as the 
> example in Part I because *there are typically two nested calls of the 
> functions `Native_Utils.eq` with `Native_Utils.eqHelp` called from within 
> it!*  This is the reason it is twice as slow as the example in Part I.
>
> If and when the issue as of Part I is fixed, then bitwise operations will 
> be fixed too.
>
> M

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

[Robin Heggelund Hansen]

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 undertaking. 
It will probably come at some point, as there are interesting optimizations 
that can be made, like the one mentioned.

Part II: Bitwise operators are inlined in 0.18, which gave a noticable 
performance boost in libraries like Skinney/elm-array-exploration and 
mgold/random-pcg. Having it available as a function (just like +, -, * 
etc.) allows more flexibility like currying.

mandag 26. desember 2016 18.44.49 UTC+1 skrev GordonBGood følgende:
>
> *Synopsis:*  Some, including  Evan, maintain that Elm can be "faster than 
> JavaScipt".  While that may be true for some use cases including use of 
> perhaps more efficient UI updates due to compartmentalized use of 
> VirtualDOM, the actaul Javascript code generated by the compiler  is not 
> very efficient for many/most tight code cases.  The reason is often 
> unnecessary nested function calls that could easily be eliminated by making 
> full use of the type information that the Elm compiler has.
>
> Part I
>
> *An example;*  The following tight loop doesn't really do anything, so 
> should therefore compile into the very tightest of code (and I'm not 
> expecting the Elm compiler to recognize that the result is actually known 
> at compile time):
>
> range : Int
> range = 10
>
> testProg : Int -> Int
> testProg n = -- do some work
>   let lmt = min (n + 1) range in
>   let loop i =
> if i >= lmt then i else
> loop (i + 1) in loop n
>
> which compiles to the following JavaScript:
>
> var _user$project$Temp1482759649866537$range = 10;
> var _user$project$Temp1482759649866537$testProg = function (n) {
> var lmt = A2(_elm_lang$core$Basics$min, n + 100, 
> _user$project$Temp1482759649866537$range);
> var loop = function (i) {
> loop:
> while (true) {
> if (_elm_lang$core$Native_Utils.cmp(i, lmt) > -1) {
> return i;
> } else {
> var _v0 = i + 1;
> i = _v0;
> continue loop;
> }
> }
> };
> return loop(n);
> };
> All right, the code looks fairly good, and we can see that for the inner 
> `loop` function that the compiler used its new capability to do tail call 
> optimization and turn it into a while loop.  Also, one might expect that 
> any decent JIT compiler such as Chrome V8 will use constant folding and get 
> rigd of the `_v0 variable.  However, the real limitation of this loop is 
> the call to the `Native_Utils.cmp` function.  Function calls are expensive 
> at 10's of CPU clock cycles each!
>
> The pertinent JavaScript for `Native_Utils.cmp` is as follows:
>
> var LT = -1, EQ = 0, GT = 1;
>
> function cmp(x, y)
> {
> if (typeof x !== 'object')
> {
> return x === y ? EQ : x < y ? LT : GT;
> }
> ...
>
> Note that there are three native branches here (in addition to the 
> enclosing one):  one for the check to see it the arguments are objects 
> (which of course they are not in the case of Int's as here or Float's as 
> the compiler well knows), one to check if they are equal. and (given that 
> generally they won't be equal most of the time) one to see which is 
> greater.  Now these conditions are not so bad by themselves as they are 
> very predictable for modern CPU's branch prediction (i is almost always < 
> lmt), so that will cost at most a few CPU cycles; However, the call to the 
> function in the first place will cost 10's of CPU clock cycles!
>
> Given that the compiler already knows and strictly enforces that the 
> arguments are both Int's or Float's (which are both just Numbers in 
> JavaScript), there is no reason that it cannot directly output (i >= lmt) 
> instead of the function call and make the whole inner loop take only a few 
> CPU clock cycles (on a JavaScript engine such as Chrome V8).  If the 
> compiler were consistent in applying this specialization rule, there would 
> be no need for the `Native_Utils.cmp` function to do the check if the 
> arguments are objects, but for safety's sake and considering that one extra 
> check in the case of objects is likely negligible compare to the object 
> processing, it may as well be left in for its true best use case of 
> comparing objects of the various kinds.
>
> *The Elm Compiler only deals with two primitive types:  Int and Float 
> (which are both actual Number/Float to JavaScript), which makes direct use 
> of primitive operands very easy*
>
> *Part II*
>
> In a similar way, the definition of the Bitwise library to emulate 
> Haskell's definition of the Data.Bits library was silly for only five Int 
> functions, made even worse by a name collision with the Bool `xor` 
> operator.  Because these are library functions, there is at least one level 
> of function call for every use.
>
> *Just as for the above function call for known primitive types (in 

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

[Robin Heggelund Hansen]

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: https://github.com/elm-lang/core/issues/649). It's also 
written entirely in javascript, is poorly documented and not so well 
understood. The new implementation fixes all of this, but to make sure it 
is as stable as I think it is, it needs to be tested.

If you have a project where you use arrays, or stopped using arrays because 
of bugs, please consider testing this new implementation out.

To get started, install Skinney/elm-array-exploration, and replaced ever 
instance of `import Array` in your code with `import Hamt.Array as Array`. 
If everything is working correctly, then great! If not, please let me know 
so it can be fixed.

Thanks for your help :)

-- 
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.

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

[Robin Heggelund Hansen]

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 
> centralized.
>
> After all, /r/elm is still going to exist whether there's additionally a 
> Google Group, a Discourse forum, etc. It'd be nice to have only one board 
> to check.
>
> What do people think?
>
>

-- 
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.

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

[Robin Heggelund Hansen]

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 runtime, core library, virtual dom and html library.

torsdag 24. november 2016 13.40.12 UTC+1 skrev Rafał Cieślak følgende:
>
> Robin:
>
> I would just keep everything in one Elm app, then use a router to display 
>> the correct page.
>
>
> The problem I see with this is that our app is not SPA, so each page that 
> needs an Elm app would need to load a big blob of JS with dependencies of 
> all the Elm modules in our source code.
>
> When it comes to google closure, Elm only works with SimpleOptimizations.
>
>
> Thanks for the info, I was under the impression that it worked okay with 
> advanced optimizations.
>
> In any case, the difference between Google Closure and Uglify is very 
>> small when it comes to Elm.
>
>
> Yeah, that's why I eventually gave up – the few KBs of reduced size were 
> not worth the time I spent figuring out how to make this all work with 
> Closure Compiler. ;)
>
>
>
> Noah:
>
> So you use a similar setup to what I described, right? I assume that by "a 
> unique Elm app" you mean "a main module" and that all the main modules 
> share a single elm-package.json.
>
> This is ideal in terms of build time and reliabitly, as everything can be 
>> built and once and  share a single lot of packages. 
>
>
> Yeah, definitely. Another advantage for me is what I mentioned earlier: it 
> can be easily plugged in to our existing workflow with webpack.
>

-- 
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.

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

[Robin Heggelund Hansen]

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 Google Closure and Uglify is very small 
when it comes to Elm. In my app, Uglify brings size down to ~80Kb, while 
Closure with AdvancedOpts brings it down to ~74Kb. When gzipped, the 
differences are barely noticeable.

onsdag 23. november 2016 19.49.19 UTC+1 skrev Rafał Cieślak følgende:
>
> For the posterity, I implemented said "architecture" in one of my side 
> projects. https://github.com/ravicious/rails-elm-forms/commit/b5ac6964f
>
> The only difference from what I said above is that the Elm apps don't have 
> their own entry points in the webpack config. Instead, the entry points are 
> the JS file which require the Elm file and then embed the app.
>
> I wish I could use Closure Compiler, but I couldn't get the trio (Closure 
> Compiler + webpack + Elm) to work together, for some reason the two webpack 
> Closure Compiler plugins I tried to use mess up the Elm code.
>
> On Saturday, November 19, 2016 at 9:58:27 PM UTC+1, Rafał Cieślak wrote:
>>
>> The project I'm working on is not a SPA, it's a rather big Rails app that 
>> sometimes needs JS to make some part of the page dynamic – usually it's 
>> about dynamic forms.
>>
>> When I was thinking about ways in which I can integrate Elm into the 
>> project, I thought about having a separate Elm project for each feature: so 
>> there would be an order_form folder with its own elm-package.json, its 
>> own versions of dependencies and Elm. Beside it there would be another 
>> folder, let's say product_form, also with its own elm-package.json and 
>> so on.
>>
>> I quickly realized it could be a nightmare from the maintainability point 
>> of view, since each folder would require its own version of Elm, thus each 
>> folder would need to have a separate package.json which would install Elm 
>> from npm.
>>
>> I looked at elm-webpack-loader and found out that it requires me to have 
>> a single elm-package.json for the whole project. Separate forms would 
>> have an access to the same dependencies and the same version of Elm. At 
>> first I was put off by this solution, as it was completely the opposite of 
>> what I had in mind (separate elm-package.json for each form). Finally, I 
>> had a sudden moment of clarity and I realized that what elm-webpack-loader 
>> does is exactly what we already do with our smaller React apps: each lives 
>> in its own directory, each has a separate entry point in webpack config, 
>> but all share the same package.json and all have access to the same deps.
>>
>> Do I get it right? If so, how should I structure the apps on the Elm side?
>>
>> I was thinking about creating a directory app/assets/javascripts/elm. 
>> Each Elm "app" would have its main module under 
>> app/assets/javascripts/elm/src. Each Elm "app" would also have its own 
>> entry point in webpack. app/assets/javascripts/elm/src would be added as 
>> a source directory in source-directories in elm-package.json. Then I 
>> could "namespace" each "app", so that there's OrderForm (the main 
>> module) and everything that is specific to it is nested under OrderForm (
>> OrderForm.Foo, OrderForm.Bar).
>>
>> This way webpack could easily handle building all the Elm apps along with 
>> React apps.
>>
>> Are there any pitfalls in my thinking? Do you see ways in which this 
>> approach could fail? If you use elm-webpack-loader and had a similar 
>> problem, I'd love to hear how you handled it!
>>
>

-- 
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.

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

[Robin Heggelund Hansen]

'A itemList' ;-)

tirsdag 22. november 2016 14.06.17 UTC+1 skrev Andrew Radford følgende:
>
> I think his point was if it was a Maybe List Int, then you would have
>
> 'A items'
>
> It still seems English is not up to this task :) We should probably just 
> make up a new word, start using it day to day, then have it included in the 
> OED. If it can be done for 'selfie 
> <https://en.oxforddictionaries.com/definition/selfie>', then we could do 
> it for 
>
> On Tuesday, 22 November 2016 10:35:48 UTC, Will White wrote:
>>
>> type Maybe thing = A thing | Nothing
>>
>> So with List.head list I’d get A 2 or Nothing.
>>
>> On 22 Nov 2016, at 10:20, Oliver Searle-Barnes <oli...@opsb.co.uk> wrote:
>>
>> The problem with Some is that it should be A/An/Some depending on the 
>> subject. I'm starting to come round to Thing vs Nothing. While the grammer 
>> isn't spot on the semantics are very clear.
>>
>>
>> On Tuesday, 22 November 2016 11:06:10 UTC+1, Will White wrote:
>>>
>>> weapon = Just sword doesn’t make sense for Maybe. It implies “just 
>>> sword, out of all the weapons”. Just *would*make sense in a Just weapon 
>>> | All (List weapon) type, where weapon could also be All [ sword, mace, 
>>> nunchuk ]. 
>>>
>>> I think we all agree that Nothing totally nails its concept (better than 
>>> null for the uninitiated). I'm just looking for a word that implies its 
>>> alternative is Nothing, e.g. Thing, Something. If it’s grammatically 
>>> correct, that’s a bonus, but I think eliminating things which hinder 
>>> understanding is more important.
>>>
>>> On 22 Nov 2016, at 00:24, joseph ni <jose...@gmail.com> wrote:
>>>
>>> I came to Elm not knowing about the Maybe type. 
>>> The hardest thing for me to grasp was the use case and being able to map 
>>> : (a -> b) -> Maybe a -> Maybe b. And knowing when to use a Maybe (rarely) 
>>> vs when to use a union type or refactor the code so it doesn't need the 
>>> Maybe type.
>>>
>>> If I was to qualitatively estimate the amount of time spent learning 
>>> about Maybe. I'd say it took me a moment to understand `Maybe a = Just a | 
>>> Nothing` and a couple of months to get comfortable enough with the Maybe 
>>> type now to understand where it's needed in my app.
>>>
>>> So I'd tend to lean with Joey, the wording works for me and changing it 
>>> would feel arbitrary and break the current grammatical 'symmetry' as in
>>> weapon = Just sword 
>>> vs 
>>> weapon = Something sword
>>>
>>> On Tuesday, 22 November 2016 08:19:21 UTC+11, Oliver Searle-Barnes wrote:
>>>>
>>>> I have to admit I did find `Just` very confusing when I first 
>>>> encountered it, as mentioned earlier in this thread it implies some kind 
>>>> of 
>>>> limitation which doesn't match the semantics of Maybe at all. That said, 
>>>> it 
>>>> was one of those little oddities that very quickly become second nature, 
>>>> just wanted to point out that it is a slight bump in the road for 
>>>> newcomers.
>>>>
>>>>
>>>> On Monday, 21 November 2016 18:34:05 UTC+1, Noah Hall wrote:
>>>>>
>>>>> Has anyone actually encountered anyone being confused by the names? I 
>>>>> haven't. I think this a solution to a problem that doesn't exist. 
>>>>>
>>>>> On Mon, Nov 21, 2016 at 6:15 PM, Will White <will.n...@gmail.com> 
>>>>> wrote: 
>>>>> > I think that’s because you already know what Just means. I don’t 
>>>>> think it’s 
>>>>> > arbitrary though from an accessibility point of view. Some or None 
>>>>> is easier 
>>>>> > for newcomers to understand than Just or Nothing, especially as Some 
>>>>> isn’t 
>>>>> > misleading the way Just is, as Andrew described well. 
>>>>> > 
>>>>> > On 21 Nov 2016, at 17:05, Joey Eremondi <joey.e...@gmail.com> wrote:
>>>>>  
>>>>> > 
>>>>> > Honestly, these choices seem pretty arbitrary. Everyone has a 
>>>>> preference. ML 
>>>>> > uses Some/None, Haskell uses Just/Nothing. Some people find Something
>>>>>  
>>>>> > intuitive, some don't. 
>>>>> > 
>>>>> > Given that the choices is (mostly) arbitrary, it seems best to stic

[elm-discuss] Re: Proposal: import groups

[Robin Heggelund Hansen]

Hmm. What makes it less clear? It essentially just removes the need to 
write `import` for every line.

mandag 21. november 2016 03.07.29 UTC+1 skrev Daniel Walker følgende:
>
> I was referring to your proposal. Josh's proposal is clearer but still not 
> as clear as what we have today 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 readable than what we currently have to me.
>>>
>>> On Saturday, November 19, 2016 at 11:38:16 PM UTC-7, Robin Heggelund 
>>> Hansen wrote:
>>>>
>>>> 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 (if any). Doing anything else fails 
>>>> to 
>>>> compile. Elm does, however, have syntax that allows specifying imports on 
>>>> different lines. What if imports had to be grouped together, just like 
>>>> exposed types/variables/functions?
>>>>
>>>> In Go, imports can be grouped together like this:
>>>>
>>>> ```
>>>> import (
>>>> "module/a"
>>>> . "module/b"
>>>> name "module/c"
>>>> )
>>>> ```
>>>>
>>>> I think this would make a nice addition to Elm as well. I propose to 
>>>> change the current import syntax so that there can only be one import 
>>>> statement per module, and that it looks like the following:
>>>>
>>>> ```
>>>> imports (
>>>> Module.A,
>>>> Module.B exposing (..),
>>>> Module.C as Name
>>>> )
>>>> ```
>>>>
>>>

-- 
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.

[elm-discuss] Re: Proposal: import groups

[Robin Heggelund Hansen]

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:
>>
>> 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 (if any). Doing anything else fails to 
>> compile. Elm does, however, have syntax that allows specifying imports on 
>> different lines. What if imports had to be grouped together, just like 
>> exposed types/variables/functions?
>>
>> In Go, imports can be grouped together like this:
>>
>> ```
>> import (
>> "module/a"
>> . "module/b"
>> name "module/c"
>> )
>> ```
>>
>> I think this would make a nice addition to Elm as well. I propose to 
>> change the current import syntax so that there can only be one import 
>> statement per module, and that it looks like the following:
>>
>> ```
>> imports (
>> Module.A,
>> Module.B exposing (..),
>> Module.C as Name
>> )
>> ```
>>
>

-- 
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.

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

[Robin Heggelund Hansen]

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 hinting that it's something other than just the counterpart 
> to Nothing. I don't know the reasons behind its naming, but I think I would 
> prefer Something, as in "something or nothing". What do you think?
>

-- 
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.

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

[Robin Heggelund Hansen]

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 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 was true of Elm as well, the example above would be the 
> same as:
>
> ```
> import Module.B
> import Module.C
> {- etc. -}
> ```
>
> For me, having this in Elm would remove most of my uses of the `as` 
> keyword. If my other import proposal was also implemented, import handling 
> would be simpler, at least for me, without sacrificing readability.
>
> What do people think?
>

-- 
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.

[elm-discuss] Proposal: Shorter qualified imports

[Robin Heggelund Hansen]

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 was true of Elm as well, the example above would be the 
same as:

```
import Module.B
import Module.C
{- etc. -}
```

For me, having this in Elm would remove most of my uses of the `as` 
keyword. If my other import proposal was also implemented, import handling 
would be simpler, at least for me, without sacrificing readability.

What do people think?

-- 
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.

[elm-discuss] Proposal: import groups

[Robin Heggelund Hansen]

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 (if any). Doing anything else fails to 
compile. Elm does, however, have syntax that allows specifying imports on 
different lines. What if imports had to be grouped together, just like 
exposed types/variables/functions?

In Go, imports can be grouped together like this:

```
import (
"module/a"
. "module/b"
name "module/c"
)
```

I think this would make a nice addition to Elm as well. I propose to change 
the current import syntax so that there can only be one import statement 
per module, and that it looks like the following:

```
imports (
Module.A,
Module.B exposing (..),
Module.C as Name
)
```

-- 
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.

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

[Robin Heggelund Hansen]

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 that get triggered on 
> mousemove. I do not have any speed issue now so I am not trying to optimize 
> things that do not need optimization right now ^^. But this work made me 
> curious about how code is optimized in elm. In this blog post [1] 
>  Evan says that Elm 
> uses requestAnimationFrame by default. I wonder what this means. Does this 
> mean that all events are "filtered" to trigger only once per frame ? (for 
> example the mousemove?) or is it specific to virtualdom since this post was 
> about that. If not, what do you think would be a suitable strategy?
>
> [1] http://elm-lang.org/blog/blazing-fast-html-round-two
>

-- 
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.

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

[Robin Heggelund Hansen]

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 think flippantly dismissing anyone who abandons Elm as having a 
> tenuous connection is fair.  A lot of existing users, especially long time 
> users who when they started, may have done so because of the 'niceties' 
> like this, and they are now being slowly eroded. Maybe you could say they 
> are now better off going to purescript/websharper/whatever, but they are 
> also the guys actually using Elm to get real stuff done, and  often act as 
> evangelists /'recruiters' to bring more newcomers to Elm in the first 
> place. Simplifying Elm to attract the JS hordes may be a good way to grow 
> the user base, but it will come at the expense of some of these guys 
> leaving, which is a bit sad. 
>
> As usual, it's a tricky (but hopefully correct) BDFL decision for the good 
> of the language ecosystem and usage, but not a clear slam-dunk for the 
> language itself according to a lot of people.
>
> On Tuesday, 15 November 2016 13:47:43 UTC, Max Goldstein wrote:
>>
>> If someone was so tenuously commuted to Elm that this syntax removal 
>> drives them away, oh well.
>>
>>
>>

-- 
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.

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

[Robin Heggelund Hansen]

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` instead of 
`import Array`.
3) You're now using new elm arrays :)

The most important part of the new implementation is that it's more stable. 
All the known issues with the core arrays should be fixed in this 
implementation. That being said, it could very well be the case this 
implementation has other bugs.

I would love for people to try this out :)

-- 
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.

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

[Robin Heggelund Hansen]

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:
>
>
>
> بتاريخ الأحد، 13 نوفمبر، 2016 1:53:05 ص UTC+2، كتب أحمد حبنكة:
>>
>> I was reading the elm-dev list and I knew that elm 0.18 removed the range 
>> syntax, so code like this : 
>> [2..3]
>> won't work anymore.
>>
>> I want to know what are the foundations behind this decision ?
>> hmmm if it is "can't find it in the documentation" then fix the 
>> documentation, when the documentation is unfixable for this feature I think 
>> it may be better to remove it, was this the case ?  
>>
>
> The syntax of ranges is not specific to haskell, ruby and some other 
> languages implement it.  
>
> Now for the fact that most new coders ask "what's this" or "how do I make 
> a range" maybe the problem lies in the docs not in the feature itself.  
>
> still if it is confusing for most beginners then I agree it's probably 
> better to remove it although I find hard to believe that this feature is 
> hard to understand !! 
>

-- 
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.

[elm-discuss] Re: Parallelism support in Elm

[Robin Heggelund Hansen]

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 JS (and in result Elm) is to do 
> concurrency instead of parallelism but I think in the future web workers 
> might become as idiomatic as AJAX or Promises.  
>
> Given that JS does now support it via web workers, I was wondering what 
> are the plans for adding Parallelism to Elm ?
>
>
>
>

-- 
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.

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

[Robin Heggelund Hansen]

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 to being more syntax to learn, and harder to discover through 
documentation, it's also not as flexible as a regular function. Then you 
also have to ask yourself if you use ranges enough that it actually 
warrants its own syntax.

søndag 13. november 2016 00.53.05 UTC+1 skrev أحمد حبنكة følgende:
>
> I was reading the elm-dev list and I knew that elm 0.18 removed the range 
> syntax, so code like this : 
> [2..3]
> won't work anymore.
>
> I want to know what are the foundations behind this decision ?
>
>

-- 
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.

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

[Robin Heggelund Hansen]

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 
to Elm, and don't have any problems training those people up.

As for longevity, the company where the creator and lead-developer of Elm 
works, No Red Ink, has 55000 lines of Elm in production, and are pretty 
reliant on that technology. I don't see Elm going away any time soon.

So to recap:
1. Elm is simple to learn. It was made for learning. Hiring people that 
don't know Elm shouldn't be a huge problem. (go through the syntax, how 
much is it really compared to ES2016?)
2. The company behind Elm has a huge stake in it's continued development, 
and they're not going anywhere soon.

lørdag 5. november 2016 23.01.42 UTC+1 skrev Zacqary Adam Xeper følgende:
>
> Hey Elmos,
>
> I've finally gotten an opportunity to pitch Elm to my fairly large dev 
> team. I feel like I'm prepared to make the case for it against a lot of 
> objections: i.e. how will we learn yet another programming language, do we 
> really need something that never throws exceptions, etc. etc.
>
> The one thing I'm not really sure I'm prepared to answer is how I can be 
> sure that Elm isn't just another CoffeeScript or Dart, and in 2 or 3 years 
> we'll have an impossible time hiring anyone who knows how to use it because 
> everyone's going to go back to JavaScript.
>
> How do I convince Elm skeptics that this thing is here to stay? I can do a 
> great job of incorporating a small bit of Elm code into our stack to show 
> how great it is, but they won't even let me merge it into prod unless I can 
> make the case for its longevity.
>
>

-- 
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.

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

[Robin Heggelund Hansen]

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 
difference here, it's easy enough to point it out. But given the proper 
context it can be easy to confuse one with the other, especially when the 
compiler (or the spell checker) don't point it out for you.

tirsdag 25. oktober 2016 17.36.02 UTC+2 skrev Rupert Smith følgende:
>
> On Tuesday, October 25, 2016 at 1:45:35 PM UTC+1, James Hamilton wrote:
>>
>> I agree with your sentiment in principle. I suppose the underlying 
>>> question is whether or not this is actually going to be such a benefit to 
>>> future users of elm that it would be worth inconveniencing current users 
>>> who want to upgrade. Personally I'm quite comfortable with foldr and foldl 
>>> but I understand the foldLeft and foldRight are more expressive. 
>>>
>>
>> I used to use ember and its constant churn drove me to find an 
>> alternative which led me to elm. Not that the community elm behaves 
>> anything like ember in this regard, but still this blog post 
>> 
>>  rather 
>> sums up the danger of making a lot of inconvenient changes for apparently 
>> abstract reasons. 
>>
>
> Also, have you ever actually encountered a bug which was caused by 
> misreading foldl for foldr or the other way around? I really don't find it 
> hard to tell them apart. 
>

-- 
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.

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

[Robin Heggelund Hansen]

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 2016 14.45.35 UTC+2 skrev James Hamilton følgende:
>
> I agree with your sentiment in principle. I suppose the underlying 
>> question is whether or not this is actually going to be such a benefit to 
>> future users of elm that it would be worth inconveniencing current users 
>> who want to upgrade. Personally I'm quite comfortable with foldr and foldl 
>> but I understand the foldLeft and foldRight are more expressive. 
>>
>
> I used to use ember and its constant churn drove me to find an alternative 
> which led me to elm. Not that the community elm behaves anything like ember 
> in this regard, but still this blog post 
> 
>  rather 
> sums up the danger of making a lot of inconvenient changes for apparently 
> abstract reasons. 
>

-- 
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.

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

[Robin Heggelund Hansen]

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 not stable.
>>
>
> The question is whether different naming for "foldl" and "foldr" would 
> bring enough benefits to be worth all these (temporary) drawbacks.
> So:
>
>- "foldLeft" and "foldRight" are easier to keep apart/ more readable - 
>regardless of someone's previous language
>- "reduce" and ("foldr" or nothing or something else) would be more 
>familiar to people coming from JS (and possibly other languages too)
>
> My own background is JS, so "reduce" is familiar. 
> But at the same time, I use "foldl" way more often in Elm than I ever used 
> "reduce" in JS, and in very different ways.
>
> What I see as a structural drawback to "foldLeft" and "foldRight" is the 
> length of the function names: shorter names are better, and (for me at 
> least) the extra characters in the function names do not give me any 
> relevant info or benefits.
> 90% of the time I use any fold, my output is the same in both directions. 
> (like .sum or .maximum etcetera). 
> I have never used "foldr" (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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robin Heggelund Hansen]

I've done a lot of library work lately where Cmds and Subs haven't been a 
part of the project, so yes, in a project where the main way to run your 
code is through fuzz tests, breakpoints would be immensively helpful.

That being said, having a Debug.breakpoint function is just a convenience, 
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 Hansen <
> skinn...@gmail.com > wrote:
>
>> Elm, as great as it is, doesn't save you from debugging every once in a 
>> while. The one option we have now, is logging. Logging is great, but it can 
>> quickly become painful in loops. Since Elm compiles to a single JS file 
>> with long mangled names, setting a breakpoint from the code would sometimes 
>> be the simplest way to properly debug your code. The generated JS isn't 
>> that hard to understand either, it's a series of vars and function calls 
>> for the most part.
>>
>> lørdag 22. oktober 2016 13.49.52 UTC+2 skrev John Orford følgende:
>>>
>>> It never occurred to me to debug the generated JS... can 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.
>>>>
>>>> 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-lang/core, called breakpoint. It would work like the identity 
>>>> function, 
>>>> but also include the `debugger;` statement, causing a breakpoint to happen 
>>>> when the browsers dev-tools are open.
>>>>
>>>> used like:
>>>>
>>>> ```
>>>> faultyFunction a b =
>>>>   let
>>>>  _ = Debug.breakpoint ()
>>>>   in
>>>> a + b
>>>> ```
>>>>
>>>> Granted, this would cause a breakpoint to happen in the actual 
>>>> Debug.breakpoint function, but since that function is very small, stepping 
>>>> out of it is no big deal. The only other option I can think of is compiler 
>>>> support, but I'm unsure how hard this would be to include.
>>>>
>>>> Opinions?
>>>>
>>>> -- 
>>>> 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...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.

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

[Robin Heggelund Hansen]

Define "other functional languages". Clojure(script) doesn't have fold, but 
reduce. F# has fold and foldBack.

What other languages do is, however, besides the point. The question is, 
what is more readable? It's easier to confuse foldl with foldr than it is 
to confuse fold(Left) with 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 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.
>>
>> In the same spirit, I propose that we change the name of foldl to 
>> foldLeft, and the name of foldr to foldRight. The difference between foldl 
>> and foldr isn't to spot at a cursory glance. foldLeft is also more 
>> self-describing than foldl, it also matches what I say when I read foldl 
>> aloud while explaining code to others.
>>
>> FYI: Scala has also called their functions foldLeft and foldRight.
>>
>> I think this proposal would benefit both seasoned and new Elm developers.
>>
>
> -1 from me. foldl and foldr are so commonly in use in other functional 
> languages that they are an acceptable short hand. Who cares what Scala does.
>

-- 
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.

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

[Robin Heggelund Hansen]

Elm, as great as it is, doesn't save you from debugging every once in a 
while. The one option we have now, is logging. Logging is great, but it can 
quickly become painful in loops. Since Elm compiles to a single JS file 
with long mangled names, setting a breakpoint from the code would sometimes 
be the simplest way to properly debug your code. The generated JS isn't 
that hard to understand either, it's a series of vars and function calls 
for the most part.

lørdag 22. oktober 2016 13.49.52 UTC+2 skrev John Orford følgende:
>
> It never occurred to me to debug the generated JS... can 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.
>>
>> 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-lang/core, called breakpoint. It would work like the identity function, 
>> but also include the `debugger;` statement, causing a breakpoint to happen 
>> when the browsers dev-tools are open.
>>
>> used like:
>>
>> ```
>> faultyFunction a b =
>>   let
>>  _ = Debug.breakpoint ()
>>   in
>> a + b
>> ```
>>
>> Granted, this would cause a breakpoint to happen in the actual 
>> Debug.breakpoint function, but since that function is very small, stepping 
>> out of it is no big deal. The only other option I can think of is compiler 
>> support, but I'm unsure how hard this would be to include.
>>
>> Opinions?
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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.

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

[Robin Heggelund Hansen]

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-lang/core, called breakpoint. It would work like the identity function, 
but also include the `debugger;` statement, causing a breakpoint to happen 
when the browsers dev-tools are open.

used like:

```
faultyFunction a b =
  let
 _ = Debug.breakpoint ()
  in
a + b
```

Granted, this would cause a breakpoint to happen in the actual 
Debug.breakpoint function, but since that function is very small, stepping 
out of it is no big deal. The only other option I can think of is compiler 
support, but I'm unsure how hard this would be to include.

Opinions?

-- 
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.

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

[Robin Heggelund Hansen]

If you get the chance, try to change the generated code from the elm 
compiler and change statements that performs a `'ctor' in obj` tests. 
Change them to `typeof obj.ctor === 'undefined'` or some such. There is one 
in the eqHelp function (called by `=`) and one in the toString function.

The reason this will fail with google closure is that the ctor property is 
renamed when used with advanced optimizations, and so 'ctor' checks will 
fail.

torsdag 20. oktober 2016 21.42.55 UTC+2 skrev OvermindDL1 følgende:
>
> I know it fails on our large Elm project at work, we have to run with 
> standard optimizations of the Google Closure compiler, but I did not 
> research in to far since generated code is not code that I control and I 
> needed to get things done.  If I get time I'll try to run it again and get 
> some data on it.
>
>
> On Thursday, October 20, 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 submit a PRs to 
>> fix the problem.
>> Pretty sure I've figured out what the problems are, but I need to 
>> replicate my success on larger projects than the few test cases I've made.
>>
>

-- 
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.

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

[Robin Heggelund Hansen]

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 element) and replaces the "cons" 
> operator with a function that takes an element and a partial result.  This 
> is consistent with other ways to define generalized folds over recursive 
> data structures.  For example for trees you can replace the leaf node with 
> a constant and replace the internal node with a binary function.  The key 
> idea here is that fold directly reflects the natural structure of the 
> underlying data structure.  ie, the way you would draw a picture of the 
> underlying data structure is exactly the picture of the execution order. 
>  If we are consistent with this, then fold will be defined for lists to be 
> the same as foldRight for lists.  For more detailed exposition to motivate 
> this definition, see the paper "Merging Monads and Folds for Functional 
> Programming", by Meijer and Jeuring. 
> 
>
> One could also define a fold (as scala does) to be not-necessarily-linear 
> -- the execution order is unspecified and left up to the implementer.  So 
> in scala, a fold can split up a list into many pieces (sublists) and 
> process the sublists in parallel, and then fold them up to obtain the final 
> answer.  In this case, it is not necessaria foldLeft or a foldRight.  It 
> could actually be a fold-from-the-middle or even 
> fold-from-many-places-in-the-middle.  In order to make sure the answer is 
> well-defined, the folding operator is required to be associative.
>
> IMO it would be a good idea to avoid confusion with these alternative 
> semantics by not reusing the name "fold" at all, or else adopting one of 
> the conventional meanings (if we can agree what the most common meaning is).
>
> On Thursday, October 20, 2016 at 11:32:12 AM UTC-4, Max Goldstein wrote:
>>
>> Normally I'm opposed to syntax or name changes. But I think this or some 
>> variation is a good idea. (Maybe foldl becomes fold, since it's usually the 
>> one you want.)
>>
>> That said, it's all subject to Evan's approval. 
>>
>

-- 
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.

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

[Robin Heggelund Hansen]

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.

In the same spirit, I propose that we change the name of foldl to foldLeft, 
and the name of foldr to foldRight. The difference between foldl and foldr 
isn't to spot at a cursory glance. foldLeft is also more self-describing 
than foldl, it also matches what I say when I read foldl aloud while 
explaining code to others.

FYI: Scala has also called their functions foldLeft and foldRight.

I think this proposal would benefit both seasoned and new Elm developers.

-- 
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.

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

[Robin Heggelund Hansen]

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 people to help and be helped! 
>
> Here's a link for anyone unfamiliar -> http://elmlang.herokuapp.com/
>

-- 
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.

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

[Robin Heggelund Hansen]

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 priority, as we already have minifiers that provide this service for us. 
This also means that there is no reason to include a 'prod' or 'dev' mode 
to the compiler (at least not for this) as a 'prod' mode is simply adding a 
minifier step to your build configuration.

The elm compiler already outputs JS in a way that makes it very simple to 
remove dead code, and to minify well. The only 'problem' with the current 
way of things, is that the elm-runtime is written by hand, and thus not 
written in such a way that makes it easy to minify well and remove dead 
code. Re-writing more of the elm-runtime in elm should mitigate this 
further. In fact, I believe Elm already beats other languages like 
ClojureScript quite well in size, even though CLJS uses google closure for 
minification. The main advantage cljs has over Elm, is that cljs' runtime 
is written in cljs.

I also don't believe that elm-html should be a part of the standard 
library. While it might makes sense today, it makes less sense in the 
distant feature when someone has come up with a new, revolutionary and 
soon-to-become de-facto HTML library. It also wouldn't make sense if Elm 
ever becomes a backend or scripting language. It should be noted however, 
that my interpretation of what a standard library is, is a library that 
provides functions you would likely use in any app, and which are unlikely 
to do better any other way. The current standard library is, IMHO, fine the 
way it is when it comes to scope, while there are certain functions I would 
love to add to certain modules (like List.find). You're interpretation may 
be different. In any case, there is no reason to discuss the size and scope 
of the standard library here, I just thought I would voice my opinion that 
just because we have DCE, that doesn't mean should be uncritical with what 
we put in the standard library.

I would also like to point out that while optimizing for Google Closure is 
a good thing (tm), it should not come at the cost of hampering other 
minifiers like UglifyJS. UglifyJS already removes all dead code (except 
dead code in native code) quite well in my applications, and I would love 
for that to still be a thing in the future without swapping out Uglify with 
a Java application.

So yeah, my 2 cents essentially boils down to:
1) Move more runtime code from native to pure elm.
2) Explore a way to make native code as easy to minify/DCE as compiled Elm 
code.
3) Should the Elm compiler ever support another target in the future, spend 
resources on DCE.

torsdag 16. oktober 2014 16.12.46 UTC+2 skrev Laszlo Pandy følgende:
>
> Currently elm-runtime.js works like any JavaScript library: you include it 
> with your page and your generated Elm code use the exposed functions. In 
> fact you could even use it from hand-written JS code. But a language 
> runtime is not the same thing as a JS library.
>
> Recently many people have brought up two issues:
> - should elm-html be in the standard library?
> - why is elm-runtime.js so big?
>
> And here are two stories which indicate which direction Elm should be 
> heading in:
> 1. Since Haxe started, they were always concerned about compiled JS size. 
> They believed that JS devs wouldn't switch to Haxe if a hello world was 10K 
> of JS. So they kept the standard modules small. There was a class String 
> with a few functions, and StringTools[1] with many more. StringTools would 
> not be included if you didn't import it.
>
> Later on, Haxe implemented function-level dead code elimination. After 
> that it didn't matter how big String was. All the parts you didn't use 
> would be deleted from your output. Now StringTools is just API baggage that 
> shouldn't exist.
>
> [1] http://api.haxe.org/StringTools.html
>
> 2. Just like Elm's runtime is written in JS, Go's runtime is written in C. 
> But how there is a big project rewrite much of it in Go[2] to take 
> advantage of the compiler's stack layouts. But even if we are talking about 
> Elm and JS, there would be many advantages to having most of the runtime 
> written in Elm:
> - inlining, and other optimizations
> - function-level dead code elimination
> - less code maintenance (ie. if Elm changes its data structures)
>
> [2] 
> http://dave.cheney.net/2014/09/01/gos-runtime-c-to-go-rewrite-by-the-numbers
>
> What we see is:
> - dead code elimination decouples the runtime size from the API design. 
> This is a good thing
> - the runtime should be a collection of functions, not a self-contained 
> library to enable dead code elimination
> - the compiler has more flexibility if more functions are in Elm instead 
> of JS
>
> The direction Elm should be heading in is to have no separate 

[elm-discuss] Re: Record update syntax

[Robin Heggelund Hansen]

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
>   something = model.something
> in
>   { model | something = { something | more = 42 } }
> ```
> Excepting the let/in part because Elm does not support an expression as 
> the first argument (`model` and `something` in these cases) for 
> I-have-no-clue-reason, and another language I work often in is Elixir, its 
> syntax for the above would be similar:
> ```elixir
>   %{ model | something: %{ model.something | more: 42 } }
> ```
>
> However, that is painful, so Elixir has a couple of helper functions that 
> simplify that kind of work, let me demonstrate, this does the same as the 
> above:
> ```elixir
>   put_in models, [:something, :more], 42
> ```
> And you can go arbitrarily deep and it returns a new model with the path 
> altered to the given value as necessary.  Elixir also has lispy macros so 
> you can also use the above function via:
> ```elixir
>   put_in models.something.more, 42
> ```
> Basically using 'read' syntax to specify the path, but it gets expanded to 
> the above at compile-time.  It also supports not only records but also maps 
> (dicts in elm), lists (also lists in elm) and anything else that follows 
> the Access protocol (a set of functions of certain types to do basic 
> functions), but those are the default.
>
> It has extra features like this, say `model.something` is a `List Int` in 
> elm parlance:
> ```elixir
> put_in model, [:something, Access.all], 42
> ```
> This will set any and all values in the list at model.something to 42, not 
> terribly useful, however it has a lot more functions as well, such as (I 
> want to use more 'elmy' syntax, so I will now use things like `.something` 
> instead of `:something` and no commas between arguments, only in tuples and 
> lists and such):
> ```elixir
> -- Where model = { something : Dict String (List Int) }
> ( oldValue, newModel ) = get_and_update_in model [ .something, "joe", 
> Access.at(0) ] (\oldValue -> let oldValue = Maybe.withDefault 0 in ( 
> oldValue, Just (oldValue+1) ))
> ```
> This will update a value in and let you return a value (anything you wish) 
> within a tuple.  This one will access `Dict.get "joe" model.something` and 
> get the returned list, accessing the first element (`at` for lists, `elem` 
> for a tuple index starting at 0 as well), and the called passed in function 
> returns a tuple where the first element is the first element of the 
> returned tuple and the second element is what the thing at the path will be 
> updated to, so this case will return the `oldValue+1` if it existed, if it 
> did not then it returns 1 due to the `withDefault 0`.
>
> More functions it adds are:
> ```elixir
> -- Where model = { something : Dict String (List Int) }
> value = get_in model [ .something, "joe", Access.at(2) ] -- Returns the 
> value at the path
>
> values = get_in model [ .something, Access.all, Access.at(2) ] -- Returns 
> all of the values 2nd values in the lists in all the values of the 
> dictionary as a list if they exist, else they are skipped
>
> pop_in model [ .something, Access.all, Access.at(2) ] -- Removes the 
> element in the list at position 2 in all the dictionary values if it 
> exists, if it does not exist then it skips it
>
> update_in model [ .something, Access.all, Access.at(2) ] (\oldValue -> 
> Just (( oldValue |> Maybe.withDefault 0 ) + 4)) -- Updates a value(s) 
> in-place
> ```
> Along with macro's for the read-format pathing, which is not needed here.
>
> The keylist (the `[ .something, Access.all, Access.at(2) ]` in the last 
> example) can also take functions, whatever they return (empty list, 
> single-element list, multiple-element list, etc...) will be what is used 
> and what is set back.
>
>
> *Thus*, what would be thought of Elm adding in functions like these 
> (HKT's might be needed, not thought through the implementation yet, only 
> the API):
> ```
> type Access
>   = All
>   | At Int
>   | Elem Int
>   | Key recordKeyType {- Whatever recordKeyType might be as an indicator 
> for a key on a record -}
>   | DictKey dictKeyType
>   | Fn (EnumerableType -> EnumerableType) {- This is why I think HKT's 
> might be needed, or special caseing in the compiler -}
>
> -- You'd need some kind of EnumerableType as well, no doubt opaque or 
> something, or need HKT's, probably need HKT's in general, Elm really badly 
> needs HKT's...
>
> {-| Get a value calculated from the old value and set a new value 
> simultaneously -}
> getAndUpdateIn
>   : List Access
>   -> (Maybe valueType -> ( retValue, Maybe valueType ))
>   -> EnumerableType
>   -> ( List retValue, EnumerableType )
>
>
> {-| Gets a value from an access path -}
> getIn
>   : List Access
>   -> EnumerableType
>   -> List retValue
>
>
> 

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

[Robin Heggelund Hansen]

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 more level as you go down the list. 
> Sometimes it crashes and busy spins Emacs too.
>
> Something better would be appreciated. :-)
>

-- 
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.

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

[Robin Heggelund Hansen]

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 probably be different if I didn't keep css in .css 
files). That's not to say that I'm representative of Elm developers at 
large, or that Color isn't useful, I just don't think it has a place in the 
core package. One could argue that Elm is about frontend development, which 
has to do with UI, which again has use of Color. Sure. But Html and Http, 
the perhaps most important modules for frontend development are not in the 
core package, so why should Color be there?

* What are the downsides?
The core package is required in every project, this means that core is 
compiled in every single Elm application. One could argue that the core 
package should be as small as possible, because Elm developers shouldn't 
pay for what they don't use. One could also argue that having Color in core 
poses an increased maintenance burden on the core developers, who are 
already overworked as it is. While true, none of these arguments pose a big 
deal, because:

1. Color is probably (not tested) not so big that it has a noticeable 
effect on compile times.
2. Unused code is easily stripped away by a minifier like UglifyJS.
3. The Color module is pretty complete, and I don't see it changing much in 
the future, so the maintenance "burden" is probably very small.

* What are the upsides?
It's probably valuable to have a de-facto Color module for Elm (again, I 
don't make use of it so I don't know). On the other hand, all other modules 
which would be good to have as the "one, true" module are external modules 
(websockets, http, html...).

* Do you have a paper thin argument?
Sure. Having modules in core that don't fit the "core concern" description 
opens the door for discussing adding more modules which also don't match 
the "core concern" description. Evan and other core developers are pretty 
good at saying no though, so I'm not worried about this.

* What would I propose?
I propose that Color should be moved from the core package and placed in a 
package of its own. There are advantages to doing this (though marginal) 
and I believe it outweighs the disadvantages (those who use Color have to 
add a line to their elm-package.json). It's not an important change, and 
shouldn't be a priority, but I still think it should be made.

What do other people think?

-- 
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.

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

[Robin Heggelund Hansen]

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 
than my Javascript React apps and previous Clojurescript apps (which uses 
Google Closure as the compiler).

I'm unconvinced that dead code removal in the compiler itself would make a 
huge difference when minified.

tirsdag 9. august 2016 05.59.22 UTC+2 skrev Austin Horning følgende:
>
> Using the latest version of elm, even the simplest of apps come out to 
> greater than 7000 lines and 100kb of generated javascript. This seems to be 
> because all imported libraries are included regardless of whether or not 
> they are used, and upon digging into the generated code, it would seem that 
> it would not be completely unreasonable to leave about half of that code 
> unused even in larger projects. If elm employed some sort of pruning 
> strategy to find and remove unused code at compile time, then thousands of 
> lines could be removed from the generated javascript. There are a couple 
> ways to go about this as far as I can see.
>
> The first would be to have a sort of lazy including strategy, which would 
> build a sort of dependency tree as function calls are detected. This method 
> has the advantage of being quick and more aware of the elm compilation 
> process(being a part of the basic compilation process), which could lend to 
> it being more extensible.
>
> The second strategy is to build the javascript as it is already done. Then 
> make a few passes with another tool and remove dead code from the file in 
> that fashion. This method might be slower, but it would not interfere with 
> the current compilation process.
>
> Don't get me wrong. 100 kb is not that bad, and I certainly would not see 
> this as a super high priority. The possibility is that if it could be 
> incredibly small at compile time, it would be incredibly practical to embed 
> elm apps everywhere(even multiple in one page, potentially). If the 
> compiler was responsible, it would likely be much more efficient than 
> UglifyJs(given the nature of JS) at dead code removal and the option to run 
> through Uglify is still available. If I am a business and you tell me that 
> I can save 90% on CDN costs and cut page load time in half(just in terms of 
> download time) by switching to elm, that could be an incredibly convincing 
> argument. 
>
> Has anyone considered implementing something like this?
>

-- 
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.

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

[Robin Heggelund Hansen]

Yeah, I assumed this would be a preference thing. However, for me the 
question is never "What does this module expose" but "is this function 
private and public?" and the fact that I have to go to the top of the file 
and scan a list to see if that's the case is a minor inconvenience when it 
could have just been a part of the function signature, as is the case in 
most other languages.

OvermindDL1 suggestion wasn't that far from what I imagined, but I'll 
provide some more examples anyway.

```elm
expose
type alias Person =
  { name : String
  , age : Int
  }

expose(..)
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 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".
>>
>>
> Just for the record, I like this feature.
> I prefer to have my list of exposed functions in one convenient place 
> rather than scattered throughout the file. 
>

-- 
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.

[elm-discuss] public keyword instead of exposing

[Robin Heggelund Hansen]

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 default for top-level vars/functions to be public, 
and you need to use a "private" keyword to restrict access. Since Elm 
currently explicitly exposes functions at the top, I thought it would be 
good to propose a public keyword instead.

I assume that this is largely a preference thing, but I think it's worth a 
discussion. What do people think of having a public/private keyword to 
restrict access to variables/functions in modules, instead of the exposing 
keyword we have today?

-- 
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.

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

[Robin Heggelund Hansen]

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 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.

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

[Robin Heggelund Hansen]

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 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.

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

[Robin Heggelund Hansen]

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 from those in elm-core with a stable Array 
implementation, and that equality (==) works as you would expect.

Read more at 
http://package.elm-lang.org/packages/Skinney/collections-ng/1.0.0

-- 
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.

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

[Robin Heggelund Hansen]

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 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.

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

[Robin Heggelund Hansen]

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 workers.

That being said. Why do you have "hundreds of thousands of nodes" in the 
UI? Elm can be sufficiently faster than React out of the box (due to 
immutable datastructures and lazy, though you can reap the benefits of this 
with React as well), but it seems to me that the real problem is the fact 
that you're trying to render way to 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.