Re: [elm-discuss] Re: elm first impressions (and frustrations)

[Zachary Kessin]

I think that being backend agnostic was / is a good choice. When I started
SquareTarget http://squaretarget.rocks I was able to reach for Erlang/OTP
and WebMachine on the backend, which is a stack that I know well and I know
how it performs under stress etc. Others have used Ruby, Elixir or Haskell.
While getting the benefits of Elm on the frontend.

As for having to context switch between erlang and elm. That is an issue,
on the plus side, the Elm Architecture and an Erlang gen_server are pretty
similar in how they do things. But the two languages are quite frankly very
different, in that they were both built to solve a problem, but two very
different problems. Elm wants to catch all errors in the type system.
Erlang was built on the assuption that there are some errors that can only
be caught in real time and in an external process such as a server hardware
failure.

Honestly, I think the actual problems being solved by frontend code and
backend code make the idea of a whole stack language not a really good one.

Zach






ᐧ

On Mon, Aug 1, 2016 at 9:06 AM, Peter Damoc  wrote:

> Hi Neil,
>
> Few comments on the issues you've raised:
>
> 1. Elm plans to go to the server side too. There are already
> proof-of-concept that allows one to use Elm server-side and with the advent
> of 0.18 (next version) we might see official support for that. Also, one
> could use something like Horizon and bypass the server-side completely.
> 2. Actually, people who had success introducing Elm into production
> started within a very small corner of the app and gradually implemented
> more and more in Elm. You can read the latest blog post
>  that talks more about
> this.
> 3. What would qualify as a moderately complex example? To me, ToDoMVC is
> moderately complex. Also, you could find more moderately complex stuff   on
> builtwithelm.co
> 4. Interop from JS to Elm is beautifully simple through the mechanism of
> ports. Basically you can push messages into the Elm app. Of course, Elm
> does not allow direct state mutation of its program because that would
> defeat some of its purpose.
> 5. There was a proof of concept for a native version of Elm via
> react-native but you are right, there is no native-app framework in Elm
> yet.
> 6. redux was inspired by Elm Architecture so... if you use that, you are
> already getting closer to Elm.
>
> Elm is not ready for the early-majority yet, I'm not sure it is really in
> the realm of the early adopter either. Most of us here might be innovators
> and there are a set of advantages that come with that but also
> disadvantages. :)
>
> So, if you're looking for a full-stack battle proven solution, you have
> come to the wrong place.
> If you are looking for something to take some of the pain of web
> development away, you might be in the right place.
>
>
>
>
> On Mon, Aug 1, 2016 at 8:25 AM, nrser  wrote:
>
>> thanks dude.
>>
>> i read a considerable amount more before going sleep last night...
>> checked out the compiler repo (which has a much more clear description of
>> elm - "Elm is a type inferred, functional reactive language that compiles
>> to HTML, CSS, and JavaScript.") and played around with trying to compile
>> something i could use from js (didn't seem possible).
>>
>> i think the conceptual architecture is fantastic. i've been down the road
>> you talk about... managed large products with javascript / actionscript UI
>> front ends... the state management was a disaster. constant source of bugs,
>> which at the scale we were operating translated into very serious amounts
>> of lost time and money.
>>
>> the canonical source of truth and well-defined states and transitions is 
>> *fucking
>> awesome*. revolutionary. and i really like the idea of using a
>> functional, type-safe language.
>>
>> but...
>>
>>1. too narrow of a scope. unless you already know Haskell (and most
>>people don't) you're learning an unfamiliar language that can only be used
>>in exactly one part of the stack and will need to constantly context 
>> switch
>>in and out of it. in my opinion, the major advantage to universal
>>javascript is despite js being such a POS language (thought babel has
>>significantly eased this pain) cutting out this context switch. seems like
>>logic would also need to be duplicated in elm and the back-end language as
>>well, which has been a source of bugs in my experience.
>>2. seem all-or-nothing - my front-end is either in Elm or it's not?
>>i'm not sure i can ease it in slowly and partially. if you have a rails 
>> app
>>or other traditional "fat-server" app this is probably not that big of a
>>deal because you can keep the server portion, serve api end points, and
>>re-write the client stuff in elm (though that alone is a huge amount of
>>effort and risk), but everything i'm dealing with is already js on both
>>sides.
>>3. i'm not really sure about any of th

Re: [elm-discuss] "I know what I'm doing"-syntax and helpful error messages for string interpolation

[Zachary Kessin]

I dislike the idea of any syntax that will let me do something dumb and let
me "Fix it later" because that generally never happens

Zach
ᐧ

On Sun, Jul 31, 2016 at 11:15 PM, Filip Haglund 
wrote:

> Keeping with the helpfullness of the compiler, having warnings when doing
> scetchy things with string interpolation (issue #905 on Github
> ) could be useful.
> This could be warnings about building urls's from variables that might be
> user input. It could also be about building SQL queries, or HTML.
>
> I suggest having some basic checks in the compiler for these areas where
> special care should be taken. This would generate warnings, assuming it is
> a mistake until proven otherwise.
>
> `"http://example.com/profile/{{userdata}}/"` would generate a warning.
> `"http://example.com/profile/{{[url] userdata }}/"`would not.
>
> `"My name is {{[url] userdata}}."`would generate a warning.
> `"My name is {{userdata}}."`would not.
>
> `"Check out my blog."` would
> generate a warning.
> `"Check out my blog."` would
> generate a warning.
> `"Check out my blog."`
> would not.
>
> `"Select * from users where username = '{{userdata}}'"` would generate a
> warning.
> `"Select * from users where username = '{{[html, url] userdata}}'"`
> would generate a warning.
> `"Select * from users where username = '{{[sql] userdata}}'"` would not.
>
> Exact syntax is not important right now. I want to know what the community
> thinks about the idea of "I know what I'm doing"-annotated string
> interpolation.
>
> --
> 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.
>



-- 
Zach Kessin
SquareTarget 
Twitter: @zkessin 
Skype: zachkessin

-- 
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] Elm Jobs Board

[Andre Bolle]

Noah,

Thanks for the link. I have signed up to that.

Andre

-- 
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] Is there a better way to structure my List types?

[Ryan W]

I want to be able to store several different types of lists in a single 
data structure, and and each type of list should be treated differently by 
the view function.

What I've tried:
type ThingList
= FooList (List Foo)
| BarList (List Bar)
| BazList (List Baz)


This works okay, but if I want to do something like get the length of a 
ThingList without caring about whether it is a FooList, BarList or BazList 
it seems I have to have to write something like this:

length : ThingList
length thingList =
case thingList of
FooList list ->
List.length list

BarList list ->
List.length list

BazList list ->
List.length list

Since in my actual program I plan to have several more sub-types in the 
actual counterpart to ThingList this becomes somewhat cumbersome and it 
definitely isn't DRY. I guess this is a form of the expression problem? 
 I tried to generalize it 
a bit so I wouldn't have to update as many of these functions when I add a 
new sub-type like this:
reduce : (List a -> b) -> EntityList -> b
reduce f entityList =
case entityList of
FooList list ->
f list

BarList list ->
f list

BazList list ->
f list

but that gave me an error like this:

Function `f` is expecting the argument to be: List Foo But it is: List Bar

In my particular case, at least for now, I only wanted the length of a 
ThingList literal so I can work around it, but I'm curious if there is way 
to structure the types that avoids this problem.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: elm first impressions (and frustrations)

[Peter Damoc]

Zach,

Of course being backend agnostic is an amazing thing.
That being said, I would love to have a backend that could be implemented
in Elm and one full-stack solution that has perfect impedance match.
This way, the data models can be shared between the backend and the
front-end and with a little bit of convention, the whole Json encoding and
decoding could disappear (it could be handled automatically by some
library).
Just imagine a workflow where you change one model working in the front end
and the compiler throws and error that the back-end does not implement what
you need.
A user learning Elm for the front-end could also leverage his/her knowledge
to move from front-end to full-stack.
This could be huge for freelance lone developers.




On Mon, Aug 1, 2016 at 10:32 AM, Zachary Kessin  wrote:

> I think that being backend agnostic was / is a good choice. When I started
> SquareTarget http://squaretarget.rocks I was able to reach for Erlang/OTP
> and WebMachine on the backend, which is a stack that I know well and I know
> how it performs under stress etc. Others have used Ruby, Elixir or Haskell.
> While getting the benefits of Elm on the frontend.
>
> As for having to context switch between erlang and elm. That is an issue,
> on the plus side, the Elm Architecture and an Erlang gen_server are pretty
> similar in how they do things. But the two languages are quite frankly very
> different, in that they were both built to solve a problem, but two very
> different problems. Elm wants to catch all errors in the type system.
> Erlang was built on the assuption that there are some errors that can only
> be caught in real time and in an external process such as a server hardware
> failure.
>
> Honestly, I think the actual problems being solved by frontend code and
> backend code make the idea of a whole stack language not a really good one.
>
> Zach
>
>
>
>
>
>
> ᐧ
>
> On Mon, Aug 1, 2016 at 9:06 AM, Peter Damoc  wrote:
>
>> Hi Neil,
>>
>> Few comments on the issues you've raised:
>>
>> 1. Elm plans to go to the server side too. There are already
>> proof-of-concept that allows one to use Elm server-side and with the advent
>> of 0.18 (next version) we might see official support for that. Also, one
>> could use something like Horizon and bypass the server-side completely.
>> 2. Actually, people who had success introducing Elm into production
>> started within a very small corner of the app and gradually implemented
>> more and more in Elm. You can read the latest blog post
>>  that talks more about
>> this.
>> 3. What would qualify as a moderately complex example? To me, ToDoMVC is
>> moderately complex. Also, you could find more moderately complex stuff   on
>> builtwithelm.co
>> 4. Interop from JS to Elm is beautifully simple through the mechanism of
>> ports. Basically you can push messages into the Elm app. Of course, Elm
>> does not allow direct state mutation of its program because that would
>> defeat some of its purpose.
>> 5. There was a proof of concept for a native version of Elm via
>> react-native but you are right, there is no native-app framework in Elm
>> yet.
>> 6. redux was inspired by Elm Architecture so... if you use that, you are
>> already getting closer to Elm.
>>
>> Elm is not ready for the early-majority yet, I'm not sure it is really in
>> the realm of the early adopter either. Most of us here might be innovators
>> and there are a set of advantages that come with that but also
>> disadvantages. :)
>>
>> So, if you're looking for a full-stack battle proven solution, you have
>> come to the wrong place.
>> If you are looking for something to take some of the pain of web
>> development away, you might be in the right place.
>>
>>
>>
>>
>> On Mon, Aug 1, 2016 at 8:25 AM, nrser  wrote:
>>
>>> thanks dude.
>>>
>>> i read a considerable amount more before going sleep last night...
>>> checked out the compiler repo (which has a much more clear description of
>>> elm - "Elm is a type inferred, functional reactive language that compiles
>>> to HTML, CSS, and JavaScript.") and played around with trying to compile
>>> something i could use from js (didn't seem possible).
>>>
>>> i think the conceptual architecture is fantastic. i've been down the
>>> road you talk about... managed large products with javascript /
>>> actionscript UI front ends... the state management was a disaster. constant
>>> source of bugs, which at the scale we were operating translated into very
>>> serious amounts of lost time and money.
>>>
>>> the canonical source of truth and well-defined states and transitions is 
>>> *fucking
>>> awesome*. revolutionary. and i really like the idea of using a
>>> functional, type-safe language.
>>>
>>> but...
>>>
>>>1. too narrow of a scope. unless you already know Haskell (and most
>>>people don't) you're learning an unfamiliar language that can only be 
>>> used
>>>in exactly one part of the stack and will need to con

[elm-discuss] Using Elm with jQuery (ports)

[Matic Zavadlal]

HI! 

I want to use tags-input widget which attaches some attributes to certain 
element in my body.
The idea is to create normal input field on the elm side and later 
implement additional functionality 
via ports.



So my approach is to load compiled Elm-js code and later once site loads 
append it. I found out that
it returns error if I integrate elm outside "ready" function, which I don't 
really understand why it happens. 

Error:
  TypeError: null is not an object (evaluating 'parent.appendChild')

So the fun comes with logging data...

"0" and "2" return empty jQuery object, even though "body" log already 
includes element with certain id.

"1" returns the correct pointer to an element, I found that it is because 
of js-interloop which puts the tasks 
inside setTimeout function at the end of queue, even with 0 timeout, and 
it's somehow resolved correctly.

But it's not the correct approach, quite obviously! Which approach would be 
correct one and how to achieve
that logs "0" and "2" won't return empty object anymore?


NOTE:
   I use browserify.

JS-Code:

"use strict"

const Elm = require('./elm.js')

const TagsInput = require('./bootstraptagsinput.js')

$(document).ready(function() {

   const App = Elm.Search.fullscreen()

   console.log($("body"));

   console.log("0", $('#tagsInputField'));

   

   setTimeout(() => {
  console.log("1", $('#tagsInputField'));
   }, 0)

   console.log("2", $('#tagsInputField'));

})

Elm-View:
renderSearchBar : Model -> Html Msg
renderSearchBar model =
input
[ onInput SearchAggregations
, placeholder "Search Filters"
, value model.filterSearch.input
, id "tagsInputField"
]
[]


-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: elm first impressions (and frustrations)

[John Orford]

> Just imagine a workflow where you change one model working in the front
end and the compiler throws and error that the back-end does not implement
what you need.

+1

On Mon, 1 Aug 2016 at 09:57 Peter Damoc  wrote:

> Zach,
>
> Of course being backend agnostic is an amazing thing.
> That being said, I would love to have a backend that could be implemented
> in Elm and one full-stack solution that has perfect impedance match.
> This way, the data models can be shared between the backend and the
> front-end and with a little bit of convention, the whole Json encoding and
> decoding could disappear (it could be handled automatically by some
> library).
> Just imagine a workflow where you change one model working in the front
> end and the compiler throws and error that the back-end does not implement
> what you need.
> A user learning Elm for the front-end could also leverage his/her
> knowledge to move from front-end to full-stack.
> This could be huge for freelance lone developers.
>
>
>
>
> On Mon, Aug 1, 2016 at 10:32 AM, Zachary Kessin  wrote:
>
>> I think that being backend agnostic was / is a good choice. When I
>> started SquareTarget http://squaretarget.rocks I was able to reach for
>> Erlang/OTP and WebMachine on the backend, which is a stack that I know well
>> and I know how it performs under stress etc. Others have used Ruby, Elixir
>> or Haskell. While getting the benefits of Elm on the frontend.
>>
>> As for having to context switch between erlang and elm. That is an issue,
>> on the plus side, the Elm Architecture and an Erlang gen_server are pretty
>> similar in how they do things. But the two languages are quite frankly very
>> different, in that they were both built to solve a problem, but two very
>> different problems. Elm wants to catch all errors in the type system.
>> Erlang was built on the assuption that there are some errors that can only
>> be caught in real time and in an external process such as a server hardware
>> failure.
>>
>> Honestly, I think the actual problems being solved by frontend code and
>> backend code make the idea of a whole stack language not a really good one.
>>
>> Zach
>>
>>
>>
>>
>>
>>
>> ᐧ
>>
>> On Mon, Aug 1, 2016 at 9:06 AM, Peter Damoc  wrote:
>>
>>> Hi Neil,
>>>
>>> Few comments on the issues you've raised:
>>>
>>> 1. Elm plans to go to the server side too. There are already
>>> proof-of-concept that allows one to use Elm server-side and with the advent
>>> of 0.18 (next version) we might see official support for that. Also, one
>>> could use something like Horizon and bypass the server-side completely.
>>> 2. Actually, people who had success introducing Elm into production
>>> started within a very small corner of the app and gradually implemented
>>> more and more in Elm. You can read the latest blog post
>>>  that talks more about
>>> this.
>>> 3. What would qualify as a moderately complex example? To me, ToDoMVC is
>>> moderately complex. Also, you could find more moderately complex stuff   on
>>> builtwithelm.co
>>> 4. Interop from JS to Elm is beautifully simple through the mechanism of
>>> ports. Basically you can push messages into the Elm app. Of course, Elm
>>> does not allow direct state mutation of its program because that would
>>> defeat some of its purpose.
>>> 5. There was a proof of concept for a native version of Elm via
>>> react-native but you are right, there is no native-app framework in Elm
>>> yet.
>>> 6. redux was inspired by Elm Architecture so... if you use that, you are
>>> already getting closer to Elm.
>>>
>>> Elm is not ready for the early-majority yet, I'm not sure it is really
>>> in the realm of the early adopter either. Most of us here might be
>>> innovators and there are a set of advantages that come with that but also
>>> disadvantages. :)
>>>
>>> So, if you're looking for a full-stack battle proven solution, you have
>>> come to the wrong place.
>>> If you are looking for something to take some of the pain of web
>>> development away, you might be in the right place.
>>>
>>>
>>>
>>>
>>> On Mon, Aug 1, 2016 at 8:25 AM, nrser  wrote:
>>>
 thanks dude.

 i read a considerable amount more before going sleep last night...
 checked out the compiler repo (which has a much more clear description of
 elm - "Elm is a type inferred, functional reactive language that compiles
 to HTML, CSS, and JavaScript.") and played around with trying to compile
 something i could use from js (didn't seem possible).

 i think the conceptual architecture is fantastic. i've been down the
 road you talk about... managed large products with javascript /
 actionscript UI front ends... the state management was a disaster. constant
 source of bugs, which at the scale we were operating translated into very
 serious amounts of lost time and money.

 the canonical source of truth and well-defined states and transitions
 is *fucking aweso

[elm-discuss] Re: Is there a better way to structure my List types?

[Wouter In t Velt]

How about this?

type Thing =
  Foo
  | Bar
  | Baz


type ThingList = List Thing



That way, you can simply do:

List.length ThingList

-- 
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] "I know what I'm doing"-syntax and helpful error messages for string interpolation

[Peter Damoc]

I agree with Zach.

"I know what I'm doing" is sometimes a shorthand for "WTF was I thinking 6
months ago?". Just because it makes sense to you now it is not a guarantee
that will continue to make sense forever.

If you like to shoot yourself in the foot, Elm does not try to prevent you
but it doesn't give you any gun either. You'll have to bring your own gun
(JS). :)





On Mon, Aug 1, 2016 at 10:34 AM, Zachary Kessin  wrote:

> I dislike the idea of any syntax that will let me do something dumb and
> let me "Fix it later" because that generally never happens
>
> Zach
> ᐧ
>
> On Sun, Jul 31, 2016 at 11:15 PM, Filip Haglund 
> wrote:
>
>> Keeping with the helpfullness of the compiler, having warnings when doing
>> scetchy things with string interpolation (issue #905 on Github
>> ) could be useful.
>> This could be warnings about building urls's from variables that might be
>> user input. It could also be about building SQL queries, or HTML.
>>
>> I suggest having some basic checks in the compiler for these areas where
>> special care should be taken. This would generate warnings, assuming it is
>> a mistake until proven otherwise.
>>
>> `"http://example.com/profile/{{userdata}}/"` would generate a warning.
>> `"http://example.com/profile/{{[url] userdata }}/"`would not.
>>
>> `"My name is {{[url] userdata}}."`would generate a warning.
>> `"My name is {{userdata}}."`would not.
>>
>> `"Check out my blog."` would
>> generate a warning.
>> `"Check out my blog."` would
>> generate a warning.
>> `"Check out my blog."`
>> would not.
>>
>> `"Select * from users where username = '{{userdata}}'"` would generate a
>> warning.
>> `"Select * from users where username = '{{[html, url] userdata}}'"`
>> would generate a warning.
>> `"Select * from users where username = '{{[sql] userdata}}'"` would not.
>>
>> Exact syntax is not important right now. I want to know what the
>> community thinks about the idea of "I know what I'm doing"-annotated string
>> interpolation.
>>
>> --
>> 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.
>>
>
>
>
> --
> Zach Kessin
> SquareTarget 
> Twitter: @zkessin 
> Skype: zachkessin
>
> --
> 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.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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: Is there a better way to structure my List types?

[ryan1729]

The problem with that, for my use case at least, is that I want to be able to 
know that a list contains only Foos or only Bars because there are functions 
that only make sense for Bars and not Foos. And it would be kind of strange to 
have to put in a case for the sub-type I never expect to call that function 
with. And if I ever do then I've lost the type safety so the compiler won't 
catch my mistake. 

> On Aug 1, 2016, at 2:25 AM, Wouter In t Velt  wrote:
> 
> How about this?
> 
> type Thing =
>   Foo
>   | Bar
>   | Baz
> 
> 
> type ThingList = List Thing
> 
> 
> 
> That way, you can simply do:
> 
> List.length ThingList
> 
> -- 
> 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/8FNvfSguIq8/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] Compiler fails on port module name in sub-directory

[Gábor Varga]

I worked it out. 
I would not call it a bug, I would rather call it a very bad compiler error 
message.

Basically what happens is the following. You have this directory structure:
/src
+-- Component
|   +-- Ports.elm
|   +-- ...
+-- ModuleA.elm
+-- ModuleB.elm

ModuleA.elm says "import Ports"
ModuleB.elm says "import Component.Ports"

Component/Ports.elm can declare "module Ports" or "module Component.Ports", 
either one is correct but the compiler will complain that the file's name 
and the source code does not match.
A good message, in my opinion, would accept whatever is declared in P
orts.elm (if it is valid), and would point to eiher ModuleA or ModuleB 
stating that one of them is trying to import a module which does not exist.






On Friday, July 29, 2016 at 11:11:05 PM UTC+2, Duane Johnson wrote:
>
> Hi Gabor, did you ever get this worked out? I'm curious if it's an elm bug.
>
> On Fri, Jul 22, 2016 at 9:40 AM, Gábor Varga  > wrote:
>
>> Hello guys,
>>
>> I have a pretty standard elm project: all my source files are in src and 
>> under src there are several sub directories for each feature.
>> One of those is called Login and it has a Model/Update/View.elm files in 
>> it as well as 2 port modules: InputPorts and OutputPorts. Now I cannot 
>> name those port modules in a way the compiler would not complain:
>>
>> $ elm-make src/main.elm --output build/elm.js --yes --warn
>> The module name is messed up for .\./src\Login\OutputPorts.elm
>>
>> According to the file's name it should be Login.OutputPorts
>> According to the source code it should be OutputPorts
>>
>> Which is it?
>>
>> *## after renaming it in the "source code" *
>> $ elm-make src/main.elm --output build/elm.js --yes --warn
>> The module name is messed up for .\./src/Login\OutputPorts.elm
>>
>> According to the file's name it should be OutputPorts
>> According to the source code it should be Login.OutputPorts
>>
>> Which is it?
>>
>>
>> Any ideas what I am missing?
>>
>>
>> Thanks,
>>
>> Gabor
>>
>> -- 
>> 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: Using Elm with jQuery (ports)

[Matic Zavadlal]

Created ready event which is triggered via Elm port and works fine. Similar 
to jQuery ready function.

Dne ponedeljek, 01. avgust 2016 10.02.14 UTC+2 je oseba Matic Zavadlal 
napisala:
>
> HI! 
>
> I want to use tags-input widget which attaches some attributes to certain 
> element in my body.
> The idea is to create normal input field on the elm side and later 
> implement additional functionality 
> via ports.
>
>
>
> So my approach is to load compiled Elm-js code and later once site loads 
> append it. I found out that
> it returns error if I integrate elm outside "ready" function, which I 
> don't really understand why it happens. 
>
> Error:
>   TypeError: null is not an object (evaluating 'parent.appendChild')
>
> So the fun comes with logging data...
>
> "0" and "2" return empty jQuery object, even though "body" log already 
> includes element with certain id.
>
> "1" returns the correct pointer to an element, I found that it is because 
> of js-interloop which puts the tasks 
> inside setTimeout function at the end of queue, even with 0 timeout, and 
> it's somehow resolved correctly.
>
> But it's not the correct approach, quite obviously! Which approach would 
> be correct one and how to achieve
> that logs "0" and "2" won't return empty object anymore?
>
>
> NOTE:
>I use browserify.
>
> JS-Code:
>
> "use strict"
>
> const Elm = require('./elm.js')
>
> const TagsInput = require('./bootstraptagsinput.js')
>
> $(document).ready(function() {
>
>const App = Elm.Search.fullscreen()
>
>console.log($("body"));
>
>console.log("0", $('#tagsInputField'));
>
>
>
>setTimeout(() => {
>   console.log("1", $('#tagsInputField'));
>}, 0)
>
>console.log("2", $('#tagsInputField'));
>
> })
>
> Elm-View:
> renderSearchBar : Model -> Html Msg
> renderSearchBar model =
> input
> [ onInput SearchAggregations
> , placeholder "Search Filters"
> , value model.filterSearch.input
> , id "tagsInputField"
> ]
> []
>
>
>

-- 
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: Using Elm with jQuery (ports)

[Matic Zavadlal]

Created ready event, which is triggered via Elm port and works! It's 
similar to jQuery ready event.

-- 
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: Is there a better way to structure my List types?

[debois]

What actually goes in the lists? (As opposed to Foo, Bar etc.)

-- 
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] Compiler fails on port module name in sub-directory

