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

[Dimitri Tcaciuc]

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. 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 aren't the same thing.
>
> To make Node a type, you need to merge it with Either.
>
> type Node = Internal Group | Leaf Dataset
>
>
>
> On Fri, Aug 19, 2016 at 7:26 PM, Dimitri Tcaciuc 
> wrote:
>
>> 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 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:
>>>
 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: List Node
 }

 type alias Dataset = {
   data: List Int
 }


 decodeNode =
   ("type" := string) `andThen` (\t ->
 case t of
   "group" ->
 customDecoder ("nodes" := list decodeNode) (\nodes ->
   Left (Group nodes) |> Result.Ok
 )
   "dataset" ->
 customDecoder ("data" := list int) (\values ->
   Right (Dataset values) |> Result.Ok
 )
   )



 The full gist test data is at https://gist.github.com/dtc
 aciuc/d11b2737fa5d719faf0e5770f6f93e2e. The problem is the compiler
 doesn't seem to recognize that `Either Group Dataset` which `decodeNode`
 returns is equivalent to Node.

 Any ideas how to make this work?

 Thank you,

 --
 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/--XqhwCggQ8/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] Decoding JSON tree using Either type

[Nick H]

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 aren't the same thing.

To make Node a type, you need to merge it with Either.

type Node = Internal Group | Leaf Dataset



On Fri, Aug 19, 2016 at 7:26 PM, Dimitri Tcaciuc  wrote:

> 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 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:
>>
>>> 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: List Node
>>> }
>>>
>>> type alias Dataset = {
>>>   data: List Int
>>> }
>>>
>>>
>>> decodeNode =
>>>   ("type" := string) `andThen` (\t ->
>>> case t of
>>>   "group" ->
>>> customDecoder ("nodes" := list decodeNode) (\nodes ->
>>>   Left (Group nodes) |> Result.Ok
>>> )
>>>   "dataset" ->
>>> customDecoder ("data" := list int) (\values ->
>>>   Right (Dataset values) |> Result.Ok
>>> )
>>>   )
>>>
>>>
>>>
>>> The full gist test data is at https://gist.github.com/dtc
>>> aciuc/d11b2737fa5d719faf0e5770f6f93e2e. The problem is the compiler
>>> doesn't seem to recognize that `Either Group Dataset` which `decodeNode`
>>> returns is equivalent to Node.
>>>
>>> Any ideas how to make this work?
>>>
>>> Thank you,
>>>
>>> --
>>> 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] Decoding JSON tree using Either type

