[elm-discuss] Re: Pre-requisites for learning Elm?

[OvermindDL1]

That is a very good point, you can make a lot of cool things in pure elm, I 
whipped up an incremental clicker in an hour a few days ago when I was 
screwing around, dead simple.  ^.^


On Monday, October 24, 2016 at 4:44:53 PM UTC-6, joseph ni wrote:
>
> Hey Razi,
>
> That sounds great! I wish I was where you are now. In my first computing 
> course, I was expected to learn Haskell and assembly, we didn't have google 
> back then, nor wikipedia, blog sites, free online courses, and I was plenty 
> lost too.
>
> One of the most valuable experience that I got from uni was learning how 
> to be resourceful and learn things. Elm is a perfectly beginner friendly 
> language. It goes out of it's way to be beginner friendly. Don't let a lack 
> of html/css/js knowledge worry you. Get in there with a goal of what you 
> want to create and do it.
> Join the elm slack channel and ask for help in #help, #general, 
> #beginners, pick up a free html/css course over at khan academy, codeschool 
> etc..., ask a class mate about stuff you're confused about, approach your 
> prof and tell him/her your worries. All these resources are there, so start 
> using it!
>
> I started doing elm 6 months ago, in that time, I've built up to ~7000 
> lines in my game, it contains no javascript and the majority of the code 
> (~6500 lines) has nothing to do with html/css.
>
> Programming is about problem solving and creativity, Elm is an absolutely 
> fantastic language and you can't get much better than starting out with it 
> imo, so persist, give it your best and don't be afraid to try. See you on 
> elm slack ;)
>
> On Monday, 24 October 2016 08:22:22 UTC+11, Razi Syed wrote:
>>
>> Hi everyone, I've never programmed before and in my first year course 
>> we're doing Elm. The prof expects us to learn Elm on our own, and simply 
>> does examples in class applying what he thinks we should have learned. 
>> Problem is, I'm totally lost. Some people are telling me you're supposed to 
>> know HTML and CSS before Elm. Even the official elm guide seems like it 
>> assumes you know HTML and CSS and javascript (note: I simply know the names 
>> of these languages and nothing about them), or have programmed in a 
>> non-functional programming.
>>
>

-- 
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] Proposal: rename foldl til foldLeft and foldr to foldRight

[Max Goldstein]

I would love more Ruby-like names across the board, except for the presence of 
aliases, but Elm grew out of Haskell so it carries some of that history. 

It really comes down to what Evan wants to do. People come to Elm from many 
languages, and everyone has preferences. Changing things makes upgrading 
harder, invalidates old code, and gives the larger community the impression 
that Elm is not stable. 

-- 
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: IntelliJ (WebStorm) devs, how do you read the compiler errors?

[Carlos Poon]

@Birowsky - Hi Daniel, sorry last screenshot was a bit too wide:


So this is going to sound a little crazy, but it seems like we can put in 
custom config files for linters, so maybe this might be useful OR it might 
be me taking a wild stab in the dark, and looking like a fool.

-- 
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: IntelliJ (WebStorm) devs, how do you read the compiler errors?

[Carlos Poon]

@Birowsky - Hi Daniel,

This is as much as I can get, in terms of errors:



Also, this may be a red herring, but do you think that is might be of some 
use: ( it is a bit of a random guess ):



This is al guess work for me, so apologies if I'm off the mark.

On Tuesday, October 25, 2016 at 12:11:26 AM UTC+1, Birowsky wrote:
>
> @Keith I have just the man for that. My colleague uses Kotlin for the 
> backend, this is how hard his life is:
>
>
> 
> hover over the 5:
>
>
> 
>
> So yeah, i envy this guy :}
>
>
> @Carlos, Keith has nailed what i hope for in his comment, and is nicely 
> depicted in the scrshots above. Thanx for your approach btw, I would 
> definitely be trying it out.
>
> @Joseph catching the errors on the preview screen is not bad, but i'm 
> mostly on my laptop, so i would rather try to come up with something 
> similar to what Carlos has going on for him self.
>
>
> So i know we are far from what Kotlin has going on for it's users, but i 
> still have hope that we might be able to utilize one of the many features 
> intellij is offering. For example, I noticed this thing in external tools:
>
>
> 
>
> So there is a way to open the console only if it had spit out an error. 
> Say we succeed in that (which would be so awesome), there is also the Output 
> Filters Dialog 
> 
>  which 
> reportedly lets you manage the output filters associated with an external 
> tool. (The output filters are used to turn absolute file paths and line 
> numbers in the tool output into hyperlinks.) It simply means that we could 
> configure it link the compiler error line numbers to the actual line number 
> in file.
>
> Now I could try to come up with such configuration, but since I haven't 
> done any serious IntelliJ tweaking, i would expect you guys to beat me to 
> 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.

Re: [elm-discuss] Proposal: rename foldl til foldLeft and foldr to foldRight

[Brian Marick]

> On Oct 20, 2016, at 9:12 AM, Robin Heggelund Hansen  
> wrote:
> 
> In Elm 0.18, primes are being removed as valid characters in a 
> variable/function name. 


That’s unfortunate. Non-alphabetical characters can be really useful for 
signaling intent.

For example, an ending  can usefully be a quick signal that the function is 
a boolean predicate. That’s less useful in a statically-typed language, but 
“less useful” is not the same thing as “useless”. 

Adding a prime mark has a long, even pre-computer, history of signaling.  
quickly tells the reader that the value is intimately bound up with  but has 
a contextually relevant difference. To be less abstract:

When working with SVG, it’s really awkward that `Svg.Attributes.x` takes a 
String argument, given that graphics often involves working with numeric 
values. So it’s not a horrible idea for graphics code to establish a convention 
that primed names take a (consistently, thus predictably) nonstandard type. 

I confidently predict that removing primes won’t result in `xInteger` 
definitions but rather `x2` - which I’d argue is less clear than x’

I could imagine libraries that said explicitly “In this library, functions 
doing  use the <‘> suffix, but functions doing  
use . (Neither Ruby nor Clojure are really consistent, but experienced users 
know roughly how to react to functions ending in .) Community pressure could 
help with that. 

-- 
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: IntelliJ (WebStorm) devs, how do you read the compiler errors?

[Birowsky]

@Keith I have just the man for that. My colleague uses Kotlin for the 
backend, this is how hard his life is:


hover over the 5:



So yeah, i envy this guy :}


@Carlos, Keith has nailed what i hope for in his comment, and is nicely 
depicted in the scrshots above. Thanx for your approach btw, I would 
definitely be trying it out.

@Joseph catching the errors on the preview screen is not bad, but i'm 
mostly on my laptop, so i would rather try to come up with something 
similar to what Carlos has going on for him self.


