Re: [elm-discuss] Listening to messages from different modules on an update

Sure I'm using something different. :-) On Wednesday, November 16, 2016 at 12:07:25 AM UTC+1, OvermindDL1 wrote: > > aMSG is not a valid constructor name, perhaps instead AMSG or A_Msg or > MsgA or so, as long as it starts with an uppercase. :-) > > > On Tuesday, November 15, 2016 at 3:50:36 PM

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

On Tue, Nov 15, 2016 at 2:38 PM, 'Andrew Radford' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > I agree with you there. I'm just pointing out that calling this a > community decision is misrepresenting things. > What would a community decision look like to you (procedurally)? -- You

[elm-discuss] ANN: update-clock for fixed-time-step game loops

On the advice of counsel (thanks Overmind), I moved this to a new thread. So a long time ago, d13 shared this article on elm-discuss. It explains how to update your model at fixed intervals, even when the updates are driven by, say, a

Re: [elm-discuss] Listening to messages from different modules on an update

Thank you. Tried to apply it but my problem is that I'm trying to send initialize a request on init: init : ( Model, Cmd Msg ) init = ( { -- my model here } , getJson ) And of course `getJson` is returning `A.Msg`, so even if in B I declare: type Msg = aMSG A.Msg | SomeLocalMessage

Re: [elm-discuss] Help for article review for SPA applications in Elm 0.18

Great article! I really like the way that you take the reader step by step through building a basic SPA, which even includes navigation and url parsing. Personally, I think it is fine to let the reader "play along" by making a local copy and work on that. It would be useful if you point out

Re: [elm-discuss] Re: Effects.tick vs Time.fps

On second thought, maybe it was not the best idea to resurrect a thread whose title refers to two functions that no longer exist... On Tue, Nov 15, 2016 at 1:09 PM, Nick H wrote: > Thread... resurrected! > > Just wanted to mention that I took the game loop pattern and

Re: [elm-discuss] Re: Correct use of port subscriptions in a submodule reused multiple times?

Thank you, Wouter for explanation. I was reading the documentation, but the chapter covers just the reusable views. View functions seems fine, using modules one can create, group, nest, etc. I am wondering how making everything "flat" scales in a long term. Having everything in just 4 files

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

I agree with you there. I'm just pointing out that calling this a community decision is misrepresenting things. On Tuesday, 15 November 2016 21:04:27 UTC, Duane Johnson wrote: > > > On Tue, Nov 15, 2016 at 1:23 PM, 'Andrew Radford' via Elm Discuss < > elm-d...@googlegroups.com > wrote: > >> No,

[elm-discuss] Re: How to manage subscriptions that require side effects?

Thanks a lot for the detailed answer!!! I clearly wasn't aware of the effect manager. I would read more about it. Thanks! On Tuesday, November 15, 2016 at 6:20:27 PM UTC-3, OvermindDL1 wrote: > > Comments i > > On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas > wrote: >>

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

> > What do you think about my suggestion in previous reply ? replacing > List.range with List.(..) operator ? Forgive me if somebody has already pointed this out, but it is very easy to write such a function yourself. (..) : Int -> Int -> List Int > (..) a b = List.range a b > If this is

Re: [elm-discuss] Re: Effects.tick vs Time.fps

Thread... resurrected! Just wanted to mention that I took the game loop pattern and wrapped it up in a library . If anyone has feedback on the API, I would love to hear it. I went with something that made sense to me, but... well,

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

On Tue, Nov 15, 2016 at 1:23 PM, 'Andrew Radford' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > No, it wasn't. Some parts of the community were aware of it, but calling > it a community decision is overstating it. While I wish it were otherwise, my experience from other communities

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

No, it wasn't. Some parts of the community were aware of it, but calling it a community decision is overstating it. On Tuesday, 15 November 2016 15:30:52 UTC, Robin Heggelund Hansen wrote: > > This was very much a community decision > -- You received this message because you are subscribed

Re: [elm-discuss] What do you think about Eve?

Also, the flappy bird example doesn't render properly in Firefox, at least for me. On Tue, Nov 15, 2016 at 11:27 AM, Nick H wrote: > Embedding the code in its documentation is a very interesting idea. I can > see it being very useful for tutorials & libraries. (The

Re: [elm-discuss] What do you think about Eve?

Embedding the code in its documentation is a very interesting idea. I can see it being very useful for tutorials & libraries. (The examples were pleasant to read through.) But generally I try to avoid comments in favor of making the code self-documenting. Comments are a liability -- it's easy for

Re: [elm-discuss] Re: Making imports more pleasant

I'm not sure what your proposing, the Python syntax you stated does the exact same thing as exposing (..). Showing where a name came from would be a great IDE feature though, Haskell can do this on Atom and it's really helpful. On Nov 15, 2016 10:33 AM, "Alejandro Do Nascimento"

