Re: [elm-discuss] Mutually dependent types

[Wouter In t Velt]

Somewhat late, but there is a nice exposition on this by Evan over here:
https://github.com/elm-lang/elm-compiler/blob/master/hints/recursive-alias.md

-- 
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: Emphasizing /r/elm more

['Rupert Smith' via Elm Discuss]

On Wednesday, January 4, 2017 at 6:51:28 AM UTC, Richard Feldman wrote:
>
> I don't think that makes /r/elm the automatic best choice, but I do think 
>> it makes it worth a shot.
>>
>
I like how on google groups everyone tends to use their real name. On 
reddit most people post with nicknames. It feels more professional and 
appropriate to use real names - perhaps we'll meet each other in the flesh 
at a conference or something.

Will people moving to /r/elm do so using the same real name they use on 
here?

-- 
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: Emphasizing /r/elm more

[John Orford]

That struck me as well - I am going to switch my name to the real one, if I
can on Reddit...

On Wed, 4 Jan 2017 at 12:54 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Wednesday, January 4, 2017 at 6:51:28 AM UTC, Richard Feldman wrote:
>
> I don't think that makes /r/elm the automatic best choice, but I do think
> it makes it worth a shot.
>
>
> I like how on google groups everyone tends to use their real name. On
> reddit most people post with nicknames. It feels more professional and
> appropriate to use real names - perhaps we'll meet each other in the flesh
> at a conference or something.
>
> Will people moving to /r/elm do so using the same real name they use on
> here?
>
> --
> 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.
>

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

[Bob Zhang]

Hi Gordon,
  As you can see, BuckleScript already did a very good good job here, of
course, there are still places for improvement. To write extremely high
performance code, you should avoid creating a closure in a tight loop, here
you can lift the `nxtc` into the toplevel, in the future, we will do this
inside the compiler. Lets take further discussions off the list -- Hongbo

On Wed, Jan 4, 2017 at 1:17 AM, GordonBGood  wrote:

> Hi Bob/Hongbo,
>
> I've run into my first speed problem with BuckleScript:  When it decides
> it needs to form a closure of captured free binding(s), it creates a
> "function returning a function" with the outer function's arguments being
> the current state of the "pure" captured bindings, and the inner returned
> function the actual closure code.  When this happens anywhere near an inner
> loop, the code gets very slow, although sometimes the compiler is smart
> enough to infer that the closure is not necessary is when the binding value
> is an argument of an enclosing function; however, this does not happen for
> local `let` bindings even when they are in the same scope as the
> callee/caller sites.
>
> For example, the following bit-packed Sieve of Eratosthenes sieves over a
> range and returns the bit packed array of found primes over that range
> (odds-only.  It runs about five times slower than using imperative code
> for/while loops (top of a quarter million).  Code is as follows:
>
> let soe_loop top =
>   if top < 3 then Array.make 0 0 else
>   let ndxlmt = (top - 3) lsr 1 in
>   let cmpsts = Array.make ((ndxlmt lsr 5) + 1) 0 in
>   for loop = 1 to 1000 do (* do it many times for timing *)
> let pir = ref 0 in
> while !pir <= ndxlmt do
>   let pi = !pir in
>   let p = pi + pi + 3 in
>   let rec nxtc ci =
>   if ci > ndxlmt then () else
>   let w = ci lsr 5 in
>   cmpsts.(w) <- cmpsts.(w) lor (1 lsl (ci land 31));
>   nxtc (ci + p) in
>   let si = (p * p - 3) lsr 1 in
>   if si > ndxlmt then pir := ndxlmt + 1 else (
> if cmpsts.(pi lsr 5) land (1 lsl (pi land 31)) == 0 then
>   nxtc si
>   cmpsts
>
> where the outer `pi` loops are imperative and the inner `nxtc` loop is
> functional; this latter becomes the closure that captures the `p` value as
> you can see in the following generated JavaScript:
>
> function soe_loop(top) {
>   if (top < 3) {
> return Caml_array.caml_make_vect(0, 0);
>   }
>   else {
> var ndxlmt = ((top - 3 | 0) >>> 1);
> var cmpsts = Caml_array.caml_make_vect((ndxlmt >>> 5) + 1 | 0, 0);
> for(var loop = 1; loop <= 1000; ++loop){
>   var pir = 0;
>   while(pir <= ndxlmt) {
> var pi = pir;
> var p = (pi + pi | 0) + 3 | 0;
> var nxtc = (function(p){
> return function nxtc(_ci) {
>   while(true) {
> var ci = _ci;
> if (ci > ndxlmt) {
>   return /* () */0;
> }
> else {
>   var w = (ci >>> 5);
>   cmpsts[w] = cmpsts[w] | (1 << (ci & 31));
>   _ci = ci + p | 0;
>   continue ;
>
> }
>   };
> }
> }(p));
> var si = ((Caml_int32.imul(p, p) - 3 | 0) >>> 1);
> if (si > ndxlmt) {
>   pir = ndxlmt + 1 | 0;
> }
> else {
>   if (!(cmpsts[(pi >>> 5)] & (1 << (pi & 31 {
> nxtc(si);
>   }
>   pir = pi + 1 | 0;
> }
>   };
> }
> return cmpsts;
>   }
> }
>
> As the compiler knows that the `p` value is pure, it should know that it
> can reference it without danger of it being in an unknown state, so there
> is no need for a cloaure, and if `nxtc` is not a closure then it can be
> inlined as usual.
>
> The same thing happens currently when all loops are functional.
>
> The back up work around is to use imperative code, but that's ugly.  I
> wonder if you have any suggestions to avoid the closure?
>
> Regards, Gordon
>
>>
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/Um7WIBTq9xU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Regards
-- Hongbo Zhang

-- 
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: Emphasizing /r/elm more

['Rupert Smith' via Elm Discuss]

On Wednesday, January 4, 2017 at 12:27:11 PM UTC, John Orford wrote:
>
> That struck me as well - I am going to switch my name to the real one, if 
> I can on Reddit...
>

Or create a new account so you can keep the nickname to use when you are 
trolling us... :-P 

-- 
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: UI effects (align/tether, scroll into view) after elements are inserted

[Mark Hamburg]

We just had a similar concern come up but with the existing Dom package. If the 
init for a model wants to generate a focus command — the autofocus property is 
proving unreliable for reasons as yet undetermined — how can we arrange to have 
that command execute after the view has actually been instantiated? Do we need 
to chain off of animation ticks and wait a round or two before the focus task 
runs?

Mark

> On Jan 3, 2017, at 10:54 PM, Richard Feldman  
> wrote:
> 
> Hi Sebastian,
> 
> Elm batches DOM updat`es using requestAnimationFrame, so you should be able 
> to delay until after the next DOM update by wrapping your entire callback 
> (starting from let el = document.body.querySelector(selector)) in a call to 
> requestAnimationFrame.
> 
> See if that works!
> -- 
> 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.

-- 
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: Emphasizing /r/elm more

[Mark Hamburg]

Me, in my white male tech bubble, focused on user interface annoyances in 
Reddit. I asked around with some other developers I work with and have worked 
with and Reddit (along with Twitter) was viewed as a place that has been too 
friendly to hate speech — particularly racist and misogynist hate speech — and 
they were uncomfortable giving Reddit any business.

Mark

> On Jan 2, 2017, at 8:23 PM, Mark Hamburg  wrote:
> 
> The web interface to Reddit is abysmal. Email isn't great but Reddit seems 
> incredibly tedious.
> 
>> On Mon, Jan 2, 2017 at 7:21 PM, Charlie Koster  wrote:
>> I just wanted to confirm one of your assertions anecdotally. In the past 
>> week I wrote two Elm blog posts and opted to post them to /r/elm rather than 
>> elm-discuss for precisely the first two bullet points you listed. A linear 
>> discussion would have been largely unhelpful and distracting.
>> 
>> I also wanted to reinforce the importance of good moderation. I've seen 
>> small subreddits grow and die due to a lack of moderation, but the ones that 
>> have good moderation that encourage productive discussion end up doing 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.
> 

-- 
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: Emphasizing /r/elm more

[Charlie Koster]

Mark, Reddit is what you make of it. Subreddits (such as /r/elm) are 
self-moderated and it's easy enough to unsubscribe from the bad ones. I 
think you can be rest assured that /r/elm will be devoid of hate speech.




Those are some of my subscriptions and I don't encounter any hate speech at 
all.

-- 
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: Emphasizing /r/elm more

[Brian Hicks]

I understand the principle of wanting to avoid Twitter and Reddit. I feel 
pretty conflicted about those two services myself. But the fact remains 
that /r/elm is going to be a place that people go to ask questions, and if 
nobody is there to answer them we're giving people a really bad experience.

See also: the Go team tried to disown /r/golang for similar reasons last 
month. It caused a big stir and they ended up changing moderators and 
dropping the "official forum" status. Once people who were willing to 
moderate and contribute stepped up, it improved by leaps and bounds. Even 
the people who wanted to see it retired have remarked on the change in only 
half a month. I think /r/elm could see similar improvement.

Bottom line for me: the services that we build on are important, but not as 
important as the communities we create. Communities can move around despite 
services coming and going. Right now we have elm-discuss, Slack, and 
/r/elm. Discourse is awesome, but as Richard pointed out it would only 
fragment those fora further.

On Wednesday, January 4, 2017 at 11:38:07 AM UTC-5, Charlie Koster wrote:
>
> Mark, Reddit is what you make of it. Subreddits (such as /r/elm) are 
> self-moderated and it's easy enough to unsubscribe from the bad ones. I 
> think you can be rest assured that /r/elm will be devoid of hate speech.
>
>
> 
>
>
> Those are some of my subscriptions and I don't encounter any hate speech 
> at all.
>

-- 
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: UI effects (align/tether, scroll into view) after elements are inserted

[Sebastian Seilund]

Thanks, Richard.

I'm pretty sure I had tried that earlier, and the element wasn't there yet. 
I had to nest two `requestAnimationFrame` calls within each other, or a mix 
of `rAF` and `setTimeout` with 1 or 0 as delay. And I would see a short 
flicker on the screen before my scroll code executed. I was suspecting that 
the port call was made before Elm itself called `rAF`, which would make my 
call to `rAF ` run before Elm's.

But now it works beautifully with just one (like you say):

app.ports.scrollIntoView.subscribe(selector => {
  window.requestAnimationFrame(() => {
let el = document.body.querySelector(selector)
if (!el) {
  throw new Error(`scrollintoView error: Element not found by selector 
'${selector}'.`)
}
el.scrollIntoView()
  })
})


Is Elm's execution order of port calls and DOM updates always 
deterministic? I.e.:


   - Elm app's `update` function is called and returns with new model and 
   command
   - Elm calls `requestAnimationFrame` (to batch DOM writes)
   - Commands on ports are called into JS

Thanks,
Sebastian

On Tuesday, January 3, 2017 at 10:54:20 PM UTC-8, Richard Feldman wrote:
>
> Hi Sebastian,
>
> Elm batches DOM updat`es using requestAnimationFrame 
> ,
>  
> so you should be able to delay until after the next DOM update by wrapping 
> your entire callback (starting from let el = document.body.querySelector(
> selector)) in a call to requestAnimationFrame.
>
> See if that works!
>

-- 
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: UI effects (align/tether, scroll into view) after elements are inserted

[Sebastian Seilund]

Hi Mark. Try to send a message on your port as a command in your `init` 
function. In the port JS handler you run `requestAnimationFrame` and find 
and focus your element there. Does that work?

On Wednesday, January 4, 2017 at 8:24:40 AM UTC-8, Mark Hamburg wrote:
>
> We just had a similar concern come up but with the existing Dom package. 
> If the init for a model wants to generate a focus command — the autofocus 
> property is proving unreliable for reasons as yet undetermined — how can we 
> arrange to have that command execute after the view has actually been 
> instantiated? Do we need to chain off of animation ticks and wait a round 
> or two before the focus task runs?
>
> Mark
>
> On Jan 3, 2017, at 10:54 PM, Richard Feldman  > wrote:
>
> Hi Sebastian,
>
> Elm batches DOM updat`es using requestAnimationFrame 
> ,
>  
> so you should be able to delay until after the next DOM update by wrapping 
> your entire callback (starting from let el = document.body.querySelector(
> selector)) in a call to requestAnimationFrame.
>
> See if that works!
>
> -- 
> 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.

Re: [elm-discuss] Re: Emphasizing /r/elm more

[Rex van der Spuy]

On Wednesday, January 4, 2017 at 12:05:33 PM UTC-5, Brian Hicks wrote:
>
> the fact remains that /r/elm is going to be a place that people go to ask 
> questions, and if nobody is there to answer them we're giving people a 
> really bad experience.
>
>
That was my problem: When I started learning Elm I first posted questions 
on /r/elm. 
But, I soon found I received many more, and better, replies here on 
elm-discuss, so I hardly visit /r/elm anymore.

I think for this move to work need to somehow pull the plug on elm-discuss.
Maybe we should set a kill date, and then after that just lock down this 
list for good with a big sign saying "Please visit /r/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.

Re: [elm-discuss] Re: Emphasizing /r/elm more

[Mark Hamburg]

I, in my ungrammatical bubble, should perhaps use some Elm-based software to 
keep me from becoming too casual in my writing. :-P

> On Jan 4, 2017, at 8:32 AM, Mark Hamburg  wrote:
> 
> Me, in my white male tech bubble, focused on user interface annoyances in 
> Reddit. I asked around with some other developers I work with and have worked 
> with and Reddit (along with Twitter) was viewed as a place that has been too 
> friendly to hate speech — particularly racist and misogynist hate speech — 
> and they were uncomfortable giving Reddit any business.
> 
> Mark
> 
>> On Jan 2, 2017, at 8:23 PM, Mark Hamburg  wrote:
>> 
>> The web interface to Reddit is abysmal. Email isn't great but Reddit seems 
>> incredibly tedious.
>> 
>>> On Mon, Jan 2, 2017 at 7:21 PM, Charlie Koster  wrote:
>>> I just wanted to confirm one of your assertions anecdotally. In the past 
>>> week I wrote two Elm blog posts and opted to post them to /r/elm rather 
>>> than elm-discuss for precisely the first two bullet points you listed. A 
>>> linear discussion would have been largely unhelpful and distracting.
>>> 
>>> I also wanted to reinforce the importance of good moderation. I've seen 
>>> small subreddits grow and die due to a lack of moderation, but the ones 
>>> that have good moderation that encourage productive discussion end up doing 
>>> 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.
>> 

-- 
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: Emphasizing /r/elm more

[Mark Hamburg]

I'm well aware that the Elm subreddit can and will be moderated. The view point 
I was hearing and relaying was basically a political statement about choosing 
not to support Reddit.

Mark

> On Jan 4, 2017, at 8:38 AM, Charlie Koster  wrote:
> 
> Mark, Reddit is what you make of it. Subreddits (such as /r/elm) are 
> self-moderated and it's easy enough to unsubscribe from the bad ones. I think 
> you can be rest assured that /r/elm will be devoid of hate speech.
> 
> 
> 
> 
> 
> Those are some of my subscriptions and I don't encounter any hate speech at 
> all.
> -- 
> 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.

-- 
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: Emphasizing /r/elm more

[Mark Hamburg]

I agree that this only works if elm-discuss gets killed. It might, however, be 
necessary to also kill elm-dev because the leakage of elm-discuss traffic over 
into elm-dev will likely become much worse if elm-discuss goes away.

Mark

> On Jan 4, 2017, at 9:34 AM, Rex van der Spuy  wrote:
> 
> 
> 
>> On Wednesday, January 4, 2017 at 12:05:33 PM UTC-5, Brian Hicks wrote:
>> the fact remains that /r/elm is going to be a place that people go to ask 
>> questions, and if nobody is there to answer them we're giving people a 
>> really bad experience.
>> 
> 
> That was my problem: When I started learning Elm I first posted questions on 
> /r/elm. 
> But, I soon found I received many more, and better, replies here on 
> elm-discuss, so I hardly visit /r/elm anymore.
> 
> I think for this move to work need to somehow pull the plug on elm-discuss.
> Maybe we should set a kill date, and then after that just lock down this list 
> for good with a big sign saying "Please visit /r/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.

-- 
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: UI effects (align/tether, scroll into view) after elements are inserted

[Mark Hamburg]

I don't have a port. I'm just using the standard Dom package. But it would 
presumably have similar issues with attempts to interact with elements that 
aren't there yet.

Mark

> On Jan 4, 2017, at 9:30 AM, Sebastian Seilund  wrote:
> 
> Hi Mark. Try to send a message on your port as a command in your `init` 
> function. In the port JS handler you run `requestAnimationFrame` and find and 
> focus your element there. Does that work?
> 
>> On Wednesday, January 4, 2017 at 8:24:40 AM UTC-8, Mark Hamburg wrote:
>> We just had a similar concern come up but with the existing Dom package. If 
>> the init for a model wants to generate a focus command — the autofocus 
>> property is proving unreliable for reasons as yet undetermined — how can we 
>> arrange to have that command execute after the view has actually been 
>> instantiated? Do we need to chain off of animation ticks and wait a round or 
>> two before the focus task runs?
>> 
>> Mark
>> 
>>> On Jan 3, 2017, at 10:54 PM, Richard Feldman  wrote:
>>> 
>>> Hi Sebastian,
>>> 
>>> Elm batches DOM updat`es using requestAnimationFrame, so you should be able 
>>> to delay until after the next DOM update by wrapping your entire callback 
>>> (starting from let el = document.body.querySelector(selector)) in a call to 
>>> requestAnimationFrame.
>>> 
>>> See if that works!
>>> -- 
>>> 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.

-- 
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: UI effects (align/tether, scroll into view) after elements are inserted

[Mark Hamburg]

Part of my issue here is that the documentation for the Dom module makes no 
promises about execution order and hence should presumably be viewed as free to 
change in the future. That said, when I go look at the source, I see that it 
ties execution to requestAnimationFrame which seems good but then leaves me 
still uncertain about when it executes relative to the actual view rendering.

Mark

> On Jan 4, 2017, at 10:15 AM, Mark Hamburg  wrote:
> 
> I don't have a port. I'm just using the standard Dom package. But it would 
> presumably have similar issues with attempts to interact with elements that 
> aren't there yet.
> 
> Mark
> 
>> On Jan 4, 2017, at 9:30 AM, Sebastian Seilund  wrote:
>> 
>> Hi Mark. Try to send a message on your port as a command in your `init` 
>> function. In the port JS handler you run `requestAnimationFrame` and find 
>> and focus your element there. Does that work?
>> 
>>> On Wednesday, January 4, 2017 at 8:24:40 AM UTC-8, Mark Hamburg wrote:
>>> We just had a similar concern come up but with the existing Dom package. If 
>>> the init for a model wants to generate a focus command — the autofocus 
>>> property is proving unreliable for reasons as yet undetermined — how can we 
>>> arrange to have that command execute after the view has actually been 
>>> instantiated? Do we need to chain off of animation ticks and wait a round 
>>> or two before the focus task runs?
>>> 
>>> Mark
>>> 
 On Jan 3, 2017, at 10:54 PM, Richard Feldman  wrote:
 
 Hi Sebastian,
 
 Elm batches DOM updat`es using requestAnimationFrame, so you should be 
 able to delay until after the next DOM update by wrapping your entire 
 callback (starting from let el = document.body.querySelector(selector)) in 
 a call to requestAnimationFrame.
 
 See if that works!
 -- 
 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.

-- 
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: Emphasizing /r/elm more

[Martin DeMello]

I would argue very strongly against killing elm-discuss. I'm a heavy reddit
user, and I think it simply lacks the features necessary to support
mailing-list-style discussions:

1. if you subscribe to a lot of subreddits, there is no guarantee you'll be
shown new posts from /r/elm in your front page. gmail lets me see a list of
folders in my sidebar with unread-thread counts for each, so I never have
to think about specifically opening up elm-discuss to check if something
new has been posted

2. there is no good way to see the messages you have and haven't already
read within a thread. (there are browser plugins that try to help with this
but don't do a particularly good job; it's a hard problem to solve from the
outside)

3. you get a notification if someone replies to you, but not if someone
replies to that reply.

4. searching through old conversation is really hard

martin

On Wed, Jan 4, 2017 at 10:13 AM, Mark Hamburg  wrote:

> I agree that this only works if elm-discuss gets killed. It might,
> however, be necessary to also kill elm-dev because the leakage of
> elm-discuss traffic over into elm-dev will likely become much worse if
> elm-discuss goes away.
>
> Mark
>
> On Jan 4, 2017, at 9:34 AM, Rex van der Spuy 
> wrote:
>
>
>
> On Wednesday, January 4, 2017 at 12:05:33 PM UTC-5, Brian Hicks wrote:
>>
>> the fact remains that /r/elm is going to be a place that people go to ask
>> questions, and if nobody is there to answer them we're giving people a
>> really bad experience.
>>
>>
> That was my problem: When I started learning Elm I first posted questions
> on /r/elm.
> But, I soon found I received many more, and better, replies here on
> elm-discuss, so I hardly visit /r/elm anymore.
>
> I think for this move to work need to somehow pull the plug on elm-discuss.
> Maybe we should set a kill date, and then after that just lock down this
> list for good with a big sign saying "Please visit /r/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.
>
> --
> 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.
>

-- 
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: Emphasizing /r/elm more

[brian]

Killing elm-discuss is outside the scope of the discussion. The point is to 
emphasize an underused watering hole, not kill an existing one that works well 
for a subset of the community.

> On Jan 4, 2017, at 2:00 PM, Martin DeMello  wrote:
> 
> I would argue very strongly against killing elm-discuss. I'm a heavy reddit 
> user, and I think it simply lacks the features necessary to support 
> mailing-list-style discussions:
> 
> 1. if you subscribe to a lot of subreddits, there is no guarantee you'll be 
> shown new posts from /r/elm in your front page. gmail lets me see a list of 
> folders in my sidebar with unread-thread counts for each, so I never have to 
> think about specifically opening up elm-discuss to check if something new has 
> been posted
> 
> 2. there is no good way to see the messages you have and haven't already read 
> within a thread. (there are browser plugins that try to help with this but 
> don't do a particularly good job; it's a hard problem to solve from the 
> outside)
> 
> 3. you get a notification if someone replies to you, but not if someone 
> replies to that reply.
> 
> 4. searching through old conversation is really hard
> 
> martin
> 
>> On Wed, Jan 4, 2017 at 10:13 AM, Mark Hamburg  wrote:
>> I agree that this only works if elm-discuss gets killed. It might, however, 
>> be necessary to also kill elm-dev because the leakage of elm-discuss traffic 
>> over into elm-dev will likely become much worse if elm-discuss goes away.
>> 
>> Mark
>> 
>>> On Jan 4, 2017, at 9:34 AM, Rex van der Spuy  wrote:
>>> 
>>> 
>>> 
 On Wednesday, January 4, 2017 at 12:05:33 PM UTC-5, Brian Hicks wrote:
 the fact remains that /r/elm is going to be a place that people go to ask 
 questions, and if nobody is there to answer them we're giving people a 
 really bad experience.
 
>>> 
>>> That was my problem: When I started learning Elm I first posted questions 
>>> on /r/elm. 
>>> But, I soon found I received many more, and better, replies here on 
>>> elm-discuss, so I hardly visit /r/elm anymore.
>>> 
>>> I think for this move to work need to somehow pull the plug on elm-discuss.
>>> Maybe we should set a kill date, and then after that just lock down this 
>>> list for good with a big sign saying "Please visit /r/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.
>> 
>> -- 
>> 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.
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/elm-discuss/rg3fzdyG_VU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> elm-discuss+unsubscr...@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.

Re: [elm-discuss] Re: Emphasizing /r/elm more

[Mark Hamburg]

At least going through the mental exercise of "would you move elm-dev to 
reddit" is a way to avoid the frequently fallacious mental trap of "I wouldn't 
do this, but others should". In fact, for any move to any other system, it 
might actually be a good thing for elm-dev to lead the way. That way, the 
argument could be made "we're using it for Elm development discussions and it's 
working great".

Mark

> On Jan 4, 2017, at 10:13 AM, Mark Hamburg  wrote:
> 
> I agree that this only works if elm-discuss gets killed. It might, however, 
> be necessary to also kill elm-dev because the leakage of elm-discuss traffic 
> over into elm-dev will likely become much worse if elm-discuss goes away.
> 
> Mark
> 
>> On Jan 4, 2017, at 9:34 AM, Rex van der Spuy  wrote:
>> 
>> 
>> 
>>> On Wednesday, January 4, 2017 at 12:05:33 PM UTC-5, Brian Hicks wrote:
>>> the fact remains that /r/elm is going to be a place that people go to ask 
>>> questions, and if nobody is there to answer them we're giving people a 
>>> really bad experience.
>>> 
>> 
>> That was my problem: When I started learning Elm I first posted questions on 
>> /r/elm. 
>> But, I soon found I received many more, and better, replies here on 
>> elm-discuss, so I hardly visit /r/elm anymore.
>> 
>> I think for this move to work need to somehow pull the plug on elm-discuss.
>> Maybe we should set a kill date, and then after that just lock down this 
>> list for good with a big sign saying "Please visit /r/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.

-- 
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: Emphasizing /r/elm more

[Mark Hamburg]

So, this is really about "please go look at /r/elm too"?

Mark

> On Jan 4, 2017, at 11:08 AM, br...@brianthicks.com wrote:
> 
> Killing elm-discuss is outside the scope of the discussion. The point is to 
> emphasize an underused watering hole, not kill an existing one that works 
> well for a subset of the community.
> 
>> On Jan 4, 2017, at 2:00 PM, Martin DeMello  wrote:
>> 
>> I would argue very strongly against killing elm-discuss. I'm a heavy reddit 
>> user, and I think it simply lacks the features necessary to support 
>> mailing-list-style discussions:
>> 
>> 1. if you subscribe to a lot of subreddits, there is no guarantee you'll be 
>> shown new posts from /r/elm in your front page. gmail lets me see a list of 
>> folders in my sidebar with unread-thread counts for each, so I never have to 
>> think about specifically opening up elm-discuss to check if something new 
>> has been posted
>> 
>> 2. there is no good way to see the messages you have and haven't already 
>> read within a thread. (there are browser plugins that try to help with this 
>> but don't do a particularly good job; it's a hard problem to solve from the 
>> outside)
>> 
>> 3. you get a notification if someone replies to you, but not if someone 
>> replies to that reply.
>> 
>> 4. searching through old conversation is really hard
>> 
>> martin
>> 
>>> On Wed, Jan 4, 2017 at 10:13 AM, Mark Hamburg  wrote:
>>> I agree that this only works if elm-discuss gets killed. It might, however, 
>>> be necessary to also kill elm-dev because the leakage of elm-discuss 
>>> traffic over into elm-dev will likely become much worse if elm-discuss goes 
>>> away.
>>> 
>>> Mark
>>> 
 On Jan 4, 2017, at 9:34 AM, Rex van der Spuy  wrote:
 
 
 
> On Wednesday, January 4, 2017 at 12:05:33 PM UTC-5, Brian Hicks wrote:
> the fact remains that /r/elm is going to be a place that people go to ask 
> questions, and if nobody is there to answer them we're giving people a 
> really bad experience.
> 
 
 That was my problem: When I started learning Elm I first posted questions 
 on /r/elm. 
 But, I soon found I received many more, and better, replies here on 
 elm-discuss, so I hardly visit /r/elm anymore.
 
 I think for this move to work need to somehow pull the plug on elm-discuss.
 Maybe we should set a kill date, and then after that just lock down this 
 list for good with a big sign saying "Please visit /r/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.
>>> 
>>> -- 
>>> 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.
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/elm-discuss/rg3fzdyG_VU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> elm-discuss+unsubscr...@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.

-- 
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: Emphasizing /r/elm more

[brian]

I can't speak to Evan's original intent in posting, but that's what I'd like to 
see people do.

> On Jan 4, 2017, at 2:11 PM, Mark Hamburg  wrote:
> 
> So, this is really about "please go look at /r/elm too"?
> 
> Mark
> 
>> On Jan 4, 2017, at 11:08 AM, br...@brianthicks.com wrote:
>> 
>> Killing elm-discuss is outside the scope of the discussion. The point is to 
>> emphasize an underused watering hole, not kill an existing one that works 
>> well for a subset of the community.
>> 
>>> On Jan 4, 2017, at 2:00 PM, Martin DeMello  wrote:
>>> 
>>> I would argue very strongly against killing elm-discuss. I'm a heavy reddit 
>>> user, and I think it simply lacks the features necessary to support 
>>> mailing-list-style discussions:
>>> 
>>> 1. if you subscribe to a lot of subreddits, there is no guarantee you'll be 
>>> shown new posts from /r/elm in your front page. gmail lets me see a list of 
>>> folders in my sidebar with unread-thread counts for each, so I never have 
>>> to think about specifically opening up elm-discuss to check if something 
>>> new has been posted
>>> 
>>> 2. there is no good way to see the messages you have and haven't already 
>>> read within a thread. (there are browser plugins that try to help with this 
>>> but don't do a particularly good job; it's a hard problem to solve from the 
>>> outside)
>>> 
>>> 3. you get a notification if someone replies to you, but not if someone 
>>> replies to that reply.
>>> 
>>> 4. searching through old conversation is really hard
>>> 
>>> martin
>>> 
 On Wed, Jan 4, 2017 at 10:13 AM, Mark Hamburg  
 wrote:
 I agree that this only works if elm-discuss gets killed. It might, 
 however, be necessary to also kill elm-dev because the leakage of 
 elm-discuss traffic over into elm-dev will likely become much worse if 
 elm-discuss goes away.
 
 Mark
 
> On Jan 4, 2017, at 9:34 AM, Rex van der Spuy  
> wrote:
> 
> 
> 
>> On Wednesday, January 4, 2017 at 12:05:33 PM UTC-5, Brian Hicks wrote:
>> the fact remains that /r/elm is going to be a place that people go to 
>> ask questions, and if nobody is there to answer them we're giving people 
>> a really bad experience.
>> 
> 
> That was my problem: When I started learning Elm I first posted questions 
> on /r/elm. 
> But, I soon found I received many more, and better, replies here on 
> elm-discuss, so I hardly visit /r/elm anymore.
> 
> I think for this move to work need to somehow pull the plug on 
> elm-discuss.
> Maybe we should set a kill date, and then after that just lock down this 
> list for good with a big sign saying "Please visit /r/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.
 
 -- 
 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.
>>> 
>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Elm Discuss" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/elm-discuss/rg3fzdyG_VU/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> elm-discuss+unsubscr...@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.
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/elm-discuss/rg3fzdyG_VU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> elm-discuss+unsubscr...@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: Game entities design question

['Andrew Radford' via Elm Discuss]

Martin are there any pros/cons to using extensible records for the game 
entities? i.e closer conceptually to an OOP model where an entity might 
inherit Collision/Physics properties from a common base class?

Andrew


>>

-- 
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: Feature: 'where' expressions (continued from GitHub)

['Andrew Radford' via Elm Discuss]

Colin,

Thanks for this comprehensive post - very well thought out and reasonably 
considered

TIL about 'where' - wow so much awesome stuff is in Haskell.  Let...in now 
seems to be upside down! 'Where' seems to closer suit describing *ideas* like 
you would in Plain English:

Kinetic Energy is:  1/2 mv^2
 where 'm' is the mass
 and 'v' is the velocity

i.e it follows a pattern more human-brain-friendly:

*Name* : *Fundamental Idea*
 other
 small
 details
 if you really care

For the same reason we don't lay out our recipes ingredients first followed 
by the name of the dish. Or our CVs with the description of duties, sate of 
service then finally the Job title.

I'm a 'top down' thinker, not a 'bottom up' thinker, so would probably 
chose where over let. But is Is 'where' really actually just a re-organised 
let..in? I.e if there was support for both, would it be simply a choice of 
personal style preference? Kinda like how you currently have the freedom to 
chose between |> and <|, >> and << etc?



On Saturday, 31 December 2016 18:36:14 UTC, Colin Woodbury wrote:
>
> *On `where`*
>
> 
>

-- 
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: Feature: 'where' expressions (continued from GitHub)

[Joey Eremondi]

>
> Kinda like how you currently have the freedom to chose between |> and <|,
> >> and <<


They're not really the same thing: << is function composition, and <| is
function application. There are cases where you can use either, but for
each there are cases where only one will do the trick.

Whereas, where vs. let are literally identical in what they do, they just
look different.

On Wed, Jan 4, 2017 at 12:20 PM, 'Andrew Radford' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> Colin,
>
> Thanks for this comprehensive post - very well thought out and reasonably
> considered
>
> TIL about 'where' - wow so much awesome stuff is in Haskell.  Let...in now
> seems to be upside down! 'Where' seems to closer suit describing *ideas* like
> you would in Plain English:
>
> Kinetic Energy is:  1/2 mv^2
>  where 'm' is the mass
>  and 'v' is the velocity
>
> i.e it follows a pattern more human-brain-friendly:
>
> *Name* : *Fundamental Idea*
>  other
>  small
>  details
>  if you really care
>
> For the same reason we don't lay out our recipes ingredients first
> followed by the name of the dish. Or our CVs with the description of
> duties, sate of service then finally the Job title.
>
> I'm a 'top down' thinker, not a 'bottom up' thinker, so would probably
> chose where over let. But is Is 'where' really actually just a re-organised
> let..in? I.e if there was support for both, would it be simply a choice of
> personal style preference? Kinda like how you currently have the freedom to
> chose between |> and <|, >> and << etc?
>
>
>
> On Saturday, 31 December 2016 18:36:14 UTC, Colin Woodbury wrote:
>>
>> *On `where`*
>>
>> 
>>
> --
> 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.
>

-- 
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: Feature: 'where' expressions (continued from GitHub)

['Andrew Radford' via Elm Discuss]

Heh ok read it again I'll make it more programmer friendly: 

( |> and <| ) and ( >> and << )


They (each) have identical behavior in what they do, with a left/right 
symmetry. (I guess you just confirmed it is the same for let/where, with a 
top/bottom symmetry)


On Wednesday, 4 January 2017 20:30:25 UTC, Joey Eremondi wrote:
>
> Kinda like how you currently have the freedom to chose between |> and <|, 
>> >> and <<
>
>
> They're not really the same thing: << is function composition, and <| is 
> function application. There are cases where you can use either, but for 
> each there are cases where only one will do the trick. 
>
> Whereas, where vs. let are literally identical in what they do, they just 
> look different.
>
>

-- 
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: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

As pointed out earlier, it is not true for *Haskell's* let and where. 


> Am 04.01.2017 um 22:52 schrieb 'Andrew Radford' via Elm Discuss 
> :
> 
> Heh ok read it again I'll make it more programmer friendly: 
> 
> ( |> and <| ) and ( >> and << )
> 
> 
> They (each) have identical behavior in what they do, with a left/right 
> symmetry. (I guess you just confirmed it is the same for let/where, with a 
> top/bottom symmetry)
> 
> 
> On Wednesday, 4 January 2017 20:30:25 UTC, Joey Eremondi wrote:
>> 
>>> Kinda like how you currently have the freedom to chose between |> and <|, 
>>> >> and <<
>> 
>> They're not really the same thing: << is function composition, and <| is 
>> function application. There are cases where you can use either, but for each 
>> there are cases where only one will do the trick. 
>> 
>> Whereas, where vs. let are literally identical in what they do, they just 
>> look different.
>> 
> 
> -- 
> 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.

-- 
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: Emphasizing /r/elm more

['Rupert Smith' via Elm Discuss]

On Wednesday, January 4, 2017 at 7:00:34 PM UTC, Martin DeMello wrote:
>
> 2. there is no good way to see the messages you have and haven't already 
> read within a thread. (there are browser plugins that try to help with this 
> but don't do a particularly good job; it's a hard problem to solve from the 
> outside)
>

Yeah, I notice that. With google groups I tend to "mark all as read" then 
when I come back tomorrow I can straight away see new stuff. I look into 
the topics that interest me, then "mark all as read" again when I am done. 
As far as keeping up with discussions go, I'm not sure reddit really does 
have a better UI than google groups. 

-- 
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] How does evancz.Markdown work?

['Rupert Smith' via Elm Discuss]

When server side rendering Html I am trying to figure out why markdown 
processing is not working right. It fails to wrap a line of text in a 
aragraph. So I tried this program:

import Html exposing (text)
import Markdown

main =
 let 
   d = Debug.log "test" (Markdown.toHtml [] "test")
   d1 = Debug.log "test2" (Html.p [] [ Html.text "test" ])
 in
  Markdown.toHtml [] "test"

I was surprised that Markdown.toHtml does not produce an Html node as I was 
expecting, but something with type = "custom" instead. Here is the console 
output:

test2: { type = "node", tag = "p", facts = {}, children = { 0 = { type = 
"text", text = "test" } }, namespace = , 
descendantsCount = 1 }

test: { type = "custom", facts = {}, model = { options = { githubFlavored = 
Just { tables = False, breaks = False }, defaultHighlighting = Nothing, 
sanitize = False, smartypants = False }, markdown = "test" }, impl = { 
render = , diff =  } }

I guess this invokes the https://github.com/chjj/marked javascript markdown 
processor somehow from the details in the "custom" Html model. Does that 
mean that marked needs to be included as a javascript library on the page - 
or does Native elm code somehow pull it in?

-- 
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 does evancz.Markdown work?

['Rupert Smith' via Elm Discuss]

On Wednesday, January 4, 2017 at 11:01:44 PM UTC, Rupert Smith wrote:
>
> I guess this invokes the https://github.com/chjj/marked javascript 
> markdown processor somehow from the details in the "custom" Html model. 
> Does that mean that marked needs to be included as a javascript library on 
> the page - or does Native elm code somehow pull it in?
>

I think it must embed a copy of marked on this line here:

https://github.com/evancz/elm-markdown/blob/3.0.1/src/Native/Markdown.js#L66

-- 
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 does evancz.Markdown work?

['Rupert Smith' via Elm Discuss]

On Wednesday, January 4, 2017 at 11:01:44 PM UTC, Rupert Smith wrote:
>
> When server side rendering Html I am trying to figure out why markdown 
> processing is not working right.
>

I just get the unprocessed markdown appearing in the page. Perhaps:

https://github.com/eeue56/elm-server-side-renderer

does not support the "custom" Html model. I'll take a look and see if it 
can be made to work...

-- 
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] How does evancz.Markdown work?

[Noah Hall]

It does support custom and supports markdown as a special case -
https://github.com/eeue56/elm-server-side-renderer/blob/master/src/ServerSide/Markdown.elm

However, it doesn't convert it to html on the server side. That should be
trivial to add - just a called to marked, but I haven't needed it yet


On Thursday, January 5, 2017, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Wednesday, January 4, 2017 at 11:01:44 PM UTC, Rupert Smith wrote:
>>
>> When server side rendering Html I am trying to figure out why markdown
>> processing is not working right.
>>
>
> I just get the unprocessed markdown appearing in the page. Perhaps:
>
> https://github.com/eeue56/elm-server-side-renderer
>
> does not support the "custom" Html model. I'll take a look and see if it
> can be made to work...
>
> --
> 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.
>

-- 
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] How does evancz.Markdown work?

['Rupert Smith' via Elm Discuss]

On Wednesday, January 4, 2017 at 11:24:31 PM UTC, Noah Hall wrote:
>
> It does support custom and supports markdown as a special case - 
>
> https://github.com/eeue56/elm-server-side-renderer/blob/master/src/ServerSide/Markdown.elm
>
> However, it doesn't convert it to html on the server side. That should be 
> trivial to add - just a called to marked, but I haven't needed it yet 
>

Sweet. Thanks, a job for tomorrow... 

-- 
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] Emphasizing /r/elm more

[Wojciech S. Czarnecki]

Dnia 2017-01-02, o godz. 17:50:41
Evan Czaplicki  napisał(a):

> I recently talked with folks who moderate the various Elm discussion forums
> about the challenges that come up and how we can do better.
> 
> The short version is: *we should start migrating more discussion to /r/elm
> .*

In short version: then I am off.

> Now the long version!

> I think it's fair to say that /r/elm is much more easily
> accessible and "public facing" for newcomers.

So let r/elm be a first-help channel for the newcomers. Who in the sticky
(pinned in r-lingo iirc) faq will be given links to mail clients and to
books how to use a mail client andThen directed here. 


> Problems with elm-discuss:
> 
>- Threads are linear, so it's hard for people to branch off into
>sub-discussions.

Excuse me, both my email clients (claws/mutt) show elm-* threads perfectly.
Unlike reddit or g-groups web [.expl.] half baked things.

>- There's no voting mechanism in elm-discuss, so topics are sorted by
>"are people posting?" not by "do people care?"

This is NOT a problem on a mail list for someone who is subscribed to the
list. Alas 'do people care' in terms of 'stars' or 'upvotes' or anything else
similar is - at least for me - against the user. It makes some topics
fashionable/hot and these are (in web interfaces) on top. Important,
valuable, hard topics are pushed off the sight of the web interface user.

In contrary, on the mailing list one at least sees the 'Subject' line of
recently posted threads. And then have it avaliable for grep.

>- Moderation to avoid spam is more difficult. All new users are
>moderated by default to avoid those awful spam robots that Google Groups
>does not catch.

This is NOT a problem for someone subscribed to a mail list. I am not that
long here - my grep '^From\s' march/elm*|wc -l shows 1957 messages (both
-discuss and -dev) - and NO single piece of spam is there.

>- It goes to people's already full inboxes. If you change this, you use
>the online interface, which is not amazing.

It goes straight to its dedicated maildir via miracle of ol' pale procmail.
The same miracle g-tags can do for gmail users; in easy clickable way.

> Problems from having two long-form forums:
> 
>- Lots of valuable expertise *only* lives on elm-discuss. When new folks
>come to /r/elm, there are not as many folks with as much production
>experience.

So let someone (a pinned faq post?) there direct newcomers here.
Possibly with a word about things that existed before web (like
aforementioned e-mail clients).

>- Blog posts (frequently shared on /r/elm) miss out on a lot of valuable
>feedback.

As above: tell people to post links also here, eg. with customary [BLOG] tag.

> They also have an interesting approach to answering beginner questions
> 
> that

Yep. Pinned posts are good to tell people that there is a thing called email
and it can be used to post and receive valuable information about elm :).

TL;DR. r/elm should exist as an entry point for the newcomers. elm-discuss
should stay for real discussions.

P.S. Thanks for keeping Elm simple :)

-- 
Wojciech S. Czarnecki
   ^oo^ OHIR-RIPE

-- 
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] Emphasizing /r/elm more

[Brian Hicks]

   - Moderation to avoid spam is more difficult. All new users are
   moderated by default to avoid those awful spam robots that Google 
Groups

   does not catch.


This is NOT a problem for someone subscribed to a mail list. I am not 
that
long here - my grep '^From\s' march/elm*|wc -l shows 1957 messages 
(both

-discuss and -dev) - and NO single piece of spam is there.


As one of the people who approves every post from a new author manually, 
and just did for yours… well, maybe that’s why. The spam is a 
problem.


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

[GordonBGood]

On Wednesday, 4 January 2017 21:05:58 UTC+7, Bob Zhang wrote:
>
> Hi Gordon, 
>   As you can see, BuckleScript already did a very good good job here, of 
> course, there are still places for improvement. To write extremely high 
> performance code, you should avoid creating a closure in a tight loop, here 
> you can lift the `nxtc` into the top level, in the future, we will do this 
> inside the compiler. Lets take further discussions off the list -- Hongbo
>

Hi Hongbo, yes, BuckleScript did a very good job other than 1) mistakenly 
determining that the closure was necessary, then 2) not automatically 
lifting the closure, and then 3) not inlining the resulting (non-closure) 
function call away (see Haskell join points optimizations).  I'm just 
sayin' ;)  In case you needed adding to your TODO list...

In fact, BuckleScript *already does* catch most cases of these, and didn't 
in this one case because the enclosing loop has been tail call optimized 
(manually in case of the code I showed) so become a "ugly imperative code" 
loop internally, and the compiler then treats the binding `p` derived from 
an impure loop variable as impure and thus needing closure treatment, which 
seems to cause the resulting function to be invalidated as a candidate for 
inlining.  The compiler needs to see that the the binding `p` is invariant 
(in fact guaranteed as the compiler injected a let on the loop variable) 
during the whole creation and execution of the `nxtc` function, therefore 
doesn't need the closure and thus can be inlinee.  (BTW, it seems that 
BuckleScript ignores the [@@inline] and [@inlined] OCaml extensions?)

If  the `nxtc` function is lifted to the top level, then it needs to be 
written so that the otherwise free bindings are arguments (`p` and `cmpsts` 
in this case) and thus it is no longer a closure, and even if there were an 
inner worker closure, BuckleScript already inlines and tail calls when 
captured bindings are arguments or derived from arguments of a function 
call, recognizing that they are pure.  There will still be a function call 
to the lifted `nxtc` where there wouldn't be if it were inlined however, 
which means that inlining would be better, although the function call has 
negligible cost relative to the rest of the work in this case.

The only reason this was noticeable here is that it turns out that the time 
cost is not so much in the creation of the closure but much more the cost 
of binding a function (a closure in this case) to a variable.  It's 
interesting how incredibly slow JavaScript/V8 is at creating a function 
binding rather than just calling one - I calculate 10's of thousands of CPU 
clock cycles; it must be dropping back to evaluating the expression each 
loop rather than JIT compiling it plus the expected time of creating a 
function object on the heap.  This isn't BuckleScript's problem, just that 
BuckleScript can help avoid it for the unwary.

Stepping back, I don't have much to complain about, as before I met 
BuckleScript I would have been writing TypeScript/JavaScript mostly 
imperatively and BuckleScript/OCaml offers the option to do the same, if 
necessary for extremely time critical code!  I've just gotten used to 
avoiding that paradigm.

Yes, let's move the discussion somewhere else as it isn't relevant here. I 
just want to say thanks for the heads-up on BuckleScript, which I am quite 
enjoying in spite of its OCaml syntax foibles.  Now I can develop both Elm 
and BuckleScript inside similar development environments using the Visual 
Studio Code plugins. - Gordon
  

> On Wed, Jan 4, 2017 at 1:17 AM, GordonBGood  > wrote:
>
>> Hi Bob/Hongbo,
>>
>> I've run into my first speed problem with BuckleScript:  When it decides 
>> it needs to form a closure of captured free binding(s), it creates a 
>> "function returning a function" with the outer function's arguments being 
>> the current state of the "pure" captured bindings, and the inner returned 
>> function the actual closure code.  When this happens anywhere near an inner 
>> loop, the code gets very slow, although sometimes the compiler is smart 
>> enough to infer that the closure is not necessary is when the binding value 
>> is an argument of an enclosing function; however, this does not happen for 
>> local `let` bindings even when they are in the same scope as the 
>> callee/caller sites.
>>
>> For example, the following bit-packed Sieve of Eratosthenes sieves over a 
>> range and returns the bit packed array of found primes over that range 
>> (odds-only.  It runs about five times slower than using imperative code 
>> for/while loops (top of a quarter million).  Code is as follows:
>>
>> let soe_loop top =
>>   if top < 3 then Array.make 0 0 else
>>   let ndxlmt = (top - 3) lsr 1 in
>>   let cmpsts = Array.make ((ndxlmt lsr 5) + 1) 0 in
>>   for loop = 1 to 1000 do (* do it many times for timing *)
>> let pir = ref 0 in
>> while !pir <= ndxlmt do
>>   let pi = !pir in
>>   let p =

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

['Andrew Radford' via Elm Discuss]

Gotcha. Presumably there would have to be an Elm flavor of it, which may 
not work the same way but kept the core concept of being an 'let..in'  the 
other way up.

I have a feeling that 'where' would clarify a lot of my code. But I also 
have a feeling I'll never see it in Elm.

On Wednesday, 4 January 2017 21:58:35 UTC, Janis Voigtländer wrote:
>
> As pointed out earlier, it is not true for *Haskell's* let and where. 
>
>
>

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