So i know we are far from what Kotlin has going on for it's users, but i 
still have hope that we might be able to utilize one of the many features 
intellij is offering. For example, I noticed this thing in external tools:



So there is a way to open the console only if it had spit out an error. Say 
we succeed in that (which would be so awesome), there is also the Output 
Filters Dialog 

 which 
reportedly lets you manage the output filters associated with an external 
tool. (The output filters are used to turn absolute file paths and line 
numbers in the tool output into hyperlinks.) It simply means that we could 
configure it link the compiler error line numbers to the actual line number 
in file.

Now I could try to come up with such configuration, but since I haven't 
done any serious IntelliJ tweaking, i would expect you guys to beat me to 
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: How do you name messages?

[Birowsky]

Thanx for this discussion, fellas. I cannot fully digest it at the moment, 
but I'm sure I'll be coming back to this as I go.

-- 
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: Metalinguistic abstractions over databases

[John Kelly]

On Monday, October 24, 2016 at 1:15:14 PM UTC-7, Peter Damoc wrote:
>
> Think about the role that a ORM is playing. What I want to understand is 
> what would a functional equivalent would look like in Elm.
>
> What would sit above graphQL or REST or some other lower level tech?
>
> Another way to look at this would be to take the Json.Decode/Encode as 
> example and imagine that one has the equivalent of a Decoder only that it 
> would be some kind of a descriptor used by some lower level library that 
> does the queries based on that descriptor data. 
> Maybe this descriptor uses something like Datalog.
>

Unless I'm mistaken, that is the goal I have set for elm-postgrest 
. The equivalent of a 
`Decoder` in my library is a `Query`. I build the Query up in the same 
fashion that Decoders are built (with some extra functionality for 
filtering and ordering and such). The high level `Query` (descriptor as you 
called it) is then converted into an PostgREST compliant HTTP Request. I 
have yet to work out the write api -- which is undoubtably a large portion 
-- however I am convinced (egotistical, i know) that the library is moving 
in the right direction. 

I think the tricky part is that the API/functionality of the client is 
tightly coupled to to functionality of the server. This is why I have 
scoped my library to *only *support PostgREST. It is not always the case 
that the server supports all of the things (nesting, filtering, ordering, 
pagination, limit, offset, etc). I am unsure if you are suggesting that a 
general API *could *exist which encompasses all backends. I originally 
tried to create a general API, but quickly came to the conclusion that such 
a task was quite tricky.

Overall, (once again sorry for the plug) I think that elm-postgrest 
 has made some decent steps in 
the right direction, and I think a more thorough audit / usage of the code 
could bring this conversation to another level. (also, for those too lazy 
to look up PostgREST -- it's basically the same as graphql -- but 0 coding 
required. some fancy people might say "isomorphic")


-- 
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: Metalinguistic abstractions over databases

[Peter Damoc]

I cannot provide sample code because I don't have a clear idea how the API
could look.

Think about the role that a ORM is playing. What I want to understand is
what would a functional equivalent would look like in Elm.

What would sit above graphQL or REST or some other lower level tech?

Another way to look at this would be to take the Json.Decode/Encode as
example and imagine that one has the equivalent of a Decoder only that it
would be some kind of a descriptor used by some lower level library that
does the queries based on that descriptor data.
Maybe this descriptor uses something like Datalog.

Another way to think about this is to try to imagine what would it take to
reduce the cognitive overload of a beginner that does not really care that
much about how the data is retrieved/saved remotely but cares to have the
functionality present.






On Mon, Oct 24, 2016 at 11:01 PM, John Kelly  wrote:

> On Monday, October 24, 2016 at 8:33:55 AM UTC-7, Peter Damoc wrote:
>>
>> I'm more interested in how one would solve this in a multilayer system
>> where the actual remote persistence is abstracted from the app.
>>
>> The actual remote persistence might be implemented with REST, or it might
>> be some kind of websockets thing.
>> It might involve a SQL database, or maybe a NoSQL database.
>> It might be something like Datomic.
>>
>> I'm interested in how would one implement this abstraction, this *separation
>> of concerns*.
>>
>
> Could you provide more details of what you are looking for? Or some sample
> code?
>
> Are you interested in how one would abstract away the data consumption?
> What I mean by that is: The library user simply requests data and the
> library determines if it needs to make an API call or if it can just get
> the data from localStorage.
>
> --
> 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: Metalinguistic abstractions over databases

[John Kelly]

On Monday, October 24, 2016 at 8:33:55 AM UTC-7, Peter Damoc wrote:
>
> I'm more interested in how one would solve this in a multilayer system 
> where the actual remote persistence is abstracted from the app. 
>
> The actual remote persistence might be implemented with REST, or it might 
> be some kind of websockets thing.
> It might involve a SQL database, or maybe a NoSQL database. 
> It might be something like Datomic. 
>
> I'm interested in how would one implement this abstraction, this *separation 
> of concerns*. 
>

Could you provide more details of what you are looking for? Or some sample 
code?

Are you interested in how one would abstract away the data consumption? 
What I mean by that is: The library user simply requests data and the 
library determines if it needs to make an API call or if it can just get 
the data from localStorage.

-- 
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] Naming functions

[Mark Hamburg]

Elm style puts the items last so that you can write:

items |> replaceItemById id item

On Monday, October 24, 2016, Lars Jacobsson 
wrote:

> | The names were inspired by Dict.insert and Dict.update, which were the
> closest to what I was looking for.
>
> Yeah, I'm probably just too used to that dot notation.
>
>
> I don't know why but
> items.replaceItemById id item
> looks better than
> replaceItemById items id item
> . Somehow it feels like a standalone function named "replaceItemById"
> won't give us a list in return. But taking your idea to heart this would
> then be something like itemsUpdateById
>
> --
> 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] Proposal: Add Debug.breakpoint to core

[Nick H]

That makes total sense. Being able to monitor model updates in debug mode
isn't the same as being able to step through the call stack. Being able to
do the latter by setting breakpoints would be useful.

On Mon, Oct 24, 2016 at 11:24 AM, Robin Heggelund Hansen <
skinney...@gmail.com> wrote:

> I've done a lot of library work lately where Cmds and Subs haven't been a
> part of the project, so yes, in a project where the main way to run your
> code is through fuzz tests, breakpoints would be immensively helpful.
>
> That being said, having a Debug.breakpoint function is just a convenience,
> not a necessity.
>
> mandag 24. oktober 2016 19.34.53 UTC+2 skrev Nick H følgende:
>>
>> Don't forget, the time-travelling debug mode is coming in 0.18. Do you
>> think setting breakpoints like this is still going to be useful?
>>
>> On Mon, Oct 24, 2016 at 5:59 AM, Robin Heggelund Hansen <
>> skinn...@gmail.com> wrote:
>>
>>> Elm, as great as it is, doesn't save you from debugging every once in a
>>> while. The one option we have now, is logging. Logging is great, but it can
>>> quickly become painful in loops. Since Elm compiles to a single JS file
>>> with long mangled names, setting a breakpoint from the code would sometimes
>>> be the simplest way to properly debug your code. The generated JS isn't
>>> that hard to understand either, it's a series of vars and function calls
>>> for the most part.
>>>
>>> lørdag 22. oktober 2016 13.49.52 UTC+2 skrev John Orford følgende:

 It never occurred to me to debug the generated JS... can you sketch out
 your use case a bit more?

 On Sat, 22 Oct 2016 at 11:19 Robin Heggelund Hansen 
 wrote:

> While I spend a lot less time debugging in Elm than in JS, sometimes
> it's useful to debug the generated Javascript.
>
> This would be greatly simplified, if it was possible to add a
> `debugger;` statement to the code.
>
> What do people think of a new function added to the Debug module of
> elm-lang/core, called breakpoint. It would work like the identity 
> function,
> but also include the `debugger;` statement, causing a breakpoint to happen
> when the browsers dev-tools are open.
>
> used like:
>
> ```
> faultyFunction a b =
>   let
>  _ = Debug.breakpoint ()
>   in
> a + b
> ```
>
> Granted, this would cause a breakpoint to happen in the actual
> Debug.breakpoint function, but since that function is very small, stepping
> out of it is no big deal. The only other option I can think of is compiler
> support, but I'm unsure how hard this would be to include.
>
> Opinions?
>
> --
> 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.
>

-- 
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] Structure for large Elm apps

[Erik Lott]

>
> Above all of this, the other key subdivision we are making in our SPA and 
> that I would recommend having seen where other programmers often first 
> head, is having a top layer that handles overall app state — e.g., logged 
> in v not logged in — as a type union. This can also often be where the 
> routing logic plugs in. 


This is exactly what we do throughout our entire SPA app. We use union 
types to manage overall state and protect our invariants, making it 
impossible for the app to be in an invalid state at any time. The union 
types may get a little deep at times, but the payoff is more than worth it. 

On Sunday, October 23, 2016 at 3:29:23 PM UTC-4, Mark Hamburg wrote:
>
> We're just getting into having an app where this is likely to matter, but 
> if you have multiple views onto the same data, then the pattern that would 
> seem to apply is to have a single data model and multiple view models. The 
> data model handles the shared part. The view models handle things specific 
> to the particular view — e.g., is a spin down open, what's the scroll 
> position, etc. The view functions would take the data model and their 
> particular view model as parameters and would generate appropriately tagged 
> messages back. This avoids significant nesting while still providing some 
> structure to keep pieces that can be separated separate.
>
> There are then a couple ways to structure the multiple view models. One is 
> to have a view selector but keep all of the view models alive all the time. 
> The benefit of this is that when you switch back to a view, it will 
> remember where you were. The downside is that one is carrying around — and 
> potentially updating if the view model depends on the data model — an 
> increasing number of view models if you have an increasing number of views. 
> The alternative is to put the view models into a union type and have one 
> model entry that serves as both view selector and view model storage. This 
> keeps things lighter weight but means that you have nowhere to maintain 
> context when switching back and forth.
>
> Above all of this, the other key subdivision we are making in our SPA and 
> that I would recommend having seen where other programmers often first 
> head, is having a top layer that handles overall app state — e.g., logged 
> in v not logged in — as a type union. This can also often be where the 
> routing logic plugs in. People who haven't spent a lot of time thinking in 
> terms of type unions tend to load their model up with a lot of fields that 
> only have meaning in certain states. This then leads to more invariants 
> about the state that can't be enforced by the compiler. Breaking things up 
> into different type cases for different states allows one to make more bad 
> states simply impossible. For example, our logging in state has a 
> RemoteData.WebData User reflecting whether we've gotten valid user data 
> back from the server but our logged in state simply has a User. The top 
> level event dispatcher works with the following type signature on the log 
> in state update:
>
> update : Login.Msg -> Login.Model -> ( Login.Model, Cmd Login.Msg, Maybe 
> User )
>
>
> After each call to update, it can check to see whether we now have a valid 
> user and if so switch to the logged in state, initializing it with the 
> supplied user.
>
> This isn't as flat as some people go, but it doesn't spread things out 
> into lots of components and the top layer(s) are pretty simple.
>
> Mark
>
>
> On Sun, Oct 23, 2016 at 11:39 AM, Francois  > wrote:
>
>> Hi,
>>
>> I'm really new to Elm. I'm not good enough to propose a guideline about 
>> Elm app structure but as a novice a guideline can help lots of people.
>>
>> I worked / works on a large angular application and John Papa Styleguide 
>> has been really helpful at the beginning.
>> So writing a community guideline can be a great resource. (there is 
>> another thread inter component that seems related)
>>
>> For example, on the server side, structuring domain core by features is 
>> good thing (for me). Help define some boundaries and help maintability. 
>> Grouping all Java classes by technical aspect at the project root : all 
>> services in one package, all models in one package can be tedious.
>>
>> On the front, if I correctly understood this thread :
>> - a unique Msg / Model inside Main.elm can be a good starting point and 
>> easy to refactor later. 
>> - separating the view per feature (only view functions) : advice taken 
>> from Dave
>> - break Model / Msg when too big (definition of "too big" is perhaps not 
>> easy, or someone can give some advices to detect "a too big Msg"). At this 
>> point, break Msg / Model / Update by feature. It is not all or nothing, 
>> just extract at first one feature and put them inside a file. Then the Main 
>> module wraps the feature (using map inside the Update).
>>
>> Can we imagine starting a community guideline 

Re: [elm-discuss] Proposal: Add Debug.breakpoint to core

[Robin Heggelund Hansen]

I've done a lot of library work lately where Cmds and Subs haven't been a 
part of the project, so yes, in a project where the main way to run your 
code is through fuzz tests, breakpoints would be immensively helpful.

That being said, having a Debug.breakpoint function is just a convenience, 
not a necessity.