[Dimitri Tcaciuc]

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 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:
>
>> 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: List Node
>> }
>>
>> type alias Dataset = {
>>   data: List Int
>> }
>>
>>
>> decodeNode =
>>   ("type" := string) `andThen` (\t ->
>> case t of
>>   "group" ->
>> customDecoder ("nodes" := list decodeNode) (\nodes -> 
>>   Left (Group nodes) |> Result.Ok
>> )
>>   "dataset" ->
>> customDecoder ("data" := list int) (\values -> 
>>   Right (Dataset values) |> Result.Ok
>> )
>>   )
>>
>>
>>
>> The full gist test data is at 
>> https://gist.github.com/dtcaciuc/d11b2737fa5d719faf0e5770f6f93e2e. The 
>> problem is the compiler doesn't seem to recognize that `Either Group 
>> Dataset` which `decodeNode` returns is equivalent to Node.
>>
>> Any ideas how to make this work? 
>>
>> Thank you,
>>
>> -- 
>> 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] Decoding JSON tree using Either type

[Nick H]

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:

> 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: List Node
> }
>
> type alias Dataset = {
>   data: List Int
> }
>
>
> decodeNode =
>   ("type" := string) `andThen` (\t ->
> case t of
>   "group" ->
> customDecoder ("nodes" := list decodeNode) (\nodes ->
>   Left (Group nodes) |> Result.Ok
> )
>   "dataset" ->
> customDecoder ("data" := list int) (\values ->
>   Right (Dataset values) |> Result.Ok
> )
>   )
>
>
>
> The full gist test data is at https://gist.github.com/dtcaciuc/
> d11b2737fa5d719faf0e5770f6f93e2e. The problem is the compiler doesn't
> seem to recognize that `Either Group Dataset` which `decodeNode` returns is
> equivalent to Node.
>
> Any ideas how to make this work?
>
> Thank you,
>
> --
> 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.

[elm-discuss] Decoding JSON tree using Either type

[Dimitri Tcaciuc]

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: List Node
}

type alias Dataset = {
  data: List Int
}


decodeNode =
  ("type" := string) `andThen` (\t ->
case t of
  "group" ->
customDecoder ("nodes" := list decodeNode) (\nodes -> 
  Left (Group nodes) |> Result.Ok
)
  "dataset" ->
customDecoder ("data" := list int) (\values -> 
  Right (Dataset values) |> Result.Ok
)
  )



The full gist test data is 
at https://gist.github.com/dtcaciuc/d11b2737fa5d719faf0e5770f6f93e2e. The 
problem is the compiler doesn't seem to recognize that `Either Group 
Dataset` which `decodeNode` returns is equivalent to Node.

Any ideas how to make this work? 

Thank you,

-- 
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: Making imports more pleasant

[Nick H]

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
(class)" and not "exposing (..)". Because I am telling the compiler
"Whatever else is in Html.Attributes, I don't want to think about it. So
please leave it in its namespace where it won't get in my way." This
approach works whether class is the only function in the module, or if it
is one of millions.


On Fri, Aug 19, 2016 at 2:23 PM, Nick H  wrote:

> 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 about? Your proposal sounds like it will take the problem you
> are trying to solve and just make it worse.
>
> On Fri, Aug 19, 2016 at 2:13 PM, Will White 
> wrote:
>
>> 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 class, and do whatever import exposing (class) does now.
>>
>> On Friday, August 19, 2016 at 10:00:07 PM UTC+1, Nick H wrote:
>>>
>>> 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 the rest of that junk.
>>>
>>>
>>>
>>> On Fri, Aug 19, 2016 at 1:41 PM, Joey Eremondi 
>>> wrote:
>>>
 I had suggested something similar a while back:
 https://groups.google.com/forum/#!topic/elm-discuss/qJL51Kf8C2M

 The arguments against it are still valid.

 I don't think there's  widespread dissatisfaction with the import
 system as of 0.17, so I doubt it will change any time soon.

 On Fri, Aug 19, 2016 at 1:37 PM, Will White 
 wrote:

> 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 Saturday, February 7, 2015 at 5:17:50 PM UTC, Evan wrote:
>>
>> Since 0.14, I have been hearing more complaints about imports. Lots
>> of different proposals and discussions. Beginners struggling to 
>> understand
>> how the different variations fit together. After hearing Laszlo's take on
>> this, I am trying out a new syntax and semantics
>> 
>> .
>>
>> Here are all the variations of the *syntax*:
>>
>> import List
>> import List exposing (map, filter)
>> import List exposing (..)
>>
>> import List as L
>> import List as L exposing (map, filter)
>> import List as L exposing (..)
>>
>> The most important change is in *semantics* though. In cases 1-3 you
>> are able to refer to anything in the List module as List.member and
>> List.isEmpty. So importing a module implies that you want to be able
>> to use it's name to qualify all of its values.
>>
>> In cases 4-6, it is the same except you can qualify with L but not
>> List. Why hide List though? There may come a time when you don't
>> want name overlaps with modules, so this makes it possible to avoid
>> collisions.
>>
>> Overall, I think this meets my goals for this change:
>>
>>- All imports are explicit and easy to find. No one can introduce
>>a dependency on line 1500 of a file.
>>- There will be less duplication in the import section. No
>>importing the same thing twice in different ways.
>>- It will be easier to understand for beginners.
>>- It somewhat discourages exposing by making it longer.
>>
>> *Remaining Questions:*
>> *1) *What happens when there are multiple imports of the same module?
>>
>>- *a)* Sean proposed making everything additive
>>. This would
>>make hiding any defaults impossible.
>>- *b)* Maybe we can just disallow multiple imports of the same
>>module?
>>
>> *2)* How this should interact with the current default 

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

[Aislan de Sousa Maia]

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

-- 
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: Will server side elm be a game changer?

[Magnus Rundberget]

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Elm-mdl implementations - suggest projects that can be added to reference list

[Dmytro Gladkyi]

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.

Site uses Service Workers (in JS) to cache all site resources so they are 
available offline (works in Chrome, FF).

*UI+backend connection is all in Elm + Elm Mdl. *Main.elm is 220 lines. Can 
be reduced to 150.
*LocalStorage stuff is done via ports.*

Minified and gzipped bundle is in 5 times smaller than React + Redux 
version.

Minified gzipped Elm bundle is 42Kb + 26Kb material design css.

React bundle (babelify + minify + gzip) was about 200Kb. + 70Kb bootstrap.

On Tuesday, August 16, 2016 at 11:33:35 AM UTC+3, Håkon Rossebø wrote:
>
> Elm-mdl  - is getting more usage in 
> various applications/projects. To improve documentation, we want to create 
> a list of implementations - all kinds - simple to complex and use it as a 
> reference on elm-mdl . I would 
> appreciate if people could suggest any implementations that can be added to 
> this list.
>
> If you know any projects/applications/repositories - reply to this thread.
>

-- 
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: Making imports more pleasant

[Nick H]

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 about? Your proposal sounds like it will take the problem you
are trying to solve and just make it worse.

On Fri, Aug 19, 2016 at 2:13 PM, Will White  wrote:

> 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 class, and do whatever import exposing (class) does now.
>
> On Friday, August 19, 2016 at 10:00:07 PM UTC+1, Nick H wrote:
>>
>> 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 the rest of that junk.
>>
>>
>>
>> On Fri, Aug 19, 2016 at 1:41 PM, Joey Eremondi 
>> wrote:
>>
>>> I had suggested something similar a while back:
>>> https://groups.google.com/forum/#!topic/elm-discuss/qJL51Kf8C2M
>>>
>>> The arguments against it are still valid.
>>>
>>> I don't think there's  widespread dissatisfaction with the import system
>>> as of 0.17, so I doubt it will change any time soon.
>>>
>>> On Fri, Aug 19, 2016 at 1:37 PM, Will White  wrote:
>>>
 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 Saturday, February 7, 2015 at 5:17:50 PM UTC, Evan wrote:
>
> Since 0.14, I have been hearing more complaints about imports. Lots of
> different proposals and discussions. Beginners struggling to understand 
> how
> the different variations fit together. After hearing Laszlo's take on 
> this, I
> am trying out a new syntax and semantics
> 
> .
>
> Here are all the variations of the *syntax*:
>
> import List
> import List exposing (map, filter)
> import List exposing (..)
>
> import List as L
> import List as L exposing (map, filter)
> import List as L exposing (..)
>
> The most important change is in *semantics* though. In cases 1-3 you
> are able to refer to anything in the List module as List.member and
> List.isEmpty. So importing a module implies that you want to be able
> to use it's name to qualify all of its values.
>
> In cases 4-6, it is the same except you can qualify with L but not
> List. Why hide List though? There may come a time when you don't want
> name overlaps with modules, so this makes it possible to avoid collisions.
>
> Overall, I think this meets my goals for this change:
>
>- All imports are explicit and easy to find. No one can introduce
>a dependency on line 1500 of a file.
>- There will be less duplication in the import section. No
>importing the same thing twice in different ways.
>- It will be easier to understand for beginners.
>- It somewhat discourages exposing by making it longer.
>
> *Remaining Questions:*
> *1) *What happens when there are multiple imports of the same module?
>
>- *a)* Sean proposed making everything additive
>. This would
>make hiding any defaults impossible.
>- *b)* Maybe we can just disallow multiple imports of the same
>module?
>
> *2)* How this should interact with the current default imports
> ?
>
>- *a)* Anyone can refer to Basics, List, Maybe, Result, and Signal
>from anywhere? Seems weird.
>- *b)* Certain values are exposed, but the modules are not
>available for making things qualified.
>
> It seems like 1.b and 2.a fit together best. We could make it so
> user-defined imports always override default imports and there are no
> duplicate user-defined imports.
>
> But maybe there are other alternatives?
>
 --
 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] Re: Making imports more pleasant

[Will White]

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 
*does* require that filenames and module names match, so I'm not sure why 
Evan mentioned that then.

On Friday, August 19, 2016 at 9:41:05 PM UTC+1, Joey Eremondi wrote:
>
> I had suggested something similar a while back: 
> https://groups.google.com/forum/#!topic/elm-discuss/qJL51Kf8C2M
>
> The arguments against it are still valid.
>
> I don't think there's  widespread dissatisfaction with the import system 
> as of 0.17, so I doubt it will change any time soon.
>
> On Fri, Aug 19, 2016 at 1:37 PM, Will White  > wrote:
>
>> 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 Saturday, February 7, 2015 at 5:17:50 PM UTC, Evan wrote:
>>>
>>> Since 0.14, I have been hearing more complaints about imports. Lots of 
>>> different proposals and discussions. Beginners struggling to understand how 
>>> the different variations fit together. After hearing Laszlo's take on this, 
>>> I 
>>> am trying out a new syntax and semantics 
>>> 
>>> .
>>>
>>> Here are all the variations of the *syntax*:
>>>
>>> import List
>>> import List exposing (map, filter)
>>> import List exposing (..)
>>>
>>> import List as L
>>> import List as L exposing (map, filter)
>>> import List as L exposing (..)
>>>
>>> The most important change is in *semantics* though. In cases 1-3 you 
>>> are able to refer to anything in the List module as List.member and 
>>> List.isEmpty. So importing a module implies that you want to be able to 
>>> use it's name to qualify all of its values.
>>>
>>> In cases 4-6, it is the same except you can qualify with L but not List. 
>>> Why hide List though? There may come a time when you don't want name 
>>> overlaps with modules, so this makes it possible to avoid collisions.
>>>
>>> Overall, I think this meets my goals for this change:
>>>
>>>- All imports are explicit and easy to find. No one can introduce a 
>>>dependency on line 1500 of a file.
>>>- There will be less duplication in the import section. No importing 
>>>the same thing twice in different ways.
>>>- It will be easier to understand for beginners.
>>>- It somewhat discourages exposing by making it longer.
>>>
>>> *Remaining Questions:*
>>> *1) *What happens when there are multiple imports of the same module?
>>>
>>>- *a)* Sean proposed making everything additive 
>>>. This would 
>>>make hiding any defaults impossible.
>>>- *b)* Maybe we can just disallow multiple imports of the same 
>>>module?
>>>
>>> *2)* How this should interact with the current default imports 
>>> ?
>>>
>>>- *a)* Anyone can refer to Basics, List, Maybe, Result, and Signal 
>>>from anywhere? Seems weird.
>>>- *b)* Certain values are exposed, but the modules are not available 
>>>for making things qualified.
>>>
>>> It seems like 1.b and 2.a fit together best. We could make it so 
>>> user-defined imports always override default imports and there are no 
>>> duplicate user-defined imports.
>>>
>>> But maybe there are other alternatives?
>>>
>> -- 
>> 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: Basic behavioral composition

[Max Goldstein]

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 string. So 
that leads me back to the union type I suggested above. (A function that takes 
a list will similarly have to contend with the empty list.)

-- 
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: Making imports more pleasant

[Will White]

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 
class, and do whatever import exposing (class) does now.

On Friday, August 19, 2016 at 10:00:07 PM UTC+1, Nick H wrote:
>
> 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 the rest of that junk.
>
>
>
> On Fri, Aug 19, 2016 at 1:41 PM, Joey Eremondi  > wrote:
>
>> I had suggested something similar a while back: 
>> https://groups.google.com/forum/#!topic/elm-discuss/qJL51Kf8C2M
>>
>> The arguments against it are still valid.
>>
>> I don't think there's  widespread dissatisfaction with the import system 
>> as of 0.17, so I doubt it will change any time soon.
>>
>> On Fri, Aug 19, 2016 at 1:37 PM, Will White > > wrote:
>>
>>> 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 Saturday, February 7, 2015 at 5:17:50 PM UTC, Evan wrote:

 Since 0.14, I have been hearing more complaints about imports. Lots of 
 different proposals and discussions. Beginners struggling to understand 
 how 
 the different variations fit together. After hearing Laszlo's take on 
 this, I 
 am trying out a new syntax and semantics 
 
 .

 Here are all the variations of the *syntax*:

 import List
 import List exposing (map, filter)
 import List exposing (..)

 import List as L
 import List as L exposing (map, filter)
 import List as L exposing (..)

 The most important change is in *semantics* though. In cases 1-3 you 
 are able to refer to anything in the List module as List.member and 
 List.isEmpty. So importing a module implies that you want to be able 
 to use it's name to qualify all of its values.

 In cases 4-6, it is the same except you can qualify with L but not List. 
 Why hide List though? There may come a time when you don't want name 
 overlaps with modules, so this makes it possible to avoid collisions.

 Overall, I think this meets my goals for this change:

- All imports are explicit and easy to find. No one can introduce a 
dependency on line 1500 of a file.
- There will be less duplication in the import section. No 
importing the same thing twice in different ways.
- It will be easier to understand for beginners.
- It somewhat discourages exposing by making it longer.

 *Remaining Questions:*
 *1) *What happens when there are multiple imports of the same module?

- *a)* Sean proposed making everything additive 
. This would 
make hiding any defaults impossible.
- *b)* Maybe we can just disallow multiple imports of the same 
module?

 *2)* How this should interact with the current default imports 
 ?

- *a)* Anyone can refer to Basics, List, Maybe, Result, and Signal 
from anywhere? Seems weird.
- *b)* Certain values are exposed, but the modules are not 
available for making things qualified.

 It seems like 1.b and 2.a fit together best. We could make it so 
 user-defined imports always override default imports and there are no 
 duplicate user-defined imports.

 But maybe there are other alternatives?

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

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

[OvermindDL1]

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
decodeScrollPosition =
  Json.Decode.oneOf
[ Json.Decoder.int
, Json.Decoder.succeed -1
]
```