[Janis Voigtländer]

I would rather call it a very bad compiler error message.

So, open an issue at https://github.com/elm-lang/error-message-catalog?
​

2016-08-01 11:54 GMT+02:00 Gábor Varga :

> I worked it out.
> I would not call it a bug, I would rather call it a very bad compiler
> error message.
>
> Basically what happens is the following. You have this directory structure:
> /src
> +-- Component
> |   +-- Ports.elm
> |   +-- ...
> +-- ModuleA.elm
> +-- ModuleB.elm
>
> ModuleA.elm says "import Ports"
> ModuleB.elm says "import Component.Ports"
>
> Component/Ports.elm can declare "module Ports" or "module Component.Ports",
> either one is correct but the compiler will complain that the file's name
> and the source code does not match.
> A good message, in my opinion, would accept whatever is declared in P
> orts.elm (if it is valid), and would point to eiher ModuleA or ModuleB
> stating that one of them is trying to import a module which does not exist.
>
>
>
>
>
>
> On Friday, July 29, 2016 at 11:11:05 PM UTC+2, Duane Johnson wrote:
>>
>> Hi Gabor, did you ever get this worked out? I'm curious if it's an elm
>> bug.
>>
>> On Fri, Jul 22, 2016 at 9:40 AM, Gábor Varga  wrote:
>>
>>> Hello guys,
>>>
>>> I have a pretty standard elm project: all my source files are in src
>>> and under src there are several sub directories for each feature.
>>> One of those is called Login and it has a Model/Update/View.elm files
>>> in it as well as 2 port modules: InputPorts and OutputPorts. Now I
>>> cannot name those port modules in a way the compiler would not complain:
>>>
>>> $ elm-make src/main.elm --output build/elm.js --yes --warn
>>> The module name is messed up for .\./src\Login\OutputPorts.elm
>>>
>>> According to the file's name it should be Login.OutputPorts
>>> According to the source code it should be OutputPorts
>>>
>>> Which is it?
>>>
>>> *## after renaming it in the "source code" *
>>> $ elm-make src/main.elm --output build/elm.js --yes --warn
>>> The module name is messed up for .\./src/Login\OutputPorts.elm
>>>
>>> According to the file's name it should be OutputPorts
>>> According to the source code it should be Login.OutputPorts
>>>
>>> Which is it?
>>>
>>>
>>> Any ideas what I am missing?
>>>
>>>
>>> Thanks,
>>>
>>> Gabor
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Is there a better way to structure my List types?