mandag 24. oktober 2016 19.34.53 UTC+2 skrev Nick H følgende:
>
> Don't forget, the time-travelling debug mode is coming in 0.18. Do you 
> think setting breakpoints like this is still going to be useful?
>
> On Mon, Oct 24, 2016 at 5:59 AM, Robin Heggelund Hansen <
> skinn...@gmail.com > wrote:
>
>> Elm, as great as it is, doesn't save you from debugging every once in a 
>> while. The one option we have now, is logging. Logging is great, but it can 
>> quickly become painful in loops. Since Elm compiles to a single JS file 
>> with long mangled names, setting a breakpoint from the code would sometimes 
>> be the simplest way to properly debug your code. The generated JS isn't 
>> that hard to understand either, it's a series of vars and function calls 
>> for the most part.
>>
>> lørdag 22. oktober 2016 13.49.52 UTC+2 skrev John Orford følgende:
>>>
>>> It never occurred to me to debug the generated JS... can you sketch out 
>>> your use case a bit more?
>>>
>>> On Sat, 22 Oct 2016 at 11:19 Robin Heggelund Hansen  
>>> wrote:
>>>
 While I spend a lot less time debugging in Elm than in JS, sometimes 
 it's useful to debug the generated Javascript.

 This would be greatly simplified, if it was possible to add a 
 `debugger;` statement to the code.

 What do people think of a new function added to the Debug module of 
 elm-lang/core, called breakpoint. It would work like the identity 
 function, 
 but also include the `debugger;` statement, causing a breakpoint to happen 
 when the browsers dev-tools are open.

 used like:

 ```
 faultyFunction a b =
   let
  _ = Debug.breakpoint ()
   in
 a + b
 ```

 Granted, this would cause a breakpoint to happen in the actual 
 Debug.breakpoint function, but since that function is very small, stepping 
 out of it is no big deal. The only other option I can think of is compiler 
 support, but I'm unsure how hard this would be to include.

 Opinions?

 -- 
 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] Proposal: Add Debug.breakpoint to core

[Nick H]

Don't forget, the time-travelling debug mode is coming in 0.18. Do you
think setting breakpoints like this is still going to be useful?

On Mon, Oct 24, 2016 at 5:59 AM, Robin Heggelund Hansen <
skinney...@gmail.com> wrote:

> Elm, as great as it is, doesn't save you from debugging every once in a
> while. The one option we have now, is logging. Logging is great, but it can
> quickly become painful in loops. Since Elm compiles to a single JS file
> with long mangled names, setting a breakpoint from the code would sometimes
> be the simplest way to properly debug your code. The generated JS isn't
> that hard to understand either, it's a series of vars and function calls
> for the most part.
>
> lørdag 22. oktober 2016 13.49.52 UTC+2 skrev John Orford følgende:
>>
>> It never occurred to me to debug the generated JS... can you sketch out
>> your use case a bit more?
>>
>> On Sat, 22 Oct 2016 at 11:19 Robin Heggelund Hansen 
>> wrote:
>>
>>> While I spend a lot less time debugging in Elm than in JS, sometimes
>>> it's useful to debug the generated Javascript.
>>>
>>> This would be greatly simplified, if it was possible to add a
>>> `debugger;` statement to the code.
>>>
>>> What do people think of a new function added to the Debug module of
>>> elm-lang/core, called breakpoint. It would work like the identity function,
>>> but also include the `debugger;` statement, causing a breakpoint to happen
>>> when the browsers dev-tools are open.
>>>
>>> used like:
>>>
>>> ```
>>> faultyFunction a b =
>>>   let
>>>  _ = Debug.breakpoint ()
>>>   in
>>> a + b
>>> ```
>>>
>>> Granted, this would cause a breakpoint to happen in the actual
>>> Debug.breakpoint function, but since that function is very small, stepping
>>> out of it is no big deal. The only other option I can think of is compiler
>>> support, but I'm unsure how hard this would be to include.
>>>
>>> Opinions?
>>>
>>> --
>>> 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] 2 yr. quest to learn front-end programming

[John Orford]

Doug,

I have been rereading the Evan's elm tutorial. Actually I don't think I
read it before, so it has been enjoyable.

I know Elm pretty OK, so my opinion about the tutorial is...

Elm is a bit like Mario Kart.

The basics are easy, and when you read the tutorial, you have covered a
good 90% of everything you need to know.

But those basics are also deep.

A week to learn and a life time to master.

Take your time, do every exercise in the tutorial, and you will be in great
shape.

Enjoy.

John

On Mon, 24 Oct 2016 at 18:50 Duane Johnson  wrote:

> These two might be helpful:
>
> https://www.gitbook.com/book/sporto/elm-tutorial/details
> https://johncrane.gitbooks.io/ninety-nine-elm-problems/content/
>
> On Mon, Oct 24, 2016 at 10:34 AM, douglas smith <395curra...@gmail.com>
> wrote:
>
> Hey everyone-
>
> Over the past 10 years I have causally studied various programming
> languages. For personal interest more than anything.   I have never written
> more then really basic code. I am 60 years old and over the next 2 years I
> am determined to learn enough about elm-lang to be employable as an
> entry-level coder.  It has been very enjoyable following Evans well written
> guide. I seem to be understanding and appreciating  the simplicity and
> power of functions. I think Evan and the whole elm-lang community is in an
> excellent position to bring powerful, flexible and "learn-able" tools to an
> otherwise very large and complicated JS ecosystem.  I am willing to bet
> that elm-lang skills will be in demand when I am ready. My question would
> be: What would be a good basis of knowledge -say in the first 4 to 6 months
> for me to get a grasp of?
>
>
> Thanks, Doug
>
> some homework:
> embedded elm counter in html
> https://dougie-.github.io/
>
> --
> 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] 2 yr. quest to learn front-end programming

[Duane Johnson]

These two might be helpful:

https://www.gitbook.com/book/sporto/elm-tutorial/details
https://johncrane.gitbooks.io/ninety-nine-elm-problems/content/

On Mon, Oct 24, 2016 at 10:34 AM, douglas smith <395curra...@gmail.com>
wrote:

> Hey everyone-
>
> Over the past 10 years I have causally studied various programming
> languages. For personal interest more than anything.   I have never written
> more then really basic code. I am 60 years old and over the next 2 years I
> am determined to learn enough about elm-lang to be employable as an
> entry-level coder.  It has been very enjoyable following Evans well written
> guide. I seem to be understanding and appreciating  the simplicity and
> power of functions. I think Evan and the whole elm-lang community is in an
> excellent position to bring powerful, flexible and "learn-able" tools to an
> otherwise very large and complicated JS ecosystem.  I am willing to bet
> that elm-lang skills will be in demand when I am ready. My question would
> be: What would be a good basis of knowledge -say in the first 4 to 6 months
> for me to get a grasp of?
>
>
> Thanks, Doug
>
> some homework:
> embedded elm counter in html
> https://dougie-.github.io/
>
> --
> 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: Metalinguistic abstractions over databases

[Peter Damoc]

What I'm looking here is more like a strategy that takes into account the
entire persistence layer from the perspective of an Elm Architecture app.

If one doesn't need to store data remotely, one could simply either use
just some transient model OR, use something like localstorage to persist
some small bits of data with an update on every relevant change to the
model.

But when one needs remote data, suddenly it comes the problem of how do you
approach solving the fact that there is state on the server and state on
your computer and there are performance considerations in retrieving the
entirety of the state.

I'm more interested in how one would solve this in a multilayer system
where the actual remote persistence is abstracted from the app.