Or you could parse out a `Maybe Int`, or you could parse out a structure if 
you want a more stuff.  Etc...  :-)


On Friday, August 19, 2016 at 2:45:32 PM UTC-6, Sergey Zubtsovskiy wrote:
>
> 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 decodeScrollPosition is:
>
>> decodeScrollPosition : Json.Decode.Decoder Int
>
>
> "on" function is only accepting value of type Json.Decode.Decoder. If I 
> was decoding myself (e.g. by calling Json.Decode.decodeString) I would get 
> a Result and process it the way you mention. But in case of an event 
> listener decoding is happening somewhere within Elm runtime which silently 
> swallows error. If I, for example, misspell event's field name, nothing 
> will happen. No runtime error (that's still valid), but no result either.
>
> I am wondering if I am missing something. To my mind it does not fit to 
> the whole impression Elm's trying to create. And I am a bit confused.
>
> Sergey Zubtsovskiy
> sergey.zu...@gmail.com 
> Skype: szubtsovskiy
>
>
> 2016-08-19 21:31 GMT+02:00 Simon :
>
>> 
>> 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 
 with latest libraries...

>>>
>>> You can setup multiple branches in a decode so it one fails then you can 
>>> fall back to a default value so it still passes.  You could even return a 
>>> Maybe and return a default value of Nothing if you want, wrapping the main 
>>> decode branch in a Just.
>>>
>> ​
>>
>> -- 
>> 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: Making imports more pleasant

[Nick H]

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 the rest of that junk.



On Fri, Aug 19, 2016 at 1:41 PM, Joey Eremondi 
wrote:

> I had suggested something similar a while back: https://groups.google.com/
> forum/#!topic/elm-discuss/qJL51Kf8C2M
>
> The arguments against it are still valid.
>
> I don't think there's  widespread dissatisfaction with the import system
> as of 0.17, so I doubt it will change any time soon.
>
> On Fri, Aug 19, 2016 at 1:37 PM, Will White 
> wrote:
>
>> 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 Saturday, February 7, 2015 at 5:17:50 PM UTC, Evan wrote:
>>>
>>> Since 0.14, I have been hearing more complaints about imports. Lots of
>>> different proposals and discussions. Beginners struggling to understand how
>>> the different variations fit together. After hearing Laszlo's take on this, 
>>> I
>>> am trying out a new syntax and semantics
>>> 
>>> .
>>>
>>> Here are all the variations of the *syntax*:
>>>
>>> import List
>>> import List exposing (map, filter)
>>> import List exposing (..)
>>>
>>> import List as L
>>> import List as L exposing (map, filter)
>>> import List as L exposing (..)
>>>
>>> The most important change is in *semantics* though. In cases 1-3 you
>>> are able to refer to anything in the List module as List.member and
>>> List.isEmpty. So importing a module implies that you want to be able to
>>> use it's name to qualify all of its values.
>>>
>>> In cases 4-6, it is the same except you can qualify with L but not List.
>>> Why hide List though? There may come a time when you don't want name
>>> overlaps with modules, so this makes it possible to avoid collisions.
>>>
>>> Overall, I think this meets my goals for this change:
>>>
>>>- All imports are explicit and easy to find. No one can introduce a
>>>dependency on line 1500 of a file.
>>>- There will be less duplication in the import section. No importing
>>>the same thing twice in different ways.
>>>- It will be easier to understand for beginners.
>>>- It somewhat discourages exposing by making it longer.
>>>
>>> *Remaining Questions:*
>>> *1) *What happens when there are multiple imports of the same module?
>>>
>>>- *a)* Sean proposed making everything additive
>>>. This would
>>>make hiding any defaults impossible.
>>>- *b)* Maybe we can just disallow multiple imports of the same
>>>module?
>>>
>>> *2)* How this should interact with the current default imports
>>> ?
>>>
>>>- *a)* Anyone can refer to Basics, List, Maybe, Result, and Signal
>>>from anywhere? Seems weird.
>>>- *b)* Certain values are exposed, but the modules are not available
>>>for making things qualified.
>>>
>>> It seems like 1.b and 2.a fit together best. We could make it so
>>> user-defined imports always override default imports and there are no
>>> duplicate user-defined imports.
>>>
>>> But maybe there are other alternatives?
>>>
>> --
>> 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: Debugging json decoders

[Sergey Zubtsovskiy]

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 decodeScrollPosition is:

> decodeScrollPosition : Json.Decode.Decoder Int


"on" function is only accepting value of type Json.Decode.Decoder. If I was
decoding myself (e.g. by calling Json.Decode.decodeString) I would get a
Result and process it the way you mention. But in case of an event listener
decoding is happening somewhere within Elm runtime which silently swallows
error. If I, for example, misspell event's field name, nothing will happen.
No runtime error (that's still valid), but no result either.

I am wondering if I am missing something. To my mind it does not fit to the
whole impression Elm's trying to create. And I am a bit confused.

Sergey Zubtsovskiy
sergey.zubtsovs...@gmail.com
Skype: szubtsovskiy


2016-08-19 21:31 GMT+02:00 Simon :

> 
> 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
>>> with latest libraries...
>>>
>>
>> You can setup multiple branches in a decode so it one fails then you can
>> fall back to a default value so it still passes.  You could even return a
>> Maybe and return a default value of Nothing if you want, wrapping the main
>> decode branch in a Just.
>>
> ​
>
> --
> 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.

[elm-discuss] Re: Making imports more pleasant

[Will White]

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 Saturday, February 7, 2015 at 5:17:50 PM UTC, Evan wrote:
>
> Since 0.14, I have been hearing more complaints about imports. Lots of 
> different proposals and discussions. Beginners struggling to understand how 
> the different variations fit together. After hearing Laszlo's take on this, I 
> am trying out a new syntax and semantics 
> 
> .
>
> Here are all the variations of the *syntax*:
>
> import List
> import List exposing (map, filter)
> import List exposing (..)
>
> import List as L
> import List as L exposing (map, filter)
> import List as L exposing (..)
>
> The most important change is in *semantics* though. In cases 1-3 you are 
> able to refer to anything in the List module as List.member and 
> List.isEmpty. So importing a module implies that you want to be able to 
> use it's name to qualify all of its values.
>
> In cases 4-6, it is the same except you can qualify with L but not List. 
> Why hide List though? There may come a time when you don't want name 
> overlaps with modules, so this makes it possible to avoid collisions.
>
> Overall, I think this meets my goals for this change:
>
>- All imports are explicit and easy to find. No one can introduce a 
>dependency on line 1500 of a file.
>- There will be less duplication in the import section. No importing 
>the same thing twice in different ways.
>- It will be easier to understand for beginners.
>- It somewhat discourages exposing by making it longer.
>
> *Remaining Questions:*
> *1) *What happens when there are multiple imports of the same module?
>
>- *a)* Sean proposed making everything additive 
>. This would make 
>hiding any defaults impossible.
>- *b)* Maybe we can just disallow multiple imports of the same module?
>
> *2)* How this should interact with the current default imports 
> ?
>
>- *a)* Anyone can refer to Basics, List, Maybe, Result, and Signal 
>from anywhere? Seems weird.
>- *b)* Certain values are exposed, but the modules are not available 
>for making things qualified.
>
> It seems like 1.b and 2.a fit together best. We could make it so 
> user-defined imports always override default imports and there are no 
> duplicate user-defined imports.
>
> But maybe there are other alternatives?
>

-- 
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] Human readable

