Re: [elm-discuss] Decoding JSON tree using Either type

Right, that fixed it. Reads better as well without somewhat arbitrary Left/Right nomenclature too. Thanks for you help! On Fri, Aug 19, 2016 at 7:58 PM, Nick H wrote: > Ah, I missed that kink. Type aliases are basically the compiler doing a > text search-and-replace.

Re: [elm-discuss] Decoding JSON tree using Either type

Ah, I missed that kink. Type aliases are basically the compiler doing a text search-and-replace. If you defined them recursively, the search-and-replace process would never end. Types are allowed to be recursive, but you can't simple replace the phrase "type alias" with "type", because they

Re: [elm-discuss] Decoding JSON tree using Either type

Hmm, that turns the type set back into mutually recursive, and so the compiler isn't happy with this setup either... On Friday, August 19, 2016 at 7:09:09 PM UTC-7, Nick H wrote: > > As it stands, you are defining two things called "Either": one is a type, > the other is a type constructor for

Re: [elm-discuss] Decoding JSON tree using Either type

As it stands, you are defining two things called "Either": one is a type, the other is a type constructor for Node. You need to change type Node = Either Group Datase to type alias Node = Either Group Dataset On Fri, Aug 19, 2016 at 6:55 PM, Dimitri Tcaciuc wrote: >

[elm-discuss] Decoding JSON tree using Either type