[ryan1729]

Records, where each type has a different set of fields. 

> On Aug 1, 2016, at 4:08 AM, debois  wrote:
> 
> What actually goes in the lists? (As opposed to Foo, Bar etc.)
> 
> -- 
> 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/8FNvfSguIq8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Is there a better way to structure my List types?

[Søren Debois]

I meant, what are you trying to model? What's the /actual/ application
you're doing?

-- 
Søren Debois
Sent with Airmail

Den 1. august 2016 kl. 13.20.47, ryan1...@gmail.com (ryan1...@gmail.com)
skrev:

> Records, where each type has a different set of fields.
>
> On Aug 1, 2016, at 4:08 AM, debois  wrote:
>
> What actually goes in the lists? (As opposed to Foo, Bar etc.)
>
> --
> 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/8FNvfSguIq8/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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/8FNvfSguIq8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Is there a better way to structure my List types?

[Ryan W]

I'm using this package
 to
display several different types of tables, with different sets of columns.
The actual number of tables and the data within them is dynamic, but the
types of tables are all definable ahead of time. Only one type of table
needs to be visible at one time, but users should be able to switch back
and forth between different tables. So, in my model I have a ThingList
called currentThingList which is rendered in the view, and a Dict that
holds all the ThingLists so the currentThingList can be set according to
the users' wishes.