[Robert]

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, and he 
> suggested working with the json output, so then I came up with this 
> solution for now:
>
> Please see: http://github.com/aklaing/call-elm-make
>

This idea is good but as you note in your README, the implementation has 
issues.  To be most useful, it needs to be part of the mainline Elm 
distribution.  All the options are not necessary.  Simply output the full 
pathname, line number and column number on one line in the same format as 
this package is doing and then many different editors could process it. 
 Error formats for translators should not be produced by 3rd-party plugins 
if you hope to have them utilized by many users of the translator.

Bob

-- 
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] Human readable

[Robert]

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, and he 
> suggested working with the json output, so then I came up with this 
> solution for now:
>
> Please see: http://github.com/aklaing/call-elm-make
>

This is great and what is needed.  Why not have the capability be a 
standard part of Elm?

Bob

-- 
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: Basic behavioral composition

[OvermindDL1]

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 what might fit into "-- Implementation 
> goes here".
>
> On Fri, Aug 19, 2016 at 11:52 AM, Richard Feldman  > wrote:
>
>> `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 require it to be this noisy.  :-)
>>>
>>
>> Yeah, elm-mdl has very specific and unusual design goals (in part 
>> because of ways MDL differs from other UI frameworks, and in part because 
>> of the author's goal for how to present MDL in a DSL) that make it 
>> substantially different from every other project in the Elm world...I would 
>> not look at its design and think "ah, this is probably what I want to do 
>> for my project!" because the opposite is far more likely. :)
>>
>> -- 
>> 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.

[elm-discuss] Re: Debugging json decoders

[Simon]

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 
>> with latest libraries...
>>
>
> You can setup multiple branches in a decode so it one fails then you can 
> fall back to a default value so it still passes.  You could even return a 
> Maybe and return a default value of Nothing if you want, wrapping the main 
> decode branch in a Just.
>
​

-- 
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: Basic behavioral composition

[Nick H]

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 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
>> require it to be this noisy.  :-)
>>
>
> Yeah, elm-mdl has very specific and unusual design goals (in part because
> of ways MDL differs from other UI frameworks, and in part because of the
> author's goal for how to present MDL in a DSL) that make it substantially
> different from every other project in the Elm world...I would not look at
> its design and think "ah, this is probably what I want to do for my
> project!" because the opposite is far more likely. :)
>
> --
> 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.

[elm-discuss] Re: Basic behavioral composition

[Richard Feldman]

>
> `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 
> require it to be this noisy.  :-)
>

Yeah, elm-mdl has very specific and unusual design goals (in part because 
of ways MDL differs from other UI frameworks, and in part because of the 
author's goal for how to present MDL in a DSL) that make it substantially 
different from every other project in the Elm world...I would not look at 
its design and think "ah, this is probably what I want to do for my 
project!" because the opposite is far more likely. :)

-- 
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: Basic behavioral composition

[OvermindDL1]

`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 
require it to be this noisy.  :-)

On Friday, August 19, 2016 at 12:08:14 PM UTC-6, suttlecommakevin wrote:
>
> 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:
>>
>> 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" ]
>> ```
>>
>> You can easily enforce the icon to always render before the label is that 
>> is a requirement, regardless of position in the list, etc... etc...
>>
>> This is how the `elm-mdl` package works for example.
>>
>>
>> On Friday, August 19, 2016 at 11:46:30 AM UTC-6, suttlecommakevin wrote:
>>>
>>> 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 a object-oriented programming environment, you could make a 
>>> ButtonBase class and extend it. 
>>> In React's bizarro world, they try to promote this Higher-order 
>>> Components technique, which is really just a function factory.
>>> In Flow, you can at least start making types, and then, share and 
>>> intersect  them. 
>>>
>>>
>>> *ButtonProps.js*
>>>
>>> // @flow
>>> /* eslint-disable import/prefer-default-export */
>>>
>>> export type ButtonProps = {
>>>   type?: 'button' | 'reset' | 'submit',
>>>   design: 'primary' | 'secondary',
>>>   className?: string,
>>>   children?: Array,
>>>   onClick?: () => void,
>>>   onFocus?: () => void,
>>>   onmouseover?: () => void,
>>>   onmouseout?: () => void,
>>> }
>>>
>>>
>>> *Button.jsx*
>>>
>>> // @flow
>>>
>>> import React from 'react';
>>> import type { ButtonProps } from './ButtonProps';
>>> import './Button.css';
>>>
>>> /* eslint-disable flowtype/space-after-type-colon */
>>> const Button = ({
>>>   design = 'primary',
>>>   className = 'btn',
>>>   type = 'button',
>>>   children } :ButtonProps) =>
>>>
>>>   
>>> {children}
>>>   ;
>>>
>>> export default Button;
>>>
>>>
>>> *Icon.jsx*
>>>
>>> // @flow
>>>
>>> import React from 'react';
>>> import Button from './Button.jsx';
>>> import type { ButtonProps } from './ButtonProps';
>>> import Icon from '../Icons/Icon.jsx';
>>> import type { IconProps } from '../Icons/IconProps';
>>>
>>> type IconButtonProps = ButtonProps & IconProps;
>>>
>>> const IconButton = (props: IconButtonProps) =>
>>>   >> design={props.design}
>>> onClick={props.onClick}
>>> className={`iconBtn ${props.className}`}
>>>   >
>>> 
>>>   ;
>>>
>>> export default IconButton;
>>>
>>>
>>> Notice this line: type IconButtonProps = ButtonProps & IconProps; which 
>>> is just a fancy Object.assign() really. 
>>> It's easy to read, easy to understand, but many would claim it doesn't 
>>> follow "best practices".
>>>
>>>
>>> My question is, how would Elm/FP handle this? 
>>>
>>>
>>>
>>> Thanks, folks. 
>>>
>>

-- 
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: Basic behavioral composition

[Richard Feldman]

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 configuration and returns the button we need:

fancyButton : { label : String, icon : String } -> Html msg
fancyButton { label, icon } =
-- Implementation goes here

Done!

In a language where refactoring is nice, you can and should reach for 
simple solutions when the problem is simple.

If the problem gets more complex later, you can then revise from a position 
of knowledge: you'll know *precisely how *it's more complicated, and that 
gives you the information you need to end up with the nicest API possible.

Conversely, trying to design an API to fit nebulous theoretical future use 
cases essentially means going in blind, and it's a recipe for unnecessary 
suffering in 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.

[elm-discuss] Re: Basic behavioral composition

[Max Goldstein]

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 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: Basic behavioral composition

[suttlecommakevin]

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:
>
> 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" ]
> ```
>
> You can easily enforce the icon to always render before the label is that 
> is a requirement, regardless of position in the list, etc... etc...
>
> This is how the `elm-mdl` package works for example.
>
>
> On Friday, August 19, 2016 at 11:46:30 AM UTC-6, suttlecommakevin wrote:
>>
>> 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 a object-oriented programming environment, you could make a ButtonBase 
>> class and extend it. 
>> In React's bizarro world, they try to promote this Higher-order 
>> Components technique, which is really just a function factory.
>> In Flow, you can at least start making types, and then, share and 
>> intersect  them. 
>>
>>
>> *ButtonProps.js*
>>
>> // @flow
>> /* eslint-disable import/prefer-default-export */
>>
>> export type ButtonProps = {
>>   type?: 'button' | 'reset' | 'submit',
>>   design: 'primary' | 'secondary',
>>   className?: string,
>>   children?: Array,
>>   onClick?: () => void,
>>   onFocus?: () => void,
>>   onmouseover?: () => void,
>>   onmouseout?: () => void,
>> }
>>
>>
>> *Button.jsx*
>>
>> // @flow
>>
>> import React from 'react';
>> import type { ButtonProps } from './ButtonProps';
>> import './Button.css';
>>
>> /* eslint-disable flowtype/space-after-type-colon */
>> const Button = ({
>>   design = 'primary',
>>   className = 'btn',
>>   type = 'button',
>>   children } :ButtonProps) =>
>>
>>   
>> {children}
>>   ;
>>
>> export default Button;
>>
>>
>> *Icon.jsx*
>>
>> // @flow
>>
>> import React from 'react';
>> import Button from './Button.jsx';
>> import type { ButtonProps } from './ButtonProps';
>> import Icon from '../Icons/Icon.jsx';
>> import type { IconProps } from '../Icons/IconProps';
>>
>> type IconButtonProps = ButtonProps & IconProps;
>>
>> const IconButton = (props: IconButtonProps) =>
>>   > design={props.design}
>> onClick={props.onClick}
>> className={`iconBtn ${props.className}`}
>>   >
>> 
>>   ;
>>
>> export default IconButton;
>>
>>
>> Notice this line: type IconButtonProps = ButtonProps & IconProps; which 
>> is just a fancy Object.assign() really. 
>> It's easy to read, easy to understand, but many would claim it doesn't 
>> follow "best practices".
>>
>>
>> My question is, how would Elm/FP handle this? 
>>
>>
>>
>> Thanks, folks. 
>>
>

-- 
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: Will server side elm be a game changer?

[suttlecommakevin]

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 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Basic behavioral composition

[OvermindDL1]

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" ]
```

You can easily enforce the icon to always render before the label is that 
is a requirement, regardless of position in the list, etc... etc...

This is how the `elm-mdl` package works for example.


On Friday, August 19, 2016 at 11:46:30 AM UTC-6, suttlecommakevin wrote:
>
> 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 a object-oriented programming environment, you could make a ButtonBase 
> class and extend it. 
> In React's bizarro world, they try to promote this Higher-order Components 
> technique, which is really just a function factory.
> In Flow, you can at least start making types, and then, share and 
> intersect  them. 
>
>
> *ButtonProps.js*
>
> // @flow
> /* eslint-disable import/prefer-default-export */
>
> export type ButtonProps = {
>   type?: 'button' | 'reset' | 'submit',
>   design: 'primary' | 'secondary',
>   className?: string,
>   children?: Array,
>   onClick?: () => void,
>   onFocus?: () => void,
>   onmouseover?: () => void,
>   onmouseout?: () => void,
> }
>
>
> *Button.jsx*
>
> // @flow
>
> import React from 'react';
> import type { ButtonProps } from './ButtonProps';
> import './Button.css';
>
> /* eslint-disable flowtype/space-after-type-colon */
> const Button = ({
>   design = 'primary',
>   className = 'btn',
>   type = 'button',
>   children } :ButtonProps) =>
>
>   
> {children}
>   ;
>
> export default Button;
>
>
> *Icon.jsx*
>
> // @flow
>
> import React from 'react';
> import Button from './Button.jsx';
> import type { ButtonProps } from './ButtonProps';
> import Icon from '../Icons/Icon.jsx';
> import type { IconProps } from '../Icons/IconProps';
>
> type IconButtonProps = ButtonProps & IconProps;
>
> const IconButton = (props: IconButtonProps) =>
>design={props.design}
> onClick={props.onClick}
> className={`iconBtn ${props.className}`}
>   >
> 
>   ;
>
> export default IconButton;
>
>
> Notice this line: type IconButtonProps = ButtonProps & IconProps; which 
> is just a fancy Object.assign() really. 
> It's easy to read, easy to understand, but many would claim it doesn't 
> follow "best practices".
>
>
> My question is, how would Elm/FP handle this? 
>
>
>
> Thanks, folks. 
>

-- 
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] Basic behavioral composition