The actual remote persistence might be implemented with REST, or it might
be some kind of websockets thing.
It might involve a SQL database, or maybe a NoSQL database.
It might be something like Datomic.

I'm interested in how would one implement this abstraction, this *separation
of concerns*.




On Mon, Oct 24, 2016 at 5:46 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Wednesday, October 19, 2016 at 9:54:44 AM UTC+1, Peter Damoc wrote:
>>
>> What options are there?
>>
>
> The option that probably has the most traction is Swagger (now the Open
> API Initiative) :
>
> https://openapis.org/
>
> In terms of what has been discussed here, graphql or PostgREST are more
> sophisticated than Swagger, but Swagger may have relevance if its following
> grows. That said, the news section in the open API initiaive is
> dissapointingly empty beyond the initial announcement of the initiative:
>
> https://openapis.org/news
>
> I would find a json-schema -> Elm decoders/encoders/records converter
> useful and the ability to generate the relevant Http boilerplate needed to
> call endpoints defined in Swagger. It would be nice if you could pick up a
> Swagger definition and create an Elm client module to work with that API
> with next to no effort.
>
> --
> 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.

[elm-discuss] Re: Naming functions

[Lars Jacobsson]

Ok Max, thanks I'll give it a go and see how it works out.

On Monday, October 24, 2016 at 4:13:33 PM UTC+2, Max Goldstein wrote:
>
> If you're going to refer to items by ID a lot, you should probably use a 
> dictionary keyed on ID. Assuming items is a record with an id field:
>
> { model |
> items = model.items |> Dict.insert updatedItem.id updatedItem }
>

-- 
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: Metalinguistic abstractions over databases

['Rupert Smith' via Elm Discuss]

On Thursday, October 20, 2016 at 7:19:05 PM UTC+1, John Kelly wrote:
>
> I'm sorry to link drop, but I've been doing a bit of work on a library to 
> remove some of the boilerplate when writing client code for a REST API. The 
> library is currently locked in / specific to what is called PostgREST, but 
> I imagine that the patterns could be applied to any REST backend. Check it 
> out: https://github.com/john-kelly/elm-postgrest/ 
> 
>  
>
> The core idea is to remove the boilerplate of always having to define 
> encoder, decoder and schema. Would love to chat.
>

Seems like a fairly nice idea - you provide functions like 'string', 'int' 
to construct the 'Fields' which are self contained in the sense that they 
provide the Decoder and the name of the field.

Mostly field names will match record fields, but sometimes they might not, 
so having an ability to name them differently to the name of the field in 
the Elm record could be useful.

I also quite like the little DSL you provide for field projection, 
filtering and sorting records. In some cases an API might already do that 
for you, but convenient to have this facility on the client side. I can see 
that coming in handy for fancy data tables for example.

-- 
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: Metalinguistic abstractions over databases

['Rupert Smith' via Elm Discuss]

On Thursday, October 20, 2016 at 7:19:05 PM UTC+1, John Kelly wrote:
>
> I'm sorry to link drop, but I've been doing a bit of work on a library to 
> remove some of the boilerplate when writing client code for a REST API. The 
> library is currently locked in / specific to what is called PostgREST, but 
> I imagine that the patterns could be applied to any REST backend. Check it 
> out: https://github.com/john-kelly/elm-postgrest/ 
>
> The core idea is to remove the boilerplate of always having to define 
> encoder, decoder and schema. Would love to chat.
>

What do you do with fields in the json that are missing or null? I can see 
for example that for an 'int' you just use Decode.int as the decoder, so I 
guess you will get a Result.Err and fail when the value is missing?

This is another awkward corner that needs to be dealt with. Until recently 
I ignored it, or used a default value like "". But of course "" just 
defeats the point, so I recently updated all my code to use Maybe fields, 
and Nothing for missing or null values. Of course, not all values can be 
missing or null, but for the ones that can be optional in input/output of 
the API it makes sense. After I went through all the code and updated it to 
deal gracefully with missing values it felt like the Elm compiler had 
forced me to much more thorough in accounting for all the possible 
interactions with the API.

-- 
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: Naming functions

[Max Goldstein]

If you're going to refer to items by ID a lot, you should probably use a 
dictionary keyed on ID. Assuming items is a record with an id field:

{ model |
items = model.items |> Dict.insert updatedItem.id updatedItem }

-- 
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: Naming functions

[Lars Jacobsson]

| The names were inspired by Dict.insert and Dict.update, which were the 
closest to what I was looking for.

Yeah, I'm probably just too used to that dot notation.


I don't know why but
items.replaceItemById id item
looks better than
replaceItemById items id item
. Somehow it feels like a standalone function named "replaceItemById" won't 
give us a list in return. But taking your idea to heart this would then be 
something like itemsUpdateById

-- 
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: Naming functions

[Wouter In t Velt]

Op maandag 24 oktober 2016 13:18:59 UTC+2 schreef Lars Jacobsson:
>
> Any thinking going out there on around naming conventions OOP vs 
> functional? I'd be grateful for any input on this matter of life or death!
>

I always try to keep my naming conventions close to the Core functions.
E.g. in my Elm app, I have functions similar to yours. They are called 
listUpdate and listInsert with the following signatures:

listUpdate : Int -> (RecordWithID a -> RecordWithID a) -> List (RecordWithID 
a) -> List (RecordWithID a)
listUpdate index updatefunction list =

listInsert : Int -> RecordWithID a -> List (RecordWithID a) -> List (
RecordWithID a)
listInsert index newRecord list =

type alias RecordWithID a = { a | id : Int }

The names were inspired by Dict.insert and Dict.update, which were the 
closest to what I was looking for.

-- 
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: Proposal: rename foldl til foldLeft and foldr to foldRight

[Robin Heggelund Hansen]

Define "other functional languages". Clojure(script) doesn't have fold, but 
reduce. F# has fold and foldBack.

What other languages do is, however, besides the point. The question is, 
what is more readable? It's easier to confuse foldl with foldr than it is 
to confuse fold(Left) with foldRight. This goes for both new and existing 
Elm developers.

mandag 24. oktober 2016 13.12.53 UTC+2 skrev Rupert Smith følgende:
>
> On Thursday, October 20, 2016 at 3:12:57 PM UTC+1, Robin Heggelund Hansen 
> wrote:
>>
>> In Elm 0.18, primes are being removed as valid characters in a 
>> variable/function name. The reason being, which I whole heartedly agree 
>> with, that removing primes will incentivize people to write proper names, 
>> and also because the difference between model and model' isn't always easy 
>> to spot.
>>
>> In the same spirit, I propose that we change the name of foldl to 
>> foldLeft, and the name of foldr to foldRight. The difference between foldl 
>> and foldr isn't to spot at a cursory glance. foldLeft is also more 
>> self-describing than foldl, it also matches what I say when I read foldl 
>> aloud while explaining code to others.
>>
>> FYI: Scala has also called their functions foldLeft and foldRight.
>>
>> I think this proposal would benefit both seasoned and new Elm developers.
>>
>
> -1 from me. foldl and foldr are so commonly in use in other functional 
> languages that they are an acceptable short hand. Who cares what Scala does.
>