I don't see how the semantics of the data is relevant.

On 1 August 2016 at 05:27, Søren Debois  wrote:

> I meant, what are you trying to model? What's the /actual/ application
> you're doing?
>
> --
> Søren Debois
> Sent with Airmail
>
> Den 1. august 2016 kl. 13.20.47, ryan1...@gmail.com (ryan1...@gmail.com)
> skrev:
>
>> Records, where each type has a different set of fields.
>>
>> On Aug 1, 2016, at 4:08 AM, debois  wrote:
>>
>> What actually goes in the lists? (As opposed to Foo, Bar etc.)
>>
>> --
>> 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/8FNvfSguIq8/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 a topic in the
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/elm-discuss/8FNvfSguIq8/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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/8FNvfSguIq8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] How to decode JSON object with more than 8 fields?

[Petr Huřťák]

For 8 fields or less I can do

import Json.Decode as Decode exposing ((:=))

collectionDecoder : Decode.Decoder (List Test)
collectionDecoder =
Decode.list
(Decode.object8 Test
("id" := Decode.int)
...
)


How to decode JSON object with more than 8 fields?

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] How to decode JSON object with more than 8 fields?

[Peter Damoc]

use (|:) from Json.Decode.Extra
http://package.elm-lang.org/packages/elm-community/json-extra/1.0.0/Json-Decode-Extra#|
:


On Mon, Aug 1, 2016 at 3:21 PM, Petr Huřťák  wrote:

> For 8 fields or less I can do
>
> import Json.Decode as Decode exposing ((:=))
>
> collectionDecoder : Decode.Decoder (List Test)
> collectionDecoder =
> Decode.list
> (Decode.object8 Test
> ("id" := Decode.int)
> ...
> )
>
>
> How to decode JSON object with more than 8 fields?
>
> --
> 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.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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] Compiler fails on port module name in sub-directory

[Gábor Varga]

That's what I wanted to do :) thanks for pointing me in the right way!
Here it is with a link to a 
sample: https://github.com/elm-lang/error-message-catalog/issues/147