[suttlecommakevin]

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 a object-oriented programming environment, you could make a ButtonBase 
class and extend it. 
In React's bizarro world, they try to promote this Higher-order Components 
technique, which is really just a function factory.
In Flow, you can at least start making types, and then, share and intersect 
 them. 


*ButtonProps.js*

// @flow
/* eslint-disable import/prefer-default-export */

export type ButtonProps = {
  type?: 'button' | 'reset' | 'submit',
  design: 'primary' | 'secondary',
  className?: string,
  children?: Array,
  onClick?: () => void,
  onFocus?: () => void,
  onmouseover?: () => void,
  onmouseout?: () => void,
}


*Button.jsx*

// @flow

import React from 'react';
import type { ButtonProps } from './ButtonProps';
import './Button.css';

/* eslint-disable flowtype/space-after-type-colon */
const Button = ({
  design = 'primary',
  className = 'btn',
  type = 'button',
  children } :ButtonProps) =>

  
{children}
  ;

export default Button;


*Icon.jsx*

// @flow

import React from 'react';
import Button from './Button.jsx';
import type { ButtonProps } from './ButtonProps';
import Icon from '../Icons/Icon.jsx';
import type { IconProps } from '../Icons/IconProps';

type IconButtonProps = ButtonProps & IconProps;

const IconButton = (props: IconButtonProps) =>
  

  ;

export default IconButton;


Notice this line: type IconButtonProps = ButtonProps & IconProps; which is 
just a fancy Object.assign() really. 
It's easy to read, easy to understand, but many would claim it doesn't 
follow "best practices".


My question is, how would Elm/FP handle this? 



Thanks, folks. 

-- 
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: Debugging json decoders

[Sergey Zubtsovskiy]

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 experiences debugging Json.Decode.Decoder 
> failures, especially while handling browser events using Html.Events.on.
>
> For instance, suppose we want to write a decoder that reads the selected 
> index within a  element. We might write:
>
> import Json.Decode exposing (..)
>
> ...
>
> decodeSelectedIndex : Decoder string
> decodeSelectedIndex = at ["action", "selectedIndex"] string  -- oops! 
> selectedIndex is an int!
>
> renderSelect : Html
> renderSelect = 
>   select 
> [ on "change" decodeSelectedIndex someHandler ]
> [ ... ]
>   
> The problem here is that the decoder doesn't match the value being parsed, 
> but we can't figure out any way to either observe the raw value 
> pre-decoding (using Debug.watch, Debug.log or even a javascript 
> breakpoint) or to convince Html.Events.on to report an error if parsing 
> fails -- the handler just doesn't fires, with no indication of why.
>
> I tried creating a monitoring function 
>
> monitorDecoder : Decoder a -> Decoder a
> monitorDecoder decoder = 
>   customDecoder Json.Decode.value <| \value -> decodeValue decoder 
> (Debug.watch "decoding value" value)
>
> so that I could write 
>
>on "change" (monitorDecoder decodeSelectedIndex) someHandler
>
> but that approach always fails to decode before the watch gets evaluated 
> -- I'm not sure why, but I suspect it's because the decoder is being asked 
> to decode a JavaScript event, which is not JSON-serializable, and thus the 
> Json.Decode.value decoder fails before the custom decoding logic runs at 
> all.
>
> Are there other strategies I can try? What do people normally do to write 
> solid decoders? I really like Elm in general but I'm worried about not 
> having an effective way to debug these kinds of issues.
>
> Thanks,
> -jacob
>

-- 
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: Code review request

[Thomas Ballinger]

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 difference between 
HasX { ..., x : ... } and HasX {...}
but those may be the wrong questions.

On Thursday, August 18, 2016 at 11:44:26 PM UTC-4, John Bugner wrote:
>
> >While adding type annotations I encountered something I didn't understand 
> that I worked around at 
> https://github.com/thomasballinger/loveinthetimeoftetris/blob/3f968afad490ebab54b4f0c3bafdf45b779ebc4b/src/Main.elm#L278
>  
> ,
>  
> I tried to simplify the behavior and got it down to this 
> https://gist.github.com/thomasballinger/a0d8b38fa7186ee2e608d4772f2ebe7e 
> 
>  which 
> I'd appreciate a hand from anyone in understanding.
> I haven't used extensible records very much, but I think it's because 
> the signatures don't match.
> The first is:
> >hasBothXAndY : HasXAndY (HasX a)
> but the other is:
> >fieldOfBothTypes : HasX (HasXAndY {})
> The order matters.
>
> (Btw, the (<|) function is the opposite of (|>). I personally use only the 
> former, because it does things in the same order that you normally write a 
> function. The latter makes things look "backwards".)
>
> On Thursday, August 18, 2016 at 7:06:13 PM UTC-5, Thomas Ballinger wrote:
>>
>> Thanks very much John. The auto-formatter I'm using is 
>> https://github.com/avh4/elm-format, I also found it to be a bit much. 
>> I'm a big fan of automatic formatting so might look at changing these 
>> settings in elm-format, or if anyone knows of other autoformatters please 
>> let me know.
>>
>> While adding type annotations I encountered something I didn't understand 
>> that I worked around at 
>> https://github.com/thomasballinger/loveinthetimeoftetris/blob/3f968afad490ebab54b4f0c3bafdf45b779ebc4b/src/Main.elm#L278,
>>  
>> I tried to simplify the behavior and got it down to this 
>> https://gist.github.com/thomasballinger/a0d8b38fa7186ee2e608d4772f2ebe7e 
>> which I'd appreciate a hand from anyone in understanding.
>>
>> I did the rest of these except for switching to SVG, but I'm looking 
>> forward to that too.
>>  
>>
>>> >* I don't think I'll be using evancz/elm-graphics in the future since 
>>> I'll be doing less gamey stuff or want to work with canvas more directly. 
>>> How is this usually done?
>>> By using Svg instead: 
>>> http://package.elm-lang.org/packages/elm-lang/svg/1.1.1
>>>
>>> On Wednesday, August 17, 2016 at 4:40:38 PM UTC-5, Thomas Ballinger 
>>> wrote:

 Hi Elm folks! I've enjoyed reading this list for a bit. I've written my 
 first Elm thing over the last couple weeks and would love to hear any kind 
 of feedback on it. It's an unfinished game jam piece I kept running with 
 so 
 the title doesn't make sense.

 code: https://github.com/thomasballinger/loveinthetimeoftetris
 live: love.ballingt.com (takes about 70 seconds to play all of)

 I was going to clean things up the way I know how, but I need to take a 
 break to get some other things done and I thought I'd learn more by asking 
 how someone else might clean it up. Please don't assume I know what I'm 
 doing in the slightest :)

 Any feedback would be great, but if prompts are helpful:
 * what does this code make it look like I'm missing about Elm?
 * what do you think of the extensible record type aliases? I think the 
 way I've used them is mostly terrible, I designed them up front instead of 
 letting them evolve.
 * code style?
 * I'm using an elm autoformatter, how's my formatting? Is this style 
 common?
 * I don't think I'll be using evancz/elm-graphics in the future since 
 I'll be doing less gamey stuff or want to work with canvas more directly. 
 How is this usually done?
 * I abandoned elm reactor once I started embedding in html, is that a 
 viable workflow I should have stuck with for longer?
 * I was tempted to start a utils file or look for an external lib but 
 was trying to focus on learning the stdlib. Are there pretty common util 
 libs folks use? I sure missed some list functions.
 * I escaped to JavaScript anytime I thought it would be hard to do 
 something with the stdlib, presumably it would be nice to use Elm for some 
 of these things?

 Thanks so much, and feel free to contact off list if you prefer at 
 m...@ballingt.com - if you do I'll report back what I learned to the 
 

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