-- 
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] Proposal: Add Debug.breakpoint to core

[Robin Heggelund Hansen]

Elm, as great as it is, doesn't save you from debugging every once in a 
while. The one option we have now, is logging. Logging is great, but it can 
quickly become painful in loops. Since Elm compiles to a single JS file 
with long mangled names, setting a breakpoint from the code would sometimes 
be the simplest way to properly debug your code. The generated JS isn't 
that hard to understand either, it's a series of vars and function calls 
for the most part.

lørdag 22. oktober 2016 13.49.52 UTC+2 skrev John Orford følgende:
>
> It never occurred to me to debug the generated JS... can you sketch out 
> your use case a bit more?
>
> On Sat, 22 Oct 2016 at 11:19 Robin Heggelund Hansen  > wrote:
>
>> While I spend a lot less time debugging in Elm than in JS, sometimes it's 
>> useful to debug the generated Javascript.
>>
>> This would be greatly simplified, if it was possible to add a `debugger;` 
>> statement to the code.
>>
>> What do people think of a new function added to the Debug module of 
>> elm-lang/core, called breakpoint. It would work like the identity function, 
>> but also include the `debugger;` statement, causing a breakpoint to happen 
>> when the browsers dev-tools are open.
>>
>> used like:
>>
>> ```
>> faultyFunction a b =
>>   let
>>  _ = Debug.breakpoint ()
>>   in
>> a + b
>> ```
>>
>> Granted, this would cause a breakpoint to happen in the actual 
>> Debug.breakpoint function, but since that function is very small, stepping 
>> out of it is no big deal. The only other option I can think of is compiler 
>> support, but I'm unsure how hard this would be to include.
>>
>> Opinions?
>>
>> -- 
>> 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] tictactoe game with elm (newbie)

[Peter Damoc]