Re: [elm-discuss] Re: Making imports more pleasant

I'm just starting with Elm, I'm as newbie as someone can be. I'm reading some examples of how to use the hop router on github, most of the things I've have found use a lot of *exposing (..)* so I find myself wasting time just searching the declarations of the symbols I encounter. I think that's

Re: [elm-discuss] Help for article review for SPA applications in Elm 0.18

Not sure about gh-pages, but I think is better to download the repo and checkout the tags running elm-reactor. It's quite easy to setup. This way you can easily play with the code and make changes. I will investigate about gh-pages though. Thanks! El martes, 15 de noviembre de 2016, 18:13:51

Re: [elm-discuss] Help for article review for SPA applications in Elm 0.18

I wonder if you could run the example on gh-pages? That way the links will work (instead of linking to localhost). I've not ever used the navigation & url-parser packages, so some of this was new to me. I like the way the program develops incrementally. Thanks for sharing! On Tue, Nov 15, 2016

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

It was indeed: https://groups.google.com/forum/#!topic/elm-discuss/ehtYLofp3TE Responses ranged from "I'd rather get rid of it" to "I like it, but I wouldn't complain if it went away." There was also a lovely tangent about Hoogle. Nobody was worried at that time that changing the syntax would

Re: [elm-discuss] 0.18 Below the Hood

On Tuesday, November 15, 2016 at 9:30:23 AM UTC-7, Max Goldstein wrote: > > My impression is that it's a Haskell extension that's very commonly used. > In the process of upgrading, I uncommented some signatures only for the > compiler to tell me that they are incorrect, so this feature has been

Re: [elm-discuss] 0.18 Below the Hood

My impression is that it's a Haskell extension that's very commonly used. In the process of upgrading, I uncommented some signatures only for the compiler to tell me that they are incorrect, so this feature has been useful already. Oh, and almost forgot: flipping the argument order for

Re: [elm-discuss] 0.18 Below the Hood

On Tuesday, November 15, 2016 at 8:57:30 AM UTC-7, John Orford wrote: > > let-bound values can be given type annotations that reference type > variables from the top level > > that's v thoughtful actually, I hadn't heard that before, just local > variables in any case, makes a lot of sense for

Re: [elm-discuss] 0.18 Below the Hood

> let-bound values can be given type annotations that reference type variables from the top level that's v thoughtful actually, I hadn't heard that before, just local variables in any case, makes a lot of sense for tricky functions. is this an elm specific creation or do you also see it in

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

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

[elm-discuss] Help for article review for SPA applications in Elm 0.18

Hi! I've written a post related how to do SPAs using elm 0.18. It starts from scratch, following the process I took while I was creating mine. I'm new in Elm and functional languages so I'd love to get your feedback. Also, I'm not a native English speaker so the text could have typos or

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

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

[elm-discuss] 0.18 Below the Hood

I'm personally looking forward to three longstanding bugs being fixed. First, recursive definitions like x = x are caught by the compiler. Second, a bug caching compiled forms of modules has been resolved, forcing a rebuild when necessary. Finally, let-bound values can be given type annotations

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

If someone was so tenuously commuted to Elm that this syntax removal drives them away, oh well. Yes, the Elm language is getting smaller. That's been true for a few releases now. Evan is trying to remove hurdles for new users (because we need a lot of new users!), not preserve legacy code (Elm

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

I'd agree with all that - but it was also trivially achievable in 0.17. Make no mistake, this is a *reduction* of the Elm language, the gamble being that it will result in more new users moving to and sticking with Elm, than existing users bailing in favour of some other alternative. I suspect

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

I really like the change (getting rid of an exceptional syntax), but what's more important is how other things adapts: see the example provided by Joey: >For example, if you want the range [0 .. n] for n in [0 .. k]: > > Old syntax: > map (\x -> [0 .. x]) [0 .. k] > New syntax: > map (Range 0)

Re: [elm-discuss] Elm 0.18: What's wrong with "number" type?

Two part answer: 1) Type-checking with number types has been partly broken for a while. See #1268 , #1270 , #1281 , #1316

[elm-discuss] Elm 0.18: What's wrong with "number" type?

I'm trying to upgrade ggb/elm-trend to Elm 0.18 but got stuck at this error message: -- TYPE MISMATCH -- src/Seasonal .elm The left argument of (>=) is causing a type mismatch. 101| index - period >= 0 ^^ (>=) is expecting

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

Lists are pretty core, I don't really have a problem with short expressive syntax that reads well. 'Well' meaning closer to reading like English. i.e I'd never say "I'll drink Bourbon on the range of days from 1 to 3, then Scotch on the days that range from day 4 to day 7". No way, it's just