[Will White]

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 Voigtländer wrote:
>
> 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 the first snippet, I was erroneously expecting toString to call 
>> toString from ModuleWithToString, possibly because I'd just been looking at 
>> toString in ModuleWithToString. import exposing (..) makes this foolproof.
>>
>> On Thursday, August 18, 2016 at 8:41:02 PM UTC+1, Janis Voigtländer wrote:
>>>
>>> Or maybe I'm still misunderstanding what your exact problem is in the 
>>> absence of "exposing (..)". Maybe you can expand on the problem description 
>>> from your first message in this thread?
>>>
>>> Am 18.08.2016 um 22:31 schrieb Janis Voigtländer >> >:
>>>
>>> You won't be able to forget one if "exposing (..)" is eliminated from 
>>> the language, as is proposed in the issue I linked to.
>>>
>>> You'd then either have to qualify or add the entities explicitly in 
>>> "exposing (concrete entities)". Problem solved, because in both cases a 
>>> reader of the code does not need to wonder too much where any given name 
>>> comes from. 
>>>
>>> Am 18.08.2016 um 22:19 schrieb Will White :
>>>
>>> Then I'll always namespace them. If I forget one though...
>>>
>>> On Thursday, August 18, 2016 at 6:35:19 PM UTC+1, Janis Voigtländer 
>>> wrote:

 More importantly, maybe, you will have to *remember* to use each 
 imported function at least once in qualified form in each module, or you 
 will end up in the situation Nick described, where in six months you don't 
 know (and other readers of your code do not even know the next day after 
 you wrote the code) where reticulateSplines comes from. 

 Am 18.08.2016 um 20:03 schrieb Nick H :

 Is that a good idea? It seems like occasionally, but not always, using 
 the namespace would make your code less readable than not doing it at all.


 On Thu, Aug 18, 2016 at 9:37 AM, Will White  
 wrote:

> I can still namespace functions with import exposing (..).
>
> On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
>>
>> If you prefer not having to remember things, then you should use 
>> qualified imports.
>>
>> Stripping the namespace off of all your imported functions means that 
>> your code no longer tells you where these functions come from. You will 
>> have to remember this information yourself. This doesn't seem like much 
>> of 
>> a mental burden at the moment, but it will likely become much more 
>> burdensome in 6 months when you are reading through your code again 
>> (e.g. 
>> "Now, which of these 10 modules did that 'reticulateSplines' function 
>> come 
>> from?") And if you never run into that annoyance, I guarantee that every 
>> other person who reads your code will.
>>
>> What's more, APIs that follow the design guidelines 
>>  are 
>> going to make your life even harder, because the functions will have 
>> names 
>> designed to work with a qualifier. Look at your own example. If 
>> "toString" 
>> only works on one type, then it is a terribly undescriptive name. But if 
>> the module is named "Foo" and the type defined in that module is named 
>> "Foo", then "Foo.toString" is not a terrible name.
>>
>> From the design guidelines:
>>
>>> A function called State.runState is redundant and silly. More 
>>> importantly, it encourages people to use import State exposing (..) 
>>> which does not scale well. In files with many so-called "unqualified" 
>>> dependencies, it is essentially impossible to figure out where 
>>> functions 
>>> are coming from. This can make large code bases impossible to 
>>> understand, 
>>> especially if custom infix operators are used as well. Repeating the 
>>> module 
>>> name actively encourages this kind of unreadable code.
>>> With a name like State.run the user is encouraged to disambiguate 
>>> functions with namespacing, leading to a codebase that will be clearer 
>>> to 
>>> people reading the project for the first time. A great example from the 
>>> standard library is Bitwise.and
>>>
>>
>>
>> On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer <
>> janis.voi...@gmail.com> wrote:

[elm-discuss] Re: Possible compiler bug?

[Max Goldstein]

> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Oliver Searle-Barnes]

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, which is 
> maintained, is being kept up to date with Elm compiler releases, and is the 
> “official successor” of circuithub/elm-maybe-extra (with circuithub‘s 
> blessing, as you can see here 
> 
> ).
> ​
>
> 2016-08-19 14:37 GMT+02:00 Oliver Searle-Barnes  >:
>
>> 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 bugs - if I use someone else's library and find a bug in it 
>> then most likely it's far more important to me that it's fixed than it is 
>> for them. If I can install the dependency from github then I can simply 
>> fork it and use my fork until the PR has been merged in. If I have an app 
>> in production this is absolutely essential, the only alternative is to 
>> copy/paste the code into my project and apply a fix there which seems a 
>> poorer solution in every way.
>>
>> 2) Applying updates - similar to (1) if I use someone else's library and 
>> I need to update it for elm 0.17 for instance then I can just fork it and 
>> apply the changes. 
>>
>> 3) Using dependencies that rely on native code - I'm aware of the 
>> argument that native code should be discouraged as far as possible and that 
>> this would make it too easy to reach for native code where an Elm solution 
>> would be better. My counter argument would be that the community is 
>> currently small but full of people who are trying to encourage adoption of 
>> Elm at their workplace. Elm becomes a much harder sell if you can't rely on 
>> existing javascript solutions when necessary. I think it's right that 
>> packages with native code are kept out of http://package.elm-lang.org/, 
>> this sends a strong signal that pure Elm solutions are very much preferred. 
>> The community already has the notion that javascript code should be 
>> considered "unsafe" so I feel confident that there would be a trend towards 
>> pure Elm solutions over time.
>>
>> To give you two concrete examples where I've already found this really 
>> useful:
>>
>> https://github.com/zapnito/local-storage - a fork of 
>> https://github.com/elm-lang/local-storage, while this is a draft it's a 
>> practical implementation written by the author of Elm (thanks Evan!) and 
>> it's highly unlikely that I'm going to improve on it. By using it I'm 
>> accepting a degree of risk, changing signatures, unexpected behaviour etc. 
>> but it still seems far more preferable to the other options.
>>
>> https://github.com/zapnito/elm-maybe-extra - a fork of 
>> https://github.com/circuithub/elm-maybe-extra, it has seem really handy 
>> functions that I wanted to use but it hadn't been updated for Elm 0.17, it 
>> took a couple of minutes to fork it, update the dependencies, change a 
>> `package` statement and have it installed in my project ready to go.
>>
>> It would be great to see official support for these workflows. I think it 
>> would help adoption (as a developer intending to put an Elm in production 
>> it gives me a lot more confidence that I can solve any issues I come across 
>> without depending on 3rd parties) without harming the "gold standard" of 
>> the packages at package.elm-lang.org.
>>
>> -- 
>> 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.

[elm-discuss] Installing packages direct from github