On Monday, August 1, 2016 at 12:28:05 PM UTC+2, Janis Voigtländer wrote:
>
> I would rather call it a very bad compiler error message.
>
> So, open an issue at https://github.com/elm-lang/error-message-catalog?
> ​
>
> 2016-08-01 11:54 GMT+02:00 Gábor Varga >:
>
>> I worked it out. 
>> I would not call it a bug, I would rather call it a very bad compiler 
>> error message.
>>
>> Basically what happens is the following. You have this directory 
>> structure:
>> /src
>> +-- Component
>> |   +-- Ports.elm
>> |   +-- ...
>> +-- ModuleA.elm
>> +-- ModuleB.elm
>>
>> ModuleA.elm says "import Ports"
>> ModuleB.elm says "import Component.Ports"
>>
>> Component/Ports.elm can declare "module Ports" or "module Component.
>> Ports", either one is correct but the compiler will complain that the 
>> file's name and the source code does not match.
>> A good message, in my opinion, would accept whatever is declared in P
>> orts.elm (if it is valid), and would point to eiher ModuleA or ModuleB 
>> stating that one of them is trying to import a module which does not exist.
>>
>>
>>
>>
>>
>>
>> On Friday, July 29, 2016 at 11:11:05 PM UTC+2, Duane Johnson wrote:
>>>
>>> Hi Gabor, did you ever get this worked out? I'm curious if it's an elm 
>>> bug.
>>>
>>> On Fri, Jul 22, 2016 at 9:40 AM, Gábor Varga  wrote:
>>>
 Hello guys,

 I have a pretty standard elm project: all my source files are in src 
 and under src there are several sub directories for each feature.
 One of those is called Login and it has a Model/Update/View.elm files 
 in it as well as 2 port modules: InputPorts and OutputPorts. Now I 
 cannot name those port modules in a way the compiler would not complain:

 $ elm-make src/main.elm --output build/elm.js --yes --warn
 The module name is messed up for .\./src\Login\OutputPorts.elm

 According to the file's name it should be Login.OutputPorts
 According to the source code it should be OutputPorts

 Which is it?

 *## after renaming it in the "source code" *
 $ elm-make src/main.elm --output build/elm.js --yes --warn
 The module name is messed up for .\./src/Login\OutputPorts.elm

 According to the file's name it should be OutputPorts
 According to the source code it should be Login.OutputPorts

 Which is it?


 Any ideas what I am missing?


 Thanks,

 Gabor

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

Re: [elm-discuss] Re: Is there a better way to structure my List types?

[Nick H]

The semantics are relevant because we want to avoid an XY scenario
, which tend to come up a lot on this mailing list.
Rest assured, Soren is only asking because he wants you to get the best
help possible.  :-)

It sounds to me like the approach you describe in the OP is the best way to
model the data.

Sure, your "reduce" function doesn't compile. But I don't think it would be
that useful anyway. How many 1-arity functions are there that can operate
on a list of *unspecified* type and return a value of a *specified *type?
The only one I can think of is List.length.

On Mon, Aug 1, 2016 at 4:49 AM, Ryan W  wrote:

> I'm using this package
> 
> to display several different types of tables, with different sets of
> columns. The actual number of tables and the data within them is dynamic,
> but the types of tables are all definable ahead of time. Only one type of
> table needs to be visible at one time, but users should be able to switch
> back and forth between different tables. So, in my model I have a ThingList
> called currentThingList which is rendered in the view, and a Dict that
> holds all the ThingLists so the currentThingList can be set according to
> the users' wishes.
>
> I don't see how the semantics of the data is relevant.
>
> On 1 August 2016 at 05:27, Søren Debois  wrote:
>
>> I meant, what are you trying to model? What's the /actual/ application
>> you're doing?
>>
>> --
>> Søren Debois
>> Sent with Airmail
>>
>> Den 1. august 2016 kl. 13.20.47, ryan1...@gmail.com (ryan1...@gmail.com)
>> skrev:
>>
>>> Records, where each type has a different set of fields.
>>>
>>> On Aug 1, 2016, at 4:08 AM, debois  wrote:
>>>
>>> What actually goes in the lists? (As opposed to Foo, Bar etc.)
>>>
>>> --
>>> 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/8FNvfSguIq8/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 a topic in the
>>> Google Groups "Elm Discuss" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/elm-discuss/8FNvfSguIq8/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 a topic in the
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/elm-discuss/8FNvfSguIq8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Is there a better way to structure my List types?

[Nick H]

I don't mean to gloss over the fact that the length function you had to
write is a little verbose. But I don't think there are a lot of other
operations that would be applicable to every type of list in ThingList. For
instance, folding and mapping wouldn't work, because the fold/map function
would only work for one of the component types.

On Mon, Aug 1, 2016 at 6:51 AM, Nick H  wrote:

> The semantics are relevant because we want to avoid an XY scenario
> , which tend to come up a lot on this mailing
> list. Rest assured, Soren is only asking because he wants you to get the
> best help possible.  :-)
>
> It sounds to me like the approach you describe in the OP is the best way
> to model the data.
>
> Sure, your "reduce" function doesn't compile. But I don't think it would
> be that useful anyway. How many 1-arity functions are there that can
> operate on a list of *unspecified* type and return a value of a *specified
> *type? The only one I can think of is List.length.
>
> On Mon, Aug 1, 2016 at 4:49 AM, Ryan W  wrote:
>
>> I'm using this package
>> 
>> to display several different types of tables, with different sets of
>> columns. The actual number of tables and the data within them is dynamic,
>> but the types of tables are all definable ahead of time. Only one type of
>> table needs to be visible at one time, but users should be able to switch
>> back and forth between different tables. So, in my model I have a ThingList
>> called currentThingList which is rendered in the view, and a Dict that
>> holds all the ThingLists so the currentThingList can be set according to
>> the users' wishes.
>>
>> I don't see how the semantics of the data is relevant.
>>
>> On 1 August 2016 at 05:27, Søren Debois  wrote:
>>
>>> I meant, what are you trying to model? What's the /actual/ application
>>> you're doing?
>>>
>>> --
>>> Søren Debois
>>> Sent with Airmail
>>>
>>> Den 1. august 2016 kl. 13.20.47, ryan1...@gmail.com (ryan1...@gmail.com)
>>> skrev:
>>>
 Records, where each type has a different set of fields.

 On Aug 1, 2016, at 4:08 AM, debois  wrote:

 What actually goes in the lists? (As opposed to Foo, Bar etc.)

 --
 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/8FNvfSguIq8/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 a topic in the
 Google Groups "Elm Discuss" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/elm-discuss/8FNvfSguIq8/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 a topic in the
>>> Google Groups "Elm Discuss" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/elm-discuss/8FNvfSguIq8/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> elm-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] "I know what I'm doing"-syntax and helpful error messages for string interpolation

[Nick H]

I think the compiler would be far exceeding its job description if it was
trying to identify the language of every string! This sounds like it would
be better as part of a separate validation tool.

And of course, there's no telling when (if?!) string interpolation gets
added to the language. Right now we are stuck with (++) and concat.

On Mon, Aug 1, 2016 at 1:35 AM, Peter Damoc  wrote:

> I agree with Zach.
>
> "I know what I'm doing" is sometimes a shorthand for "WTF was I thinking 6
> months ago?". Just because it makes sense to you now it is not a guarantee
> that will continue to make sense forever.
>
> If you like to shoot yourself in the foot, Elm does not try to prevent you
> but it doesn't give you any gun either. You'll have to bring your own gun
> (JS). :)
>
>
>
>
>
> On Mon, Aug 1, 2016 at 10:34 AM, Zachary Kessin  wrote:
>
>> I dislike the idea of any syntax that will let me do something dumb and
>> let me "Fix it later" because that generally never happens
>>
>> Zach
>> ᐧ
>>
>> On Sun, Jul 31, 2016 at 11:15 PM, Filip Haglund 
>> wrote:
>>
>>> Keeping with the helpfullness of the compiler, having warnings when
>>> doing scetchy things with string interpolation (issue #905 on Github
>>> ) could be useful.
>>> This could be warnings about building urls's from variables that might be
>>> user input. It could also be about building SQL queries, or HTML.
>>>
>>> I suggest having some basic checks in the compiler for these areas where
>>> special care should be taken. This would generate warnings, assuming it is
>>> a mistake until proven otherwise.
>>>
>>> `"http://example.com/profile/{{userdata}}/"` would generate a warning.
>>> `"http://example.com/profile/{{[url] userdata }}/"`would not.
>>>
>>> `"My name is {{[url] userdata}}."`would generate a warning.
>>> `"My name is {{userdata}}."`would not.
>>>
>>> `"Check out my blog."`
>>> would generate a warning.
>>> `"Check out my blog."` would
>>> generate a warning.
>>> `"Check out my blog."`
>>> would not.
>>>
>>> `"Select * from users where username = '{{userdata}}'"` would generate a
>>> warning.
>>> `"Select * from users where username = '{{[html, url] userdata}}'"`
>>> would generate a warning.
>>> `"Select * from users where username = '{{[sql] userdata}}'"` would not.
>>>
>>> Exact syntax is not important right now. I want to know what the
>>> community thinks about the idea of "I know what I'm doing"-annotated string
>>> interpolation.
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> Zach Kessin
>> SquareTarget 
>> Twitter: @zkessin 
>> Skype: zachkessin
>>
>> --
>> 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.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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: Using Elm with jQuery (ports)