You almost got it right. Here is your program with the view altered a
little bit (I've extracted the row display and the style of the cell)

import Html.App as App
import Html exposing (..)
import Html.Attributes exposing(..)

main =
App.program { init = init, update = update, view = view, subscriptions
= \_ -> Sub.none}

type alias Player =
  {
name: String
   ,shape: String
   ,score: Int
  }

type alias Model =
{
player1: Player
   ,player2: Player
}


type alias Box =
  {
id: Int
   ,shape: Maybe Player
  }

area: List (List Box)
area =
  [
[Box 1 Nothing, Box 2 Nothing, Box 3 Nothing]
   ,[Box 4 Nothing, Box 5 Nothing, Box 6 Nothing]
   ,[Box 7 Nothing, Box 8 Nothing, Box 9 Nothing]
  ]

init: (Model, Cmd Msg)
init =
(Model {name = "Player 1", shape = "X", score = 0 } {name = "Player 2",
shape = "O", score = 0}, Cmd.none)

type Msg = None

update: Msg -> Model -> (Model, Cmd Msg)
update msg model =
case msg of
None ->
(model, Cmd.none)

view: Model -> Html Msg
view model =
div []
[
  span[style [("font-weight", "bold")]][text model.player1.name]
 ,span[style [("text-decoration", "underline")]] [text
(toString(model.player1.score))]
 ,span[style [("margin-right", "15px")]][]
 ,span[style [("text-decoration", "underline")]] [text
(toString(model.player2.score))]
 ,span[style [("font-weight", "bold")]][text model.player2.name]
 ,div[]
 [
   area
   |> List.map viewRow
   |> div[style [("border", "1px solid black")]]
 ]
]



viewRow : List Box -> Html Msg
viewRow row =
  div []
  (List.map (\box -> div [id (toString box.id), style (boxStyle
box.shape)][]) row)


boxStyle shape =
  [ ("border", "1px solid black")
  , ("width", "64px")
  , ("height", "64px")
  , ("display", "inline-block")
  ]

On Mon, Oct 24, 2016 at 3:01 PM, Did  wrote:

> Hello there!
>
> As a newbie, and in order to learn elm, I started to write a tic tac toe
> game. I wanted to start by drawing the game area but I'm stuck with one
> thing. I decided that my area was a list of list of Box : List (List Box).
> A box is defined by an id and maybe a player (so that I can track if a box
> was filled by a player or not). With procedural languages, I can do
> something like this:
>
> for(var i = 0; i < 3; i++ {
> for (var j = 0; j < 3,; j++) {
> drawBox(area[i][j]);
> }
> }
>
> But I can't figure out how to do this in elm... It does not even compile,
> but that's because I don't fully understand List.map...
>
> Here is the code I started writing. If someone can help me, I would really
> appreciate!
>
> import Html.App as App
> import Html exposing (..)
> import Html.Attributes exposing(..)
>
> main =
> App.program { init = init, update = update, view = view, subscriptions
> = \_ -> Sub.none}
>
> type alias Player =
>   {
> name: String
>,shape: String
>,score: Int
>   }
>
> type alias Model =
> {
> player1: Player
>,player2: Player
> }
>
>
> type alias Box =
>   {
> id: Int
>,shape: Maybe Player
>   }
>
> area: List (List Box)
> area =
>   [
> [Box 1 Nothing, Box 2 Nothing, Box 3 Nothing]
>,[Box 4 Nothing, Box 5 Nothing, Box 6 Nothing]
>,[Box 7 Nothing, Box 8 Nothing, Box 9 Nothing]
>   ]
>
> init: (Model, Cmd Msg)
> init =
> (Model {name = "Player 1", shape = "X", score = 0 } {name = "Player
> 2", shape = "O", score = 0}, Cmd.none)
>
> type Msg = None
>
> update: Msg -> Model -> (Model, Cmd Msg)
> update msg model =
> case msg of
> None ->
> (model, Cmd.none)
>
> view: Model -> Html Msg
> view model =
> div []
> [
>   span[style [("font-weight", "bold")]][text model.player1.name]
>  ,span[style [("text-decoration", "underline")]] [text
> (toString(model.player1.score))]
>  ,span[style [("margin-right", "15px")]][]
>  ,span[style [("text-decoration", "underline")]] [text
> (toString(model.player2.score))]
>  ,span[style [("font-weight", "bold")]][text model.player2.name]
>  ,div[]
>  [
>area
>|> List.map
>|> List.map (\box -> span[id box.id, style [("border", "1px solid
> black")]][])
>|> div[style [("border", "1px solid black")]]
>  ]
> ]
>
> --
> 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: Proposal: rename foldl til foldLeft and foldr to foldRight

[Peter Damoc]

On Mon, Oct 24, 2016 at 2:12 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> -1 from me. foldl and foldr are so commonly in use in other functional
> languages that they are an acceptable short hand. Who cares what Scala does.
>
> The main target of Elm are developers who come from imperative languages
like javascript, python or ruby.
People with a background in FP might actually get a little bit frustrated
with Elm due to it deliberately leaving out certain facilities like
type-classes.

The thing is that if Elm convinces even a very small fraction of the JS
devs to move to FP, that would be a huge win for FP.

Considering this, it would actually make more sense to call foldl *reduce* and
remove foldr all together while providing that functionality via reversing
the list/array.

This could make things more familiar for JS/Python/Ruby while maybe
frustrating people coming from Haskell/OCaml/Erlang/Elixir.



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

[elm-discuss] tictactoe game with elm (newbie)

[Did]

Hello there!

As a newbie, and in order to learn elm, I started to write a tic tac toe 
game. I wanted to start by drawing the game area but I'm stuck with one 
thing. I decided that my area was a list of list of Box : List (List Box). 
A box is defined by an id and maybe a player (so that I can track if a box 
was filled by a player or not). With procedural languages, I can do 
something like this:

for(var i = 0; i < 3; i++ {
for (var j = 0; j < 3,; j++) {
drawBox(area[i][j]);
}
}

But I can't figure out how to do this in elm... It does not even compile, 
but that's because I don't fully understand List.map... 

Here is the code I started writing. If someone can help me, I would really 
appreciate!

import Html.App as App
import Html exposing (..)
import Html.Attributes exposing(..)

main =
App.program { init = init, update = update, view = view, subscriptions 
= \_ -> Sub.none}

type alias Player =
  {
name: String
   ,shape: String
   ,score: Int
  }

type alias Model = 
{
player1: Player
   ,player2: Player
}

 
type alias Box = 
  {
id: Int
   ,shape: Maybe Player
  }

area: List (List Box)
area = 
  [
[Box 1 Nothing, Box 2 Nothing, Box 3 Nothing]
   ,[Box 4 Nothing, Box 5 Nothing, Box 6 Nothing]
   ,[Box 7 Nothing, Box 8 Nothing, Box 9 Nothing]
  ]

init: (Model, Cmd Msg)
init =
(Model {name = "Player 1", shape = "X", score = 0 } {name = "Player 2", 
shape = "O", score = 0}, Cmd.none)

type Msg = None

update: Msg -> Model -> (Model, Cmd Msg)
update msg model =
case msg of
None ->
(model, Cmd.none)

view: Model -> Html Msg
view model =
div []
[
  span[style [("font-weight", "bold")]][text model.player1.name]
 ,span[style [("text-decoration", "underline")]] [text 
(toString(model.player1.score))]
 ,span[style [("margin-right", "15px")]][]
 ,span[style [("text-decoration", "underline")]] [text 
(toString(model.player2.score))]
 ,span[style [("font-weight", "bold")]][text model.player2.name]
 ,div[]
 [
   area
   |> List.map
   |> List.map (\box -> span[id box.id, style [("border", "1px solid 
black")]][])
   |> div[style [("border", "1px solid black")]]
 ]
]

-- 
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] Structure for large Elm apps

[Oliver Searle-Barnes]

@Mark this is a pattern I've been exploring recently. An area that I 
haven't found a solution to is keeping the view model in sync with the 
shared models. For instance, let's say I have a view with a list of 
checkboxes next to each user. The state for the checkboxes would be kept in 
the view model, but then I need to manage adding/removing checkboxes as the 
list of users changes. Currently I handle this by having a default state 
for the checkbox which is used until a user actually clicks on a checkbox 
at which point the state is added to the view model. This works but is 
semantically awkward and doesn't take care of removing the checkbox state 
if a user is removed from the shared list. 
https://github.com/elm-lang/html/issues/19 provides a potential avenue for 
cleanup, but even then the lifecycle seems a little awkward. 

I wonder if you have a different approach for this problem?


On Sunday, 23 October 2016 21:29:23 UTC+2, Mark Hamburg wrote:
>
> We're just getting into having an app where this is likely to matter, but 
> if you have multiple views onto the same data, then the pattern that would 
> seem to apply is to have a single data model and multiple view models. The 
> data model handles the shared part. The view models handle things specific 
> to the particular view — e.g., is a spin down open, what's the scroll 
> position, etc. The view functions would take the data model and their 
> particular view model as parameters and would generate appropriately tagged 
> messages back. This avoids significant nesting while still providing some 
> structure to keep pieces that can be separated separate.
>
> There are then a couple ways to structure the multiple view models. One is 
> to have a view selector but keep all of the view models alive all the time. 
> The benefit of this is that when you switch back to a view, it will 
> remember where you were. The downside is that one is carrying around — and 
> potentially updating if the view model depends on the data model — an 
> increasing number of view models if you have an increasing number of views. 
> The alternative is to put the view models into a union type and have one 
> model entry that serves as both view selector and view model storage. This 
> keeps things lighter weight but means that you have nowhere to maintain 
> context when switching back and forth.
>
> Above all of this, the other key subdivision we are making in our SPA and 
> that I would recommend having seen where other programmers often first 
> head, is having a top layer that handles overall app state — e.g., logged 
> in v not logged in — as a type union. This can also often be where the 
> routing logic plugs in. People who haven't spent a lot of time thinking in 
> terms of type unions tend to load their model up with a lot of fields that 
> only have meaning in certain states. This then leads to more invariants 
> about the state that can't be enforced by the compiler. Breaking things up 
> into different type cases for different states allows one to make more bad 
> states simply impossible. For example, our logging in state has a 
> RemoteData.WebData User reflecting whether we've gotten valid user data 
> back from the server but our logged in state simply has a User. The top 
> level event dispatcher works with the following type signature on the log 
> in state update:
>
> update : Login.Msg -> Login.Model -> ( Login.Model, Cmd Login.Msg, Maybe 
> User )
>
>
> After each call to update, it can check to see whether we now have a valid 
> user and if so switch to the logged in state, initializing it with the 
> supplied user.
>
> This isn't as flat as some people go, but it doesn't spread things out 
> into lots of components and the top layer(s) are pretty simple.
>
> Mark
>
>
> On Sun, Oct 23, 2016 at 11:39 AM, Francois  > wrote:
>
>> Hi,
>>
>> I'm really new to Elm. I'm not good enough to propose a guideline about 
>> Elm app structure but as a novice a guideline can help lots of people.
>>
>> I worked / works on a large angular application and John Papa Styleguide 
>> has been really helpful at the beginning.
>> So writing a community guideline can be a great resource. (there is 
>> another thread inter component that seems related)
>>
>> For example, on the server side, structuring domain core by features is 
>> good thing (for me). Help define some boundaries and help maintability. 
>> Grouping all Java classes by technical aspect at the project root : all 
>> services in one package, all models in one package can be tedious.
>>
>> On the front, if I correctly understood this thread :
>> - a unique Msg / Model inside Main.elm can be a good starting point and 
>> easy to refactor later. 
>> - separating the view per feature (only view functions) : advice taken 
>> from Dave
>> - break Model / Msg when too big (definition of "too big" is perhaps not 
>> easy, or someone can give some advices to detect "a too big Msg"). At this 

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

['Rupert Smith' via Elm Discuss]

On Monday, October 24, 2016 at 1:17:30 AM UTC+1, John Kelly wrote:
>
> I'm coming to the sad realization that an api like this is simply not 
> possible:
>
> ```
> session =
> resource "sessions"
> { id = int "id"
> , speaker_id = int "speaker_id"
> , start_time = string "start_time"
> , end_time = string "end_time"
> , location = string "location"
> , session_type = int "session_type"
> , speaker = hasOne (\_ -> speaker)
> }
>
>
> speaker =
> resource "speakers"
> { id = int "id"
> , name = string "name"
> , sessions = hasMany (\_ -> session)
> }
> ```
>
> Any ideas? I was under the impression that the lambda would fix the 
> recursive type issue, but now i see that elm still has trouble with the 
> type of the record. 
>

Yes, I also ran into this issue with mutual recursion. I simply followed 
the advice here and created wrapper types for all my records:

https://github.com/elm-lang/elm-compiler/blob/master/hints/recursive-alias.md 

type Session = Session { ... }
type Speaker = Speaker { ... }

Its a bit of a PITA, since you end up having to wrap and unwrap records all 
the time. Defining an unwrap function can help things along:

unwrapSpeaker (Speaker speaker) = speaker

-- 
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] Naming functions

[Lars Jacobsson]

Hey you guys! I've started to build out my first real Elm app and I'm 
loving it. On my model there is a field called items

 Model
...
items : List Item
...

which is a list of the type Item. Coming from a rails mindset I created an 
"updateItemById" -function, which I use like this in my update
 case msg of
   ...
   OnSubmit updatedItem ->
   { model | items = updateItemById updatedItem }
but then it dawned on me that this does not read very well in this context. 
We'll be getting back a list of items, while "updateItem" implies that we 
are working with a single item. A CORRECT name for the function would be 
something like getNewItemsListWithReplacedItemById which works, but is not 
very elegant. Of course I could make it a little shorter, but you get the 
idea.

Any thinking going out there on around naming conventions OOP vs 
functional? I'd be grateful for any input on this matter of life or death!

-- 
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: Proposal: rename foldl til foldLeft and foldr to foldRight

['Rupert Smith' via Elm Discuss]

On Thursday, October 20, 2016 at 3:12:57 PM UTC+1, Robin Heggelund Hansen 
wrote:
>
> In Elm 0.18, primes are being removed as valid characters in a 
> variable/function name. The reason being, which I whole heartedly agree 
> with, that removing primes will incentivize people to write proper names, 
> and also because the difference between model and model' isn't always easy 
> to spot.
>
> In the same spirit, I propose that we change the name of foldl to 
> foldLeft, and the name of foldr to foldRight. The difference between foldl 
> and foldr isn't to spot at a cursory glance. foldLeft is also more 
> self-describing than foldl, it also matches what I say when I read foldl 
> aloud while explaining code to others.
>
> FYI: Scala has also called their functions foldLeft and foldRight.
>
> I think this proposal would benefit both seasoned and new Elm developers.
>

-1 from me. foldl and foldr are so commonly in use in other functional 
languages that they are an acceptable short hand. Who cares what Scala does.

-- 
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 GUI component library

[António Ramos]

If you prefer js and keep the ELM architecture in your code you can try
 Choo framework

https://github.com/yoshuawuyts/choo



2016-10-24 9:14 GMT+01:00 Witold Szczerba :

> I love Elm. The problem with it is that's a niche. It is now and, sadly,
> it will be :(
> Last time I used it for my pet project I was looking for tree components,
> so I could draw files and directories.
> The problem is, in Elm you are left alone.
>
> For JS there are many libraries, not only showing the foldable tree,
> skinnable to mimic many OSes, but also auto downloading data from server.
> Integration seems to be few lines of code.
>
> There always will be 100x more JS libs than Elm ones. We should think how
> to make them live together easily in Elm apps, not the other way around.
>
> Regards,
> Witold Szczerba
>
> 11.10.2016 11:17 PM "Casper Bollen"  napisał(a):
>
>> I would love to use ELM as my client side language. However, a show
>> stopper at the moment is the lack of a decent ELM GUI component library.
>>
>> Currently I am using webix  an extremely simple to
>> use library to create a complex one page application. I think it would be a
>> great boost to the ELM usage if a library like that would be natively
>> available. I also, tried to lure
>>  the webix
>> developers into looking at ELM.
>>
>> If you, from ELM were to cooperate in implementing a sort of 'ELM webix'
>> with the webix developers, this could be a very interesting project. I
>> personally don't have the time and the skill to do this.
>>
>> Just fishing here;-)
>>
>> P.s. To get a gist of the kind of application I am working on see:
>> http://github.com/halcwb/GenPDMS.git. Look at the latest commits in the
>> client folder.
>>
>> --
>> 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] Elm GUI component library

[Witold Szczerba]

I love Elm. The problem with it is that's a niche. It is now and, sadly, it
will be :(
Last time I used it for my pet project I was looking for tree components,
so I could draw files and directories.
The problem is, in Elm you are left alone.

For JS there are many libraries, not only showing the foldable tree,
skinnable to mimic many OSes, but also auto downloading data from server.
Integration seems to be few lines of code.

There always will be 100x more JS libs than Elm ones. We should think how
to make them live together easily in Elm apps, not the other way around.

Regards,
Witold Szczerba

11.10.2016 11:17 PM "Casper Bollen"  napisał(a):

> I would love to use ELM as my client side language. However, a show
> stopper at the moment is the lack of a decent ELM GUI component library.
>
> Currently I am using webix  an extremely simple to use
> library to create a complex one page application. I think it would be a
> great boost to the ELM usage if a library like that would be natively
> available. I also, tried to lure
>  the webix
> developers into looking at ELM.
>
> If you, from ELM were to cooperate in implementing a sort of 'ELM webix'
> with the webix developers, this could be a very interesting project. I
> personally don't have the time and the skill to do this.
>
> Just fishing here;-)
>
> P.s. To get a gist of the kind of application I am working on see:
> http://github.com/halcwb/GenPDMS.git. Look at the latest commits in the
> client folder.
>
> --
> 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.