[Oliver Searle-Barnes]

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 bugs - if I use someone else's library and find a bug in it then 
most likely it's far more important to me that it's fixed than it is for 
them. If I can install the dependency from github then I can simply fork it 
and use my fork until the PR has been merged in. If I have an app in 
production this is absolutely essential, the only alternative is to 
copy/paste the code into my project and apply a fix there which seems a 
poorer solution in every way.

2) Applying updates - similar to (1) if I use someone else's library and I 
need to update it for elm 0.17 for instance then I can just fork it and 
apply the changes. 

3) Using dependencies that rely on native code - I'm aware of the argument 
that native code should be discouraged as far as possible and that this 
would make it too easy to reach for native code where an Elm solution would 
be better. My counter argument would be that the community is currently 
small but full of people who are trying to encourage adoption of Elm at 
their workplace. Elm becomes a much harder sell if you can't rely on 
existing javascript solutions when necessary. I think it's right that 
packages with native code are kept out of http://package.elm-lang.org/, 
this sends a strong signal that pure Elm solutions are very much preferred. 
The community already has the notion that javascript code should be 
considered "unsafe" so I feel confident that there would be a trend towards 
pure Elm solutions over time.

To give you two concrete examples where I've already found this really 
useful:

https://github.com/zapnito/local-storage - a fork of 
https://github.com/elm-lang/local-storage, while this is a draft it's a 
practical implementation written by the author of Elm (thanks Evan!) and 
it's highly unlikely that I'm going to improve on it. By using it I'm 
accepting a degree of risk, changing signatures, unexpected behaviour etc. 
but it still seems far more preferable to the other options.

https://github.com/zapnito/elm-maybe-extra - a fork 
of https://github.com/circuithub/elm-maybe-extra, it has seem really handy 
functions that I wanted to use but it hadn't been updated for Elm 0.17, it 
took a couple of minutes to fork it, update the dependencies, change a 
`package` statement and have it installed in my project ready to go.

It would be great to see official support for these workflows. I think it 
would help adoption (as a developer intending to put an Elm in production 
it gives me a lot more confidence that I can solve any issues I come across 
without depending on 3rd parties) without harming the "gold standard" of 
the packages at package.elm-lang.org.

-- 
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] Remove ways of importing except `import exposing (..)`?

[Janis Voigtländer]

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 the first snippet, I was erroneously expecting toString to call
> toString from ModuleWithToString, possibly because I'd just been looking at
> toString in ModuleWithToString. import exposing (..) makes this foolproof.
>
> On Thursday, August 18, 2016 at 8:41:02 PM UTC+1, Janis Voigtländer wrote:
>>
>> Or maybe I'm still misunderstanding what your exact problem is in the
>> absence of "exposing (..)". Maybe you can expand on the problem description
>> from your first message in this thread?
>>
>> Am 18.08.2016 um 22:31 schrieb Janis Voigtländer > >:
>>
>> You won't be able to forget one if "exposing (..)" is eliminated from the
>> language, as is proposed in the issue I linked to.
>>
>> You'd then either have to qualify or add the entities explicitly in
>> "exposing (concrete entities)". Problem solved, because in both cases a
>> reader of the code does not need to wonder too much where any given name
>> comes from.
>>
>> Am 18.08.2016 um 22:19 schrieb Will White :
>>
>> Then I'll always namespace them. If I forget one though...
>>
>> On Thursday, August 18, 2016 at 6:35:19 PM UTC+1, Janis Voigtländer wrote:
>>>
>>> More importantly, maybe, you will have to *remember* to use each
>>> imported function at least once in qualified form in each module, or you
>>> will end up in the situation Nick described, where in six months you don't
>>> know (and other readers of your code do not even know the next day after
>>> you wrote the code) where reticulateSplines comes from.
>>>
>>> Am 18.08.2016 um 20:03 schrieb Nick H :
>>>
>>> Is that a good idea? It seems like occasionally, but not always, using
>>> the namespace would make your code less readable than not doing it at all.
>>>
>>>
>>> On Thu, Aug 18, 2016 at 9:37 AM, Will White  wrote:
>>>
 I can still namespace functions with import exposing (..).

 On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
>
> If you prefer not having to remember things, then you should use
> qualified imports.
>
> Stripping the namespace off of all your imported functions means that
> your code no longer tells you where these functions come from. You will
> have to remember this information yourself. This doesn't seem like much of
> a mental burden at the moment, but it will likely become much more
> burdensome in 6 months when you are reading through your code again (e.g.
> "Now, which of these 10 modules did that 'reticulateSplines' function come
> from?") And if you never run into that annoyance, I guarantee that every
> other person who reads your code will.
>
> What's more, APIs that follow the design guidelines
>  are going
> to make your life even harder, because the functions will have names
> designed to work with a qualifier. Look at your own example. If "toString"
> only works on one type, then it is a terribly undescriptive name. But if
> the module is named "Foo" and the type defined in that module is named
> "Foo", then "Foo.toString" is not a terrible name.
>
> From the design guidelines:
>
>> A function called State.runState is redundant and silly. More
>> importantly, it encourages people to use import State exposing (..)
>> which does not scale well. In files with many so-called "unqualified"
>> dependencies, it is essentially impossible to figure out where functions
>> are coming from. This can make large code bases impossible to understand,
>> especially if custom infix operators are used as well. Repeating the 
>> module
>> name actively encourages this kind of unreadable code.
>> With a name like State.run the user is encouraged to disambiguate
>> functions with namespacing, leading to a codebase that will be clearer to
>> people reading the project for the first time. A great example from the
>> standard library is Bitwise.and
>>
>
>
> On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer <
> janis.voi...@gmail.com> wrote:
>
>> I can’t search for the thread right now, but I’m sure you can find it
>> yourself via the archive. In any case, one aspect of it (but I think 
>> there
>> were more) was this: https://github.com/elm-lang/elm-make/issues/61
>> ​
>>
>> 2016-08-18 17:08 GMT+02:00 Will White :
>>
>>> What unexpected results? The compiler has your back if two
>>> unqualified functions have the same name.
>>>
>>> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis 

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

[Will White]

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 typeFromThatModule
>
> Compiles with unexpected results that you have to catch.
>
> import ModuleWithToString exposing (..)
>
> toString typeFromThatModule
>
> Doesn't compile: "use of toString is ambiguous: did you mean 
> Basics.toString or ModuleWithToString.toString?"
>

-- 
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: We need a clearer story on architecture

[Oliver Searle-Barnes]

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 Thursday, 18 August 2016 01:33:15 UTC+2, Richard Feldman wrote:
>
>
>
> If you mean dividing a component into 3 separate files - ie. model.elm, 
>> update.elm, view.elm , then yeah, that's fine. A single file is too. If you 
>> have a massive Elm component that you feel is difficult to manage in a 
>> single file, and splitting it into three pieces will make it much easier to 
>> maintain and understand, go ahead and do that. Whether your component is 3 
>> files, or a single file shouldn't change your overall architecture - it's 
>> just a horizontal partitioning of functions.
>>
>
> Totally agree! I tried to present this advice on another thread 
>  
> but I'm not sure I said it as well as you just did. ;D
>  
>
>> I'm not sure what you mean by framework - do you mean elm-parts? If so, 
>> just forget about that for now and connect your components manually. It's 
>> not a big deal.
>>
>
> 100% agree.
>  
>
>> as the SPA transitions from page to page, we load only the data that is 
>> required for that page - We have no central business data in our app, 
>> because our server itself serves acts as the single source of truth.
>>
>
> +1 to this too
>
> If you're using websockets to update your business model, go ahead and do 
>>> that - the model will be automatically reflected in the view. *Your 
>>> view shouldn't know anything about websockets.*
>>>
>>
> Strongly agree! Only update should know or care that websockets are 
> involved.
>
> I would second the need for better "official" documentation in Elm for 
>> folks getting started. There is a learning curve to Elm, but once it 
>> "clicks", it'll be more obvious how to piece your application together.
>>
>
> I think part of the challenge is figuring out where the gaps are. Threads 
> like this are super helpful in surfacing specific questions, so HUGE thanks 
> to Oliver for posting it!
>

-- 
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: Possible compiler bug?

[Martin Janiczek]

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)

The compiler will then tell you that the imports are ambiguous.

