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

[Matthieu Pizenberg]

On Monday, June 12, 2017 at 7:15:59 AM UTC+8, Robin Heggelund Hansen wrote:
>
> I've been doing some thinking on how to improve Arrays in Elm.
>

Thanks alot for this work on an alternative array implementation! It's 
awesome! It's one of some challenges to use elm for my needs (scientific 
programming), with blocking UI on long computation, and handling natively 
some binary data types (eg. for image manipulations).

A few words regarding your questions:

1) Can the benchmarks be improved?
Could there be one example at a very different scale? For example, I'm 
manipulating scientific data for my work which tend to hold many thousands 
values (like images). Would be nice to see how the different 
implementations scale.
>From the results point of view, it's very important to have an idea of the 
standard deviation of statistical results (or box plots, or similar). If a 
value oscilates between 10 and 100, there is no point giving only it's 
mean or median value.

2) Are people getting similar results as I have?
Not tested yet but starred your repo to come back later. I've been pausing 
my elm coding lately.

3) Has anyone encountered performance issues with lists, and if so, do you 
have an example?
No, not for typical small size lists used here and there.

4) Have you been confused by Lists and Arrays? What could be improved to 
reduce that confusion?
No, but I've been needing to do some gymnastic between lists, arrays and 
dicts for different features specific to each. 

-- 
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 to manage long running computations in Elm?

[Matthieu Pizenberg]

On Wednesday, June 7, 2017 at 4:08:37 PM UTC+8, Rupert Smith wrote:
>
> On Tuesday, June 6, 2017 at 3:20:42 PM UTC+1, Rupert Smith wrote:
>>
>> The problem with long running computations in a single threaded UI is 
>> that they may cause the UI to block and become unresponsive for a period. 
>> Definitely not an acceptable user experience.
>>
>
Yep, totally agree with you. I also would love to be able to run some 
scientific computation, but the UI blocking is a stopper. 

-- 
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: Cascading ul and li with onClick

[David Legard]

Thank you both very much for these prompt and useful answers.

I went with Pi's suggestion simply because it involved less rewriting.

It worked straight out of the box :)

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

[Robert Woodhead]

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.

Re: [elm-discuss] Add css classes to existing html nodes

[Pi]

Hi Eike!
Have you had a look at the package pablohirafuji/elm-markdown? It's a pure 
Elm implementation of a Markdown parser where you can customize how HTML 
gets rendered.
See https://github.com/pablohirafuji/elm-markdown#customization. 
I'm not sure whether the lib supports tables at all since they aren't 
mentioned anywhere in the docs.

Anyway, give it a try!

Am Freitag, 9. Juni 2017 23:04:17 UTC+2 schrieb eike.k...@gmail.com:
>
> Hello Peter,
>
> thank you very much for your reply and example! I think option 2 doesn't 
> work for me, because I render user input and using “real” html in markdown 
> would defeat the purpose of creating tables with markdown. I also think, 
> the first option is sadly not working for me either. I'm sorry for not 
> being clear enough in my fist mail. I actually would like to add existing 
> classes (i.e. the semantic-ui classes "ui table") to all tables that were 
> generated by markdown. I don't want to mess with CSS myself (I'm not a 
> frontend dev and really bad at it I'm afraid).
>
> I guess I could run via Elm's command external javascript that finds all 
> tables within the markdown generated markup and then add these classes? I 
> hoped I could stay within Elm, though.
>
> Kind regards
> Eike
>
> Am Freitag, 9. Juni 2017 07:46:01 UTC+2 schrieb Peter Damoc:
>>
>> Hi Eike and welcome to Elm. 
>>
>> You could add some kind of a class to the div that's holding the markdown 
>> generated html and use that as a selector. 
>>
>> If you need something more complex than that, you might need to use html 
>> inside the markdown 
>>
>> Here is how to do both:
>> https://ellie-app.com/3r5tc7YsmmCa1/1
>>
>>  
>>
>>
>> On Fri, Jun 9, 2017 at 2:13 AM,  wrote:
>>
>>> Hallo Elm users,
>>>
>>> I'm creating my first app with Elm, and I'm really enjoying it. I'm 
>>> using the markdown package to generate html from user input. I'd like to 
>>> add css classes to certain (i.e. to tables) elements generated by this 
>>> library. I didn't find a way to do this. Is this possible?
>>>
>>> Thank you and regards
>>> Eike
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>

-- 
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: The way forward for Elm Arrays

[Peter Damoc]

On Mon, Jun 12, 2017 at 8:08 AM, Evan  wrote:

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


This might sound silly but wouldn't it be possible to have the same syntax
and let the programmer make the type concrete with usage?

array : Array
array = [1, 2, 3]

list : List
list = [1, 2, 3]

I'm asking because we already have a similar situation with `number` where
one ca declare both Int and Float the same way and the compiler is able to
figure out the actual type.

Maybe something similar can be done for dictionaries/records too:

record : Record
record = { field = "value"}

dict : Dict
dict = { key : "value"}

set : Set
set = {1,2}


The main advantage of a dictionary syntax like above is that it is familiar
for people coming from python/javascript.



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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 
> - This 
>made the Elm version significantly faster than before.
>- Get rid of List => Array => List conversion 
> - 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 
>  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 
>>  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 
>>  about optimizing 
>> List.map in OCaml a while ago, and Fred did some excellent work on this 
>> ! 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 
>>- Finger Trees  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 
>> changing it completely.
>>
>>
>> Anyway, exciting to see your work as always! And hopefully these ideas 
>> are helpful!
>> Evan
>>
>>
>>
>> On Monday, June 12, 2017 at 12:15:59 AM UTC+1, Robin Heggelund Hansen 
>> wrote:
>>>
>>> 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