Hello, I'm trying to decode a tree structure where each node can either have children nodes or be a leaf and have data attached to it. Here are the types and a decoder I've come up with so far: type Either a b = Left a | Right b type Node = Either Group Dataset type alias Group = { nodes:

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

Let me try to state my concern in a different way. You say: The fact that class is only one of an arbitrary number of functions in > Html.Attributes isn't actually something the programmer should have to > think about > I completely agree with this! And it is exactly why I write "exposing

[elm-discuss] Re: Will server side elm be a game changer?

I don't see "server side" history in this thread, @Magnus Runderberget. Seems 0.18 isn't about the concern posted here. Em sexta-feira, 19 de agosto de 2016 18:49:20 UTC-3, Magnus Rundberget escreveu: > > Check out this thread : > https://groups.google.com/forum/m/#!topic/elm-dev/u66_K3AbqIM

[elm-discuss] Re: Will server side elm be a game changer?

Check out this thread : https://groups.google.com/forum/m/#!topic/elm-dev/u66_K3AbqIM -- 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] Re: Elm-mdl implementations - suggest projects that can be added to reference list

Hi Håkon, I have switched from React + Redux + Bootstrap to Elm + Elm Mdl my hobby project: *https://offtie.com/* Project allows to save urls to read later without data connection or in AirPlane Mode. Urls are parsed by www.readability.com and saved into LocalStorage.

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

It is something I have to worry about, because having 50+ useless functions with names like "id" and "title" imported into my default namespace is a recipe for naming collisions and confusing compiler errors. Supposing Html.Attributes had a function called "toString" that I didn't know or care

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

Just to be clear, this idea has now been prompted by a real problem: https://groups.google.com/d/msg/elm-discuss/-e27G4vwjGY/6N-RErBiBAAJ. Changing the way imports work like this would mean Elm could guarantee that problem couldn't happen, and make imports more pleasant to use to boot. Elm

Re: [elm-discuss] Re: Basic behavioral composition

As much as I love "don't overengineer it" as a principle, I'm not sure Richard's suggestion solves OP's problem. We want the possibility of NO label or NO icon, not just custom values. So that implies Maybe values in the record. Except, that opens the possibility of having neither an icon nor a

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

That's optimisation work that should be done by the compiler. The fact that class is only one of an arbitrary number of functions in Html.Attributes isn't actually something the programmer should have to think about. The compiler would look at the Html.Attributes you use in your file, find only

Re: [elm-discuss] Re: Debugging json decoders

Given this: ```elm onScroll tagger = on "scroll" (Json.Decode.map tagger decodeScrollPosition) ``` If you *always* want it to be called, and since we know in this case that the scroll javascript event will not return a negative number then you could do this for decodeScrollPosition: ```elm

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

Will, how would you propose to deal with selective imports? For example: import Html.Attributes exposing (class) This is a frequent usage for me. Html.Attributes has a bazillion things in it, and a lot of them are common words. I want to de-namespace "class" because I use it frequently, but not

Re: [elm-discuss] Re: Debugging json decoders

I am not sure I understand the answer. If you are talking about calling decode function then, as Jacob mentioned, it works in all cases but the one we're wondering about. Check this example: onScroll tagger = > on "scroll" (Json.Decode.map tagger decodeScrollPosition) Where

[elm-discuss] Re: Making imports more pleasant

I have an idea that I think is nice. Make writing List.map actually *do* what import List exposing (map) does, so you don't have to write import List at all. And if you want to use a function without a namespace, e.g. Html, import Html could do what import Html exposing (..) does now. On

Re: [elm-discuss] Human readable

On Wednesday, August 17, 2016 at 1:26:46 PM UTC-4, Ambrose Laing wrote: > > To everyone who wanted to have the elm-compiler produce line numbers and > column numbers that can help a traditional editor (like emacs for example) > to navigate to error locations: I discussed this a bit with Evan,

Re: [elm-discuss] Human readable

On Wednesday, August 17, 2016 at 1:26:46 PM UTC-4, Ambrose Laing wrote: > > To everyone who wanted to have the elm-compiler produce line numbers and > column numbers that can help a traditional editor (like emacs for example) > to navigate to error locations: I discussed this a bit with Evan,

Re: [elm-discuss] Re: Basic behavioral composition

Precisely, the thing like `MyButton.label` would return an appropriate instanced union holding whatever data you need. On Friday, August 19, 2016 at 12:58:10 PM UTC-6, Nick H wrote: > > I don't think Overmind's and Richard's inputs are at odds. Richard has > suggested an API. Overmind's code is

[elm-discuss] Re: Debugging json decoders

My emulator may help - http://simonh1000.github.io/decoder/ On Friday, 19 August 2016 19:56:05 UTC+2, OvermindDL1 wrote: On Friday, August 19, 2016 at 11:17:45 AM UTC-6, Sergey Zubtsovskiy wrote: >> >> Hey Jacob, >> >> Any update on this topic? I am facing the same issue, even in Elm 0.17

Re: [elm-discuss] Re: Basic behavioral composition

I don't think Overmind's and Richard's inputs are at odds. Richard has suggested an API. Overmind's code is what might fit into "-- Implementation goes here". On Fri, Aug 19, 2016 at 11:52 AM, Richard Feldman < richard.t.feld...@gmail.com> wrote: > `elm-mdl` is doing it that way because it is

[elm-discuss] Re: Basic behavioral composition

> > `elm-mdl` is doing it that way because it is trying to follow how Google's > material library works, and since there is no way to introspect into the > virtualnode's to change how they act then it has to wrap things up in that > pattern, I.E., VirtualNode limitations and Html.Attributes

[elm-discuss] Re: Basic behavioral composition

`elm-mdl` is doing it that way because it is trying to follow how Google's material library works, and since there is no way to introspect into the virtualnode's to change how they act then it has to wrap things up in that pattern, I.E., VirtualNode limitations and Html.Attributes limitations

[elm-discuss] Re: Basic behavioral composition

This is a great question! I think there's a very clear answer here: *Don't overengineer it.* As you noted, this is basic - *super* basic - so by default, the best solution is also super basic. There's a button with 2 configurable options? Cool, let's write a function that accepts that

[elm-discuss] Re: Basic behavioral composition

It sounds like you want a union type to represent the three possible buttons. You can have a view function that does case analysis and renders each possibility. Any shared code can be moved to a "let" definition, or another function. I mean, unless in missing something... -- You received

[elm-discuss] Re: Basic behavioral composition

Very interesting, thank you. Can you explain a bit more on the motives of that architecture and API, please? https://debois.github.io/elm-mdl/#buttons https://github.com/debois/elm-mdl/blob/master/demo/Demo/Buttons.elm On Friday, August 19, 2016 at 2:00:20 PM UTC-4, OvermindDL1 wrote: > >

[elm-discuss] Re: Will server side elm be a game changer?

I've been wondering about this myself. Would be interested in hearing what the core team thinks in terms of roadmap. -- 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

[elm-discuss] Re: Basic behavioral composition

You could invert it to compose instead of extend, so something like this: ```elm -- Button with a Label MyButton.view [ MyButton.label "blah" ] -- Button with an Icon MyButton.view [ MyButton.icon "iconId" ] -- Button with both MyButton.view [ MyButton.label "blah", MyButton.icon "iconId" ] ```

[elm-discuss] Basic behavioral composition

Apologies if this has been posted elsewhere, but I keep coming back to it. Let's get basic. Like *super *basic. I get a spec from a designer for a button with 3 types of children. 1. A button with a label only 2. A button with an icon only 3. A button with an icon *and* a label In

[elm-discuss] Re: Debugging json decoders

Hey Jacob, Any update on this topic? I am facing the same issue, even in Elm 0.17 with latest libraries... On Tuesday, November 3, 2015 at 11:16:53 PM UTC+1, Jacob Matthews wrote: > > > I've been playing with Elm recently. I really like it in general, but I > have had some pretty frustrating

[elm-discuss] Re: Code review request

I can see experimentally this is the case, but would someone mind spelling this out a bit for me? I think I don't understand * why the order of lines 55/56 matter * how HasX (HasXAndY {}) and HasXAndY (Has X a) could behave differently * what the error message is trying to say; what is the

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

It's worth saying that this issue will become more frequent as Elm's package number grows, not to mention more dangerous as Elm is used in more places. I don't think this should be handled by anything more optional than the compiler. On Friday, August 19, 2016 at 12:46:14 PM UTC+1, Janis

[elm-discuss] Re: Possible compiler bug?

> I have created my own Random.Pcg `together` and it compiles. Would you mind clarifying what you mean by this? -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [elm-discuss] Installing packages direct from github

Ah, good to know. A note in the readme would be good. On Friday, 19 August 2016 14:56:19 UTC+2, Janis Voigtländer wrote: > > Aside: For the specific case of > https://github.com/circuithub/elm-maybe-extra, you might more easily have > switched to https://github.com/elm-community/maybe-extra,

[elm-discuss] Installing packages direct from github

I've recently started using https://github.com/gdotdesign/elm-github-install in place of the usual package manager. It allows you to install dependencies direct from github whilst still handling the semantic versioning resolution. Here are some scenarios where this is really helpful 1) Fixing

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

Okay, I see the usability problem now. But I don’t think it calls for always importing with exposing (..). Maybe it does call for a warning to be issued in such situations by the compiler or by an optional code quality tool. ​ 2016-08-18 23:15 GMT+02:00 Will White : > In

[elm-discuss] Re: Remove ways of importing except `import exposing (..)`?

Namespacing everything actually makes import redundant. No more imports if you like to namespace everything. Then make import exposing (..) the new import. Well up for that! On Thursday, August 18, 2016 at 2:33:25 PM UTC+1, Will White wrote: > > import ModuleWithToString > > toString

[elm-discuss] Re: We need a clearer story on architecture

Thanks Richard and Erik for your input, I am taking this all onboard and giving it lots of thought. I think the next step for me is to experiment and refactor my app into a couple of different structures. That should give me a feel for what works well and what doesn't. Thanks again. On

[elm-discuss] Re: Possible compiler bug?

The namespaces get 'merged' - ie. if you do: module A exposing (a, b, c) --- module B exposing (d, e, f) --- module C exposing (..) import A import B as A then nothing's wrong - you can do A.a through to A.f without a problem. Problems happen when collision happens, ie. module B exposing (c)

[elm-discuss] Re: Possible compiler bug?

Why are duplicate imports allowed in the first place? On Friday, August 19, 2016 at 2:20:50 AM UTC-5, Martin Janiczek wrote: > > Hello, > > I've been stumped by a compiler error which I can't figure out. I think > it's a compiler bug. (I'd like to maybe help fix that and contribute a PR - >

Re: [elm-discuss] Possible compiler bug?

Shoot, you're right! (And I thought I checked for that.) I have created my own Random.Pcg `together` and it compiles. I will at least post this to *error-message-catalog* :) Thank you! On Friday, August 19, 2016 at 10:14:28 AM UTC+2, Nick H wrote: > > I think this error might have to do with

Re: [elm-discuss] Possible compiler bug?

I think this error might have to do with these two lines: import Random.Pcg as Random import Random.Extra as Random These two libraries are not designed to work together. Random.Extra works with the Generator type that is defined in the core library. Random.Pcg defines its own type called

[elm-discuss] Possible compiler bug?

Hello, I've been stumped by a compiler error which I can't figure out. I think it's a compiler bug. (I'd like to maybe help fix that and contribute a PR - even though it might get incorporated into elm-compiler wy later or not at all, I could have my own elm-compiler and continue on the