Re: [elm-discuss] Re: Moving on

On Wed, Apr 26, 2017 at 5:17 AM, John Orford wrote: > My 2c on above... > > 1) web components - once they're a standard they will be a must. > > Perhaps they feel like a necessity now (I am sold) but they're still in a > flux, browsers support bits and pieces, some things

Re: [elm-discuss] Re: Moving on

I agree with a lot of this. I.e. 1) Long standing bugs are indefensible (although interestingly not complained about by Duane). Community contributions should be encouraged 2) Communication. Thing is, Evan is a good communicator. Perhaps a weekly or monthly blogpost would be prudent 3)

[elm-discuss] Re: view function to call other view function with different Msg type

> > Well, the problem is itemView can't be used , as it is 'Html ItemMsg', and > not 'Html Msg' > However, the Item module doesn't have access to 'Msg' ( which is top level > ), > Whenever I run into that problem, I create a separate file *MessageTypes.elm* with the Msg types in it and

Re: [elm-discuss] Re: Moving on

> > This will evolve, but see above, the constraint is that Elm remains > reliable... Which the lack of attention to bug fixes undermines. How long were there warnings that arrays had problems? How long has Elm sometimes generated bad code for cyclic definitions leading to runtime crashes? The

Re: [elm-discuss] Re: Moving on

My 2c on above... 1) web components - once they're a standard they will be a must. Perhaps they feel like a necessity now (I am sold) but they're still in a flux, browsers support bits and pieces, some things haven't been finalised yet. Angular / Reacts / Vue's ad hoc implementations for their

[elm-discuss] Re: Moving on

I have felt very much as Duane describes, powerless and at the mercy of the whims of a few unreachable No Red Ink devs. I could not contribute my elm-audio library and found myself frustrated by the lack of progress along many fronts. However, I have since come to reconsider this. The point is,

Re: [elm-discuss] Re: Moving on

On Tue, Apr 25, 2017 at 7:42 PM, Eirik Sletteberg wrote: > Since you mention pitch forks... > Maybe there's a potential for an Elm fork. > There are so many unexplored options that don't need any kind of fork of Elm. Reaching for something as drastic as a fork of the

Re: [elm-discuss] Re: Moving on

It's easy to be a silent observer when none of a thread applies to you. But I feel like I need to throw in here that Elm has been working great for the SPA I've been building. I transitioned to Elm from Ember 3 months ago and couldn't be happier. I also recognize that Elm is still a pre-1.0

[elm-discuss] Re: Moving on

I haven't found interop or missing FFI to be as problematic as some others it seems. First of all I don't think it makes much sense to embed Elm to JS if you can't reasonably shape surrounding JS system and it's API to elm. We're using svgs as well a lot for charting. Anyway since it's quite

Re: [elm-discuss] Re: Moving on

> > Does anybody has an idea how other languages/platforms manage to get > community involved? The elm community will grow organically if it's given the chance. However, to have a thriving and exciting community, at a minimum, developers need to be able to actively write, contribute and

Re: [elm-discuss] Re: Moving on

I was late to the Lua community — Lua 4.0 verging on 5.0 — but in some ways at a similar point or earlier to where Elm is trying to be given that at the time Lua conferences and talks at other conferences were not a common thing. Lua the language is controlled by three people with the

[elm-discuss] Re: Optimisation in Elm

Hello Ana! Since no one have commented more on this thread for some time I'll add some addition points to Peter's answer myself. First of all I think that you might misunderstand what tail recursion is but that's OK. I encourage you to look for some nice explanation on internet. I saw many

[elm-discuss] Re: Scaling Elm

I think having drop down component would be really valuable. Anyway I think that implementing some reusable component what ever complicated it might be is far from "scaling elm". Designing reusable parts of UI is not necessary same thing scaling application code base. -- You received this

Re: [elm-discuss] How to get typed-svg into elm-community?

Like I replied in that thread, open an issue at https://github.com/elm-community/manifesto and we will discuss there. Looks like one has already been created: https://github.com/elm-community/Manifesto/issues/69 On Tue, Apr 25, 2017 at 4:45 PM, 'Rupert Smith' via Elm Discuss