[OvermindDL1]

For future note, the Elm DOM is not created until the view function is run 
for the first time, which happens after init, which happens sometime 
'after' the elm app creation.  Always use callbacks to synch things, never 
assume any timing (my `cmd_delay` call I use heavily for such 
synchronization in ports for example).

On Monday, August 1, 2016 at 3:55:43 AM UTC-6, Matic Zavadlal wrote:
>
> Created ready event, which is triggered via Elm port and works! It's 
> similar to jQuery ready event.
>

-- 
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: Is there a better way to structure my List types?

[Ryan W]

I was thinking I might want List.take and List.drop for pagination purposes
but in seems like the easiest way in this particular case is to do all that
generic list manipulation ahead of time when I have the plain lists, before
I add the types. But if dynamic pagination was a hard requirement then it
seems like I'd be stuck filling out functions for every type.

On 1 August 2016 at 07:59, Nick H  wrote:

> I don't mean to gloss over the fact that the length function you had to
> write is a little verbose. But I don't think there are a lot of other
> operations that would be applicable to every type of list in ThingList. For
> instance, folding and mapping wouldn't work, because the fold/map function
> would only work for one of the component types.
>
> On Mon, Aug 1, 2016 at 6:51 AM, Nick H  wrote:
>
>> The semantics are relevant because we want to avoid an XY scenario
>> , which tend to come up a lot on this mailing
>> list. Rest assured, Soren is only asking because he wants you to get the
>> best help possible.  :-)
>>
>> It sounds to me like the approach you describe in the OP is the best way
>> to model the data.
>>
>> Sure, your "reduce" function doesn't compile. But I don't think it would
>> be that useful anyway. How many 1-arity functions are there that can
>> operate on a list of *unspecified* type and return a value of a *specified
>> *type? The only one I can think of is List.length.
>>
>> On Mon, Aug 1, 2016 at 4:49 AM, Ryan W  wrote:
>>
>>> I'm using this package
>>> 
>>> to display several different types of tables, with different sets of
>>> columns. The actual number of tables and the data within them is dynamic,
>>> but the types of tables are all definable ahead of time. Only one type of
>>> table needs to be visible at one time, but users should be able to switch
>>> back and forth between different tables. So, in my model I have a ThingList
>>> called currentThingList which is rendered in the view, and a Dict that
>>> holds all the ThingLists so the currentThingList can be set according to
>>> the users' wishes.
>>>
>>> I don't see how the semantics of the data is relevant.
>>>
>>> On 1 August 2016 at 05:27, Søren Debois  wrote:
>>>
 I meant, what are you trying to model? What's the /actual/ application
 you're doing?

 --
 Søren Debois
 Sent with Airmail

 Den 1. august 2016 kl. 13.20.47, ryan1...@gmail.com (ryan1...@gmail.com)
 skrev:

> Records, where each type has a different set of fields.
>
> On Aug 1, 2016, at 4:08 AM, debois  wrote:
>
> What actually goes in the lists? (As opposed to Foo, Bar etc.)
>
> --
> 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/8FNvfSguIq8/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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/8FNvfSguIq8/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 a topic in the
 Google Groups "Elm Discuss" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/elm-discuss/8FNvfSguIq8/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 elm-discuss+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elm-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/8FNvfSguIq8/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+unsub

[elm-discuss] Re: Is there a better way to structure my List types?

[OvermindDL1]

As another way to think about this, and I am unsure how Elm'ish this is 
(but it is very functional), you could invert your lists into being 
functions, then pass in commands to operate on the internal lists.  This is 
how some functional list implementations are developed especially when 
missing HKT's like Elm is (when is Elm getting HKT's anyway?).


On Monday, August 1, 2016 at 1:46:53 AM UTC-6, Ryan W wrote:
>
> I want to be able to store several different types of lists in a single 
> data structure, and and each type of list should be treated differently by 
> the view function.
>
> What I've tried:
> type ThingList
> = FooList (List Foo)
> | BarList (List Bar)
> | BazList (List Baz)
>
>
> This works okay, but if I want to do something like get the length of a 
> ThingList without caring about whether it is a FooList, BarList or BazList 
> it seems I have to have to write something like this:
>
> length : ThingList
> length thingList =
> case thingList of
> FooList list ->
> List.length list
>
> BarList list ->
> List.length list
>
> BazList list ->
> List.length list
>
> Since in my actual program I plan to have several more sub-types in the 
> actual counterpart to ThingList this becomes somewhat cumbersome and it 
> definitely isn't DRY. I guess this is a form of the expression problem? 
>  I tried to generalize 
> it a bit so I wouldn't have to update as many of these functions when I add 
> a new sub-type like this:
> reduce : (List a -> b) -> EntityList -> b
> reduce f entityList =
> case entityList of
> FooList list ->
> f list
>
> BarList list ->
> f list
>
> BazList list ->
> f list
>
> but that gave me an error like this:
>
> Function `f` is expecting the argument to be: List Foo But it is: List Bar
>
> In my particular case, at least for now, I only wanted the length of a 
> ThingList literal so I can work around it, but I'm curious if there is 
> way to structure the types that avoids this problem.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: How to decode JSON object with more than 8 fields?

[Aditya Vishwakarma]

If you wish to know how to do it, then take a look at this 
: https://github.com/adityav/elm-reddit-listing/blob/master/src/Decoders.elm#L14

Once you understand how it is done, you can 
use http://package.elm-lang.org/packages/NoRedInk/elm-decode-pipeline/1.1.2 
package. 

On Monday, 1 August 2016 17:51:24 UTC+5:30, Petr Huřťák wrote:
>
> For 8 fields or less I can do
>
> import Json.Decode as Decode exposing ((:=))
>
> collectionDecoder : Decode.Decoder (List Test)
> collectionDecoder =
> Decode.list
> (Decode.object8 Test
> ("id" := Decode.int)
> ...
> )
>
>
> How to decode JSON object with more than 8 fields?
>

-- 
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: Is there a better way to structure my List types?

[Nick H]

Every data type is going to need its own view function, right? (I am
assuming your thingList corresponds to the "List data" argument to
Table.view.) It seems like that would be the logical place to put the
pagination logic.

Your pagination could be encapsulated by a function like "paginate : Config
-> List a -> List a" that is perfectly generic and calls List.take or
whatever. Each of your view functions could then call this function.

Yes, the call to paginate would be duplicated in each of your view
functions, but it is a better sort of duplication than, say, defining
take/drop on your over-arching ThingList type and having tons of case
statements. It will be easier to maintain, and easier on the eyes!

In my (recent, painful) experience, Elm works much better when you focus on
"vertical encapsulation" -- your main union type has a case statement in
your outer "update" function, your outer "view" function, and nowhere else.
What you are trying to do with your list operations, I would describe as
"horizontal encapsulation" -- trying to define as many operations as
possible on your main union type.

If you focus on vertical encapsulation, Elm will make your life easy. If
you focus on horizontal encapsulation, Elm will be your enemy every step of
the way.

On Mon, Aug 1, 2016 at 7:29 AM, OvermindDL1  wrote:

> As another way to think about this, and I am unsure how Elm'ish this is
> (but it is very functional), you could invert your lists into being
> functions, then pass in commands to operate on the internal lists.  This is
> how some functional list implementations are developed especially when
> missing HKT's like Elm is (when is Elm getting HKT's anyway?).
>
>
> On Monday, August 1, 2016 at 1:46:53 AM UTC-6, Ryan W wrote:
>>
>> I want to be able to store several different types of lists in a single
>> data structure, and and each type of list should be treated differently by
>> the view function.
>>
>> What I've tried:
>> type ThingList
>> = FooList (List Foo)
>> | BarList (List Bar)
>> | BazList (List Baz)
>>
>>
>> This works okay, but if I want to do something like get the length of a
>> ThingList without caring about whether it is a FooList, BarList or
>> BazList it seems I have to have to write something like this:
>>
>> length : ThingList
>> length thingList =
>> case thingList of
>> FooList list ->
>> List.length list
>>
>> BarList list ->
>> List.length list
>>
>> BazList list ->
>> List.length list
>>
>> Since in my actual program I plan to have several more sub-types in the
>> actual counterpart to ThingList this becomes somewhat cumbersome and it
>> definitely isn't DRY. I guess this is a form of the expression problem?
>>  I tried to generalize
>> it a bit so I wouldn't have to update as many of these functions when I add
>> a new sub-type like this:
>> reduce : (List a -> b) -> EntityList -> b
>> reduce f entityList =
>> case entityList of
>> FooList list ->
>> f list
>>
>> BarList list ->
>> f list
>>
>> BazList list ->
>> f list
>>
>> but that gave me an error like this:
>>
>> Function `f` is expecting the argument to be: List Foo But it is: List Bar
>>
>> In my particular case, at least for now, I only wanted the length of a
>> ThingList literal so I can work around it, but I'm curious if there is
>> way to structure the types that avoids this problem.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: Is there a better way to structure my List types?

[Ryan W]

Doing pagination in the view after the case statement like that does sound
a lot better than what I was thinking of.

Your advice about vertical encapsulation is interesting. I'll keep it in
mind.

On 1 August 2016 at 09:28, Nick H  wrote:

> Every data type is going to need its own view function, right? (I am
> assuming your thingList corresponds to the "List data" argument to
> Table.view.) It seems like that would be the logical place to put the
> pagination logic.
>
> Your pagination could be encapsulated by a function like "paginate :
> Config -> List a -> List a" that is perfectly generic and calls List.take
> or whatever. Each of your view functions could then call this function.
>
> Yes, the call to paginate would be duplicated in each of your view
> functions, but it is a better sort of duplication than, say, defining
> take/drop on your over-arching ThingList type and having tons of case
> statements. It will be easier to maintain, and easier on the eyes!
>
> In my (recent, painful) experience, Elm works much better when you focus
> on "vertical encapsulation" -- your main union type has a case statement in
> your outer "update" function, your outer "view" function, and nowhere else.
> What you are trying to do with your list operations, I would describe as
> "horizontal encapsulation" -- trying to define as many operations as
> possible on your main union type.
>
> If you focus on vertical encapsulation, Elm will make your life easy. If
> you focus on horizontal encapsulation, Elm will be your enemy every step of
> the way.
>
> On Mon, Aug 1, 2016 at 7:29 AM, OvermindDL1  wrote:
>
>> As another way to think about this, and I am unsure how Elm'ish this is
>> (but it is very functional), you could invert your lists into being
>> functions, then pass in commands to operate on the internal lists.  This is
>> how some functional list implementations are developed especially when
>> missing HKT's like Elm is (when is Elm getting HKT's anyway?).
>>
>>
>> On Monday, August 1, 2016 at 1:46:53 AM UTC-6, Ryan W wrote:
>>>
>>> I want to be able to store several different types of lists in a single
>>> data structure, and and each type of list should be treated differently by
>>> the view function.
>>>
>>> What I've tried:
>>> type ThingList
>>> = FooList (List Foo)
>>> | BarList (List Bar)
>>> | BazList (List Baz)
>>>
>>>
>>> This works okay, but if I want to do something like get the length of a
>>> ThingList without caring about whether it is a FooList, BarList or
>>> BazList it seems I have to have to write something like this:
>>>
>>> length : ThingList
>>> length thingList =
>>> case thingList of
>>> FooList list ->
>>> List.length list
>>>
>>> BarList list ->
>>> List.length list
>>>
>>> BazList list ->
>>> List.length list
>>>
>>> Since in my actual program I plan to have several more sub-types in the
>>> actual counterpart to ThingList this becomes somewhat cumbersome and it
>>> definitely isn't DRY. I guess this is a form of the expression problem?
>>>  I tried to
>>> generalize it a bit so I wouldn't have to update as many of these functions
>>> when I add a new sub-type like this:
>>> reduce : (List a -> b) -> EntityList -> b
>>> reduce f entityList =
>>> case entityList of
>>> FooList list ->
>>> f list
>>>
>>> BarList list ->
>>> f list
>>>
>>> BazList list ->
>>> f list
>>>
>>> but that gave me an error like this:
>>>
>>> Function `f` is expecting the argument to be: List Foo But it is: List
>>> Bar
>>>
>>> In my particular case, at least for now, I only wanted the length of a
>>> ThingList literal so I can work around it, but I'm curious if there is
>>> way to structure the types that avoids this problem.
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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/8FNvfSguIq8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Is there a better way to structure my List types?

[Nick H]

I may have oversold it there at the end :-P, but I have been doing some
major refactoring lately and am very pleased with the results so far.
Please keep sharing your experiences!

On Mon, Aug 1, 2016 at 8:49 AM, Ryan W  wrote:

> Doing pagination in the view after the case statement like that does sound
> a lot better than what I was thinking of.
>
> Your advice about vertical encapsulation is interesting. I'll keep it in
> mind.
>
> On 1 August 2016 at 09:28, Nick H  wrote:
>
>> Every data type is going to need its own view function, right? (I am
>> assuming your thingList corresponds to the "List data" argument to
>> Table.view.) It seems like that would be the logical place to put the
>> pagination logic.
>>
>> Your pagination could be encapsulated by a function like "paginate :
>> Config -> List a -> List a" that is perfectly generic and calls List.take
>> or whatever. Each of your view functions could then call this function.
>>
>> Yes, the call to paginate would be duplicated in each of your view
>> functions, but it is a better sort of duplication than, say, defining
>> take/drop on your over-arching ThingList type and having tons of case
>> statements. It will be easier to maintain, and easier on the eyes!
>>
>> In my (recent, painful) experience, Elm works much better when you focus
>> on "vertical encapsulation" -- your main union type has a case statement in
>> your outer "update" function, your outer "view" function, and nowhere else.
>> What you are trying to do with your list operations, I would describe as
>> "horizontal encapsulation" -- trying to define as many operations as
>> possible on your main union type.
>>
>> If you focus on vertical encapsulation, Elm will make your life easy. If
>> you focus on horizontal encapsulation, Elm will be your enemy every step of
>> the way.
>>
>> On Mon, Aug 1, 2016 at 7:29 AM, OvermindDL1 
>> wrote:
>>
>>> As another way to think about this, and I am unsure how Elm'ish this is
>>> (but it is very functional), you could invert your lists into being
>>> functions, then pass in commands to operate on the internal lists.  This is
>>> how some functional list implementations are developed especially when
>>> missing HKT's like Elm is (when is Elm getting HKT's anyway?).
>>>
>>>
>>> On Monday, August 1, 2016 at 1:46:53 AM UTC-6, Ryan W wrote:

 I want to be able to store several different types of lists in a single
 data structure, and and each type of list should be treated differently by
 the view function.

 What I've tried:
 type ThingList
 = FooList (List Foo)
 | BarList (List Bar)
 | BazList (List Baz)


 This works okay, but if I want to do something like get the length of a
 ThingList without caring about whether it is a FooList, BarList or
 BazList it seems I have to have to write something like this:

 length : ThingList
 length thingList =
 case thingList of
 FooList list ->
 List.length list

 BarList list ->
 List.length list

 BazList list ->
 List.length list

 Since in my actual program I plan to have several more sub-types in the
 actual counterpart to ThingList this becomes somewhat cumbersome and
 it definitely isn't DRY. I guess this is a form of the expression
 problem?  I tried to
 generalize it a bit so I wouldn't have to update as many of these functions
 when I add a new sub-type like this:
 reduce : (List a -> b) -> EntityList -> b
 reduce f entityList =
 case entityList of
 FooList list ->
 f list

 BarList list ->
 f list

 BazList list ->
 f list

 but that gave me an error like this:

 Function `f` is expecting the argument to be: List Foo But it is: List
 Bar

 In my particular case, at least for now, I only wanted the length of a
 ThingList literal so I can work around it, but I'm curious if there is
 way to structure the types that avoids this problem.

 --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elm-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> 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/8FNvfSguIq8/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 su