On Friday, August 19, 2016 at 11:29:00 AM UTC+2, John Bugner wrote:
>
> 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 - 
>> 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 project :) )
>>
>> import Fuzz exposing (Fuzzer)
>> import Random.Pcg as Random
>> import Random.Extra as Random
>> import Shrink
>>
>>
>> type alias Op op =
>> { generator : Random.Generator op }
>>
>>
>> opsFuzzer : List (Op op) -> Fuzzer (List op)
>> opsFuzzer ops =
>> Fuzz.custom
>> (Random.together (List.map .generator ops))
>> (Shrink.list Shrink.noShrink)
>>
>>
>> -- TYPE MISMATCH - 
>> src/A.elm
>>
>> The type annotation for `opsFuzzer` does not match its definition.
>>
>> 21| opsFuzzer : List (Op op) -> Fuzzer (List op)
>> 
>> The type annotation is saying:
>>
>> List { generator : Random.Generator b } -> Fuzzer (List b)
>>
>> But I am inferring that the definition has this type:
>>
>> List { generator : Random.Generator a } -> Fuzzer (List b)
>>
>> -- TYPE MISMATCH - 
>> src/A.elm
>>
>> The 1st argument to function `custom` is causing a mismatch.
>>
>> 23| Fuzz.custom
>> 24|>(Random.together (List.map .generator ops))
>> 25| (Shrink.list Shrink.noShrink)
>>
>> Function `custom` is expecting the 1st argument to be:
>>
>> Random.Generator a
>>
>> But it is:
>>
>> Random.Generator (List a)
>>
>> Detected errors in 1 module.
>>
>> (The larger codebase is here: 
>> https://github.com/Janiczek/elm-test/commit/9b8323d4721cea0f0420c1440d31b79989b7528a
>> )
>>
>> The compiler is telling me my types don't match but I think they do (even 
>> by substituting the types by hand).
>> Does anybody have any idea on what to do with 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Possible compiler bug?

[John Bugner]

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 - 
> 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 project :) )
>
> import Fuzz exposing (Fuzzer)
> import Random.Pcg as Random
> import Random.Extra as Random
> import Shrink
>
>
> type alias Op op =
> { generator : Random.Generator op }
>
>
> opsFuzzer : List (Op op) -> Fuzzer (List op)
> opsFuzzer ops =
> Fuzz.custom
> (Random.together (List.map .generator ops))
> (Shrink.list Shrink.noShrink)
>
>
> -- TYPE MISMATCH - src
> /A.elm
>
> The type annotation for `opsFuzzer` does not match its definition.
>
> 21| opsFuzzer : List (Op op) -> Fuzzer (List op)
> 
> The type annotation is saying:
>
> List { generator : Random.Generator b } -> Fuzzer (List b)
>
> But I am inferring that the definition has this type:
>
> List { generator : Random.Generator a } -> Fuzzer (List b)
>
> -- TYPE MISMATCH - src
> /A.elm
>
> The 1st argument to function `custom` is causing a mismatch.
>
> 23| Fuzz.custom
> 24|>(Random.together (List.map .generator ops))
> 25| (Shrink.list Shrink.noShrink)
>
> Function `custom` is expecting the 1st argument to be:
>
> Random.Generator a
>
> But it is:
>
> Random.Generator (List a)
>
> Detected errors in 1 module.
>
> (The larger codebase is here: 
> https://github.com/Janiczek/elm-test/commit/9b8323d4721cea0f0420c1440d31b79989b7528a
> )
>
> The compiler is telling me my types don't match but I think they do (even 
> by substituting the types by hand).
> Does anybody have any idea on what to do with 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Possible compiler bug?

[Martin Janiczek]

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 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 Generator
>
> So when you call Random.together, you are passing it a 
> Random.Pcg.Generator, but it is expecting a core Generator.
>
>
> On Fri, Aug 19, 2016 at 12:20 AM, 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 - 
>> 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 project :) )
>>
>> import Fuzz exposing (Fuzzer)
>> import Random.Pcg as Random
>> import Random.Extra as Random
>> import Shrink
>>
>>
>> type alias Op op =
>> { generator : Random.Generator op }
>>
>>
>> opsFuzzer : List (Op op) -> Fuzzer (List op)
>> opsFuzzer ops =
>> Fuzz.custom
>> (Random.together (List.map .generator ops))
>> (Shrink.list Shrink.noShrink)
>>
>>
>> -- TYPE MISMATCH - 
>> src/A.elm
>>
>> The type annotation for `opsFuzzer` does not match its definition.
>>
>> 21| opsFuzzer : List (Op op) -> Fuzzer (List op)
>> 
>> The type annotation is saying:
>>
>> List { generator : Random.Generator b } -> Fuzzer (List b)
>>
>> But I am inferring that the definition has this type:
>>
>> List { generator : Random.Generator a } -> Fuzzer (List b)
>>
>> -- TYPE MISMATCH - 
>> src/A.elm
>>
>> The 1st argument to function `custom` is causing a mismatch.
>>
>> 23| Fuzz.custom
>> 24|>(Random.together (List.map .generator ops))
>> 25| (Shrink.list Shrink.noShrink)
>>
>> Function `custom` is expecting the 1st argument to be:
>>
>> Random.Generator a
>>
>> But it is:
>>
>> Random.Generator (List a)
>>
>> Detected errors in 1 module.
>>
>> (The larger codebase is here: 
>> https://github.com/Janiczek/elm-test/commit/9b8323d4721cea0f0420c1440d31b79989b7528a
>> )
>>
>> The compiler is telling me my types don't match but I think they do (even 
>> by substituting the types by hand).
>> Does anybody have any idea on what to do with 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 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] Possible compiler bug?

[Nick H]

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 Generator

So when you call Random.together, you are passing it a
Random.Pcg.Generator, but it is expecting a core Generator.


On Fri, Aug 19, 2016 at 12:20 AM, 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 -
> 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 project :) )
>
> import Fuzz exposing (Fuzzer)
> import Random.Pcg as Random
> import Random.Extra as Random
> import Shrink
>
>
> type alias Op op =
> { generator : Random.Generator op }
>
>
> opsFuzzer : List (Op op) -> Fuzzer (List op)
> opsFuzzer ops =
> Fuzz.custom
> (Random.together (List.map .generator ops))
> (Shrink.list Shrink.noShrink)
>
>
> -- TYPE MISMATCH - src
> /A.elm
>
> The type annotation for `opsFuzzer` does not match its definition.
>
> 21| opsFuzzer : List (Op op) -> Fuzzer (List op)
> 
> The type annotation is saying:
>
> List { generator : Random.Generator b } -> Fuzzer (List b)
>
> But I am inferring that the definition has this type:
>
> List { generator : Random.Generator a } -> Fuzzer (List b)
>
> -- TYPE MISMATCH - src
> /A.elm
>
> The 1st argument to function `custom` is causing a mismatch.
>
> 23| Fuzz.custom
> 24|>(Random.together (List.map .generator ops))
> 25| (Shrink.list Shrink.noShrink)
>
> Function `custom` is expecting the 1st argument to be:
>
> Random.Generator a
>
> But it is:
>
> Random.Generator (List a)
>
> Detected errors in 1 module.
>
> (The larger codebase is here: https://github.com/Janiczek/elm-test/commit/
> 9b8323d4721cea0f0420c1440d31b79989b7528a)
>
> The compiler is telling me my types don't match but I think they do (even
> by substituting the types by hand).
> Does anybody have any idea on what to do with 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 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] Possible compiler bug?

[Martin Janiczek]

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 project :) )

import Fuzz exposing (Fuzzer)
import Random.Pcg as Random
import Random.Extra as Random
import Shrink


type alias Op op =
{ generator : Random.Generator op }


opsFuzzer : List (Op op) -> Fuzzer (List op)
opsFuzzer ops =
Fuzz.custom
(Random.together (List.map .generator ops))
(Shrink.list Shrink.noShrink)


-- TYPE MISMATCH - src/A
.elm

The type annotation for `opsFuzzer` does not match its definition.

21| opsFuzzer : List (Op op) -> Fuzzer (List op)

The type annotation is saying:

List { generator : Random.Generator b } -> Fuzzer (List b)

But I am inferring that the definition has this type:

List { generator : Random.Generator a } -> Fuzzer (List b)

-- TYPE MISMATCH - src/A
.elm

The 1st argument to function `custom` is causing a mismatch.

23| Fuzz.custom
24|>(Random.together (List.map .generator ops))
25| (Shrink.list Shrink.noShrink)

Function `custom` is expecting the 1st argument to be:

Random.Generator a

But it is:

Random.Generator (List a)

Detected errors in 1 module.

(The larger codebase is 
here: 
https://github.com/Janiczek/elm-test/commit/9b8323d4721cea0f0420c1440d31b79989b7528a)

The compiler is telling me my types don't match but I think they do (even 
by substituting the types by hand).
Does anybody have any idea on what to do with 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.