Re: [elm-discuss] Re: Moving on

On Tue, Apr 25, 2017 at 4:39 AM, Noah Hall wrote: > Open an issue here: https://github.com/elm-community/manifesto and we'll > discuss > Opened: https://github.com/elm-community/Manifesto/issues/69 -- You received this message because you are subscribed to the Google

[elm-discuss] How to get typed-svg into elm-community?

It would be good to get this moved to elm-community provided canadaduane is happy with that. I did not realize until I started using it that the elm-lang/svg is untyped Strings all the way, so it would seem worth re-writing a more strongly typed SVG library with a view to replacing the default

[elm-discuss] Re: Moving on

Hi folks. I really respect Duane's opinion and right to move on. Anyway since recently I've participated in some kind of dissolving of this community... *original thread: https://groups.google.com/forum/#!topic/elm-dev/iqErmKHnLDY

Re: [elm-discuss] Re: Moving on

On Tuesday, April 25, 2017 at 2:27:49 PM UTC+1, Wojtek Piekutowski wrote: > > The number of similar voices regarding community process and amount of > frequently requested missing features/native libraries (like binary support > and better JS interop) show a problem. No matter how amazing and

Re: [elm-discuss] Re: Moving on

The number of similar voices regarding community process and amount of frequently requested missing features/native libraries (like binary support and better JS interop) show a problem. No matter how amazing and performant Elm will ever be, newcomers will be discouraged by everlasting begging for

Re: [elm-discuss] Re: view function to call other view function with different Msg type

Maybe it will help you to know that I always return top level messages from my views. Like this: input [ type_ "checkbox" , checked form.queryAssignedOnly , onCheck (Msg.PayoutList << PayoutMsg.UpdateQueryAssignedOnly) ] Just for the record, the (Msg.PayoutList <<

Re: [elm-discuss] Unexpected parse error for reasonable code (Bug in parser?)

Thanks Dustin! On Saturday, April 22, 2017 at 3:27:01 PM UTC-4, Dustin Farris wrote: > > This is because the syntax for record updates does not allow you to update > nested records like what you are attempting. > > This is part of an ongoing discussion. There is a thread where you can > post

[elm-discuss] Re: Unexpected error when parsing what seems to be reasonable code (Bug in parser maybe?)

Thanks guys! Both responses were helpful. -- 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

[elm-discuss] Re: view function to call other view function with different Msg type

Hi, On Monday, April 24, 2017 at 10:54:28 PM UTC+5:30, Erik Lott wrote: > > Whoops. Html.map is correct... > Thanks for the answers. However I later ``discovered`` that the top Msg will have to include a id too , type Msg= ItemMsg IDType ItemMsg .. so things got more complicated.

Re: [elm-discuss] Re: Moving on

Open an issue here: https://github.com/elm-community/manifesto and we'll discuss On Tue, Apr 25, 2017 at 12:36 PM, 'Rupert Smith' via Elm Discuss wrote: > On Monday, April 24, 2017 at 4:59:43 PM UTC+1, Jakub Hampl wrote: >> >> Typed SVG is a fantastic and much

[elm-discuss] Re: Moving on

On Monday, April 24, 2017 at 4:59:43 PM UTC+1, Jakub Hampl wrote: > > Typed SVG is a fantastic and much needed project so I hope somebody takes > over. I wonder if elm-community would take it over? I'd be happy to review > pull requests and do some other light maintenance work, but unfortunately

[elm-discuss] Re: Error Messages can they be made more intuitive?

Sure Richard. Please find it posted at https://github.com/elm-lang/error-message-catalog/issues/216. And Thanks for making me aware about the error-message-catalog repo. Thanks. -- You received this message because you are subscribed to

[elm-discuss] Re: Error Messages can they be made more intuitive?

This is perfect for the error message catalog - if you have a sec, would you mind reposting as an issue there? Welcome to Elm! :D > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To