Re: [elm-discuss] "I know what I'm doing"-syntax and helpful error messages for string interpolation

[Magnus Rundberget]

Well a step up from ++ and concat would be 
http://package.elm-lang.org/packages/krisajenkins/formatting/3.0.0/Formatting

-magnus

-- 
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] Equality Error Undecidable

[Mark Hamburg]

I think I'm going to revise my stance on how this issue should be handled. I am 
now gong to argue that function equality should be handled via object identity 
— i.e., two closures constructed at different times are necessarily unequal.

What this breaks is referential transparency and more specifically it means 
that compiler optimizations could change the results computed by programs. That 
last point seems disturbing, but let's consider what this really means. The 
issue of concern is that the compiler could decide to lift a closure 
construction and thereby make more things that weren't equal to each other in 
the un-optimized code now equal to each other.

I think it would be reasonable to say "don't use functions as a way to cause 
things to be unequal because if you do that may not survive compiler 
optimization." This seems at least as reasonable as saying "don't compare 
functions or structures containing functions because the program might throw a 
runtime exception if you do".

If it really seems of concern, then write a non-fatal message to the console 
log whenever comparing functions that aren't equal via object identity and 
aren't obviously non-equal because they say reference different pieces of code 
for their definitions (though of course even that raises questions about what 
it means for functions to be equal).

But my basic argument now is that it seems better to fail at referential 
transparency than to throw runtime errors.

Mark

-- 
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] Elm Records as a platform-agnostic data type?

[suttlecommakevin]

http://elm-lang.org/docs/records 

Much in the same spirit as EDN, Datomic, Ion, etc., would it make sense to 
enable non-Elm programs to describe data in Elm Record format? 
The simplicity and readability offer so many advantages. 

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: How to decode JSON object with more than 8 fields?

[Pablo Parga]

This is a great tool to encode/decode 
: http://noredink.github.io/json-to-elm/

El lunes, 1 de agosto de 2016, 11:11:04 (UTC-4), Aditya Vishwakarma 
escribió:
>
> If you wish to know how to do it, then take a look at this : 
> https://github.com/adityav/elm-reddit-listing/blob/master/src/Decoders.elm#L14
>
> Once you understand how it is done, you can use 
> http://package.elm-lang.org/packages/NoRedInk/elm-decode-pipeline/1.1.2 
> package. 
>
> On Monday, 1 August 2016 17:51:24 UTC+5:30, Petr Huřťák wrote:
>>
>> For 8 fields or less I can do
>>
>> import Json.Decode as Decode exposing ((:=))
>>
>> collectionDecoder : Decode.Decoder (List Test)
>> collectionDecoder =
>> Decode.list
>> (Decode.object8 Test
>> ("id" := Decode.int)
>> ...
>> )
>>
>>
>> How to decode JSON object with more than 8 fields?
>>
>

-- 
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] Elm Records as a platform-agnostic data type?

[Joey Eremondi]

I'm not sure this is a great idea.

Syntax-wise, Elm records aren't different that much from JSON. But in terms
of semantics, they can store any Elm value, which includes functions and
other things that can't be serialized well.

At the end of the day, an Elm record is just a mapping from names to
values, whose names are known at compile time. So it shouldn't be too hard
to make that work in other languages.

On Mon, Aug 1, 2016 at 12:28 PM, suttlecommakevin <
suttlecommake...@gmail.com> wrote:

> http://elm-lang.org/docs/records
>
> Much in the same spirit as EDN, Datomic, Ion, etc., would it make sense to
> enable non-Elm programs to describe data in Elm Record format?
> The simplicity and readability offer so many advantages.
>
> --
> 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] Scheduling tasks

[Nikolai Koudelia]

Hi!

I need to schedule a task to be executed after a second but I can't really 
find a suitable function.

There is Time.now but I need Time.now + 1 second. There is also Time.every 
but I need the task to be triggered only once and only starting from some 
user action (e.g. clicking a button).

I guess I could use ports and subscribe for an action to be responded on 
the Javascript side using setTimeout()... but it just feels so awkward. 
Isn't there anything like "Time.after : Time -> Task x msg" existing?

BR
Nikolai

-- 
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] Scheduling tasks

[Max Goldstein]

Process.sleep (1*Time.second)

Then use Task.andThen to perform your task. 

-- 
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] Equality Error Undecidable

[Janis Voigtländer]

That’s what this pull request 
would have achieved.
​

2016-08-01 20:56 GMT+02:00 Mark Hamburg :

> I think I'm going to revise my stance on how this issue should be handled.
> I am now gong to argue that function equality should be handled via object
> identity — i.e., two closures constructed at different times are
> necessarily unequal.
>
> What this breaks is referential transparency and more specifically it
> means that compiler optimizations could change the results computed by
> programs. That last point seems disturbing, but let's consider what this
> really means. The issue of concern is that the compiler could decide to
> lift a closure construction and thereby make more things that weren't equal
> to each other in the un-optimized code now equal to each other.
>
> I think it would be reasonable to say "don't use functions as a way to
> cause things to be unequal because if you do that may not survive compiler
> optimization." This seems at least as reasonable as saying "don't compare
> functions or structures containing functions because the program might
> throw a runtime exception if you do".
>
> If it really seems of concern, then write a non-fatal message to the
> console log whenever comparing functions that aren't equal via object
> identity and aren't obviously non-equal because they say reference
> different pieces of code for their definitions (though of course even that
> raises questions about what it means for functions to be equal).
>
> But my basic argument now is that it seems better to fail at referential
> transparency than to throw runtime errors.
>
> Mark
>
> --
> 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] How are deeply nested records updated or what alternatives are typically used?

[Austin B]

Hi,

I come from an OOP background and trying to make the leap to keeping all 
state in a single immutable data store, which has shown to be amazing as 
long as the system is small, but I am having trouble scaling up to anything 
beyond a toy app.

One big challenge is trying to update nested fields. For example if I want 
to change a forecast parameter in the following code:

-- Model
type alias Forecast =
  { parameters: Pf.ArpsParameters
  , production: List Float
  }
type alias Model =
  { primaryForecast: Forecast
  , secondaryForecast: Forecast
  }

-- Init

init : (Model, Cmd Msg)
init =
  (
{ primaryForecast =
  { parameters =
{ q = Nothing
, de = Nothing
, c = Nothing
, months = [0..48]
}
  , production = []
  }
}
, Cmd.none
  )


I end up with code like this:

update : Msg -> Model -> (Model, Cmd Msg)
update msg model =
  let
primaryForecast = model.primaryForecast
parameters = model.primaryForecast.parameters
  in
case msg of
  Q string -> ({ model | primaryForecast = { primaryForecast | 
parameters = { parameters | q = toMaybe (String.toFloat string) } } }, 
message UpdateProduction)
  De string -> ({ model | primaryForecast = { primaryForecast | 
parameters = { parameters | de = toMaybe (String.toFloat string) } } }, 
message UpdateProduction)
  C string -> ({ model | primaryForecast = { primaryForecast | 
parameters = { parameters | c = toMaybe (String.toFloat string) } }}, 
message UpdateProduction)
  UpdateProduction -> ...


This seems unnecessarily verbose, and I'm unsure whether I am turning wrong 
with how I am structuring data or if I am trying to modify data incorrectly.

Thanks for any help!

Austin

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