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

[Fergus Meiklejohn]

I think understanding CCS and HTML are pretty essential to applying Elm to 
practical projects in the browser.  But that's just saying, "if we want to 
make things in the browser we need to know CSS"; it doesn't really have 
much to do with Elm the language.  Similarly, Javascript is very useful for 
making Elm apps actually work because we Port out of Elm and write a little 
JS and  then can interact with other services, but we don't need to even 
want to learn JS in order to learn Elm.  

For learning Elm the language, I would watch Aaron VonderHaar's, { @avh4 on 
twitter }, fantastic Elm Live coding sessions.  They are full of brilliant 
insights.
I'd also recommend the Haskell Book: http://haskellbook.com  Honestly: it's 
a brilliant book, assumes no prior knowledge and it explains tons of stuff 
that Elm uses.

On Monday, 24 October 2016 05:22:22 UTC+8, 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.

[elm-discuss] Re: zip function in the standard library

[janderson]

I agree with Luis and Gulshan. Having a "zip" function without a 
corresponding "unzip" reduces the readability and intuitive discoverability 
of the language.

This is my Python sensibilities talking, I know. Python also haze "zip" and 
I thought it also had "unzip". But when I tried it, I realized that "unzip" 
is not in the Python standard library. And I've been using Python for many 
years now!

I realized that the Python equivalent of "unzip" is the List Comprehension. 
Here's a really bad example (in Python):

>>> a = []
>>> b = []
>>> c = []
>>> [(a.append(x), b.append(y), c.append(z)) for (x, y, z) in [(1,2,3), 
(4,5,6)]]
[(None, None, None), (None, None, None)]
>>> a
[1, 4]
>>> b
[2, 5]
>>> c
[3, 6]


I'm very new to Elm, so I don't yet know if there's something analogous to 
List Comprehension.

In any case, this helped me see that "unzip" is non-trivial in any 
language. I can understand it being left out of a standard library. 
(Though, if Elm solved this, I would cheer. :)

-- 
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: Is there any way to use a type instead of a string for the value of an option

[Ian Mackenzie]

I've been slowly working on a small library 
 to make working with the basic 
input widgets like  more pleasant to work with - I'd be interested 
to see what you think. The implementation 

 handles 
the mapping between selected index and strongly-typed values; check out 
examples/ComboBox.elm 
 to 
see a simple usage example.

On Tuesday, 25 October 2016 23:45:26 UTC+11, James Hamilton wrote:
>
> Hello!
>
> I suppose this really only applies to instances of , but there may 
> be other examples. 
>
> When using  with , it's necessary to set a value on the 
>  using  which accepts a String. However, I usually actually 
> want to refer to a Type which I have to represent as a String and marshal 
> it back to its correct type when updating the model. 
>
> Is there a way of doing this using a type, and if not could it be done? I 
> think it's a reasonable thing to expect to be able to do with an , 
> but then again I'm pretty new to this so please tell me if I'm asking for 
> something complicated!
>
>

-- 
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: Function equality again

[Mark Hamburg]

Okay. I'm shutting up here and just tacking this onto
https://github.com/elm-lang/elm-compiler/issues/1145.

On Tue, Oct 25, 2016 at 4:15 PM, Mark Hamburg  wrote:

> Here is a very simple failure case that shows that comparing tasks isn't
> necessarily safe (though it does succeed if I create two success tasks):
>
> import Html exposing (..)
>
> import Http
>
> task1 = Http.getString "http://somewhere;
>
> task2 = Http.getString "http://somewhere;
>
> main = text <| if task1 == task2 then "Match" else "No match"
>
>
> What in this was supposed to clue me in that it might throw a runtime
> exception other than the use of ==?
>
> Mark
>
> On Tue, Oct 25, 2016 at 3:18 PM, Mark Hamburg 
> wrote:
>
>> I just thought of another example where the ability to test function
>> equality matters:
>>
>> Picking up on a discussion on elm-dev regarding the new HTTP rate
>> limiting logic, I thought about moving my case away from using rate limit
>> and instead just creating the model code to manage buffering HTTP requests.
>> This is pretty easy to do with the new Http.Request. (It would also have
>> been straightforward with tasks but might have felt a bit less natural.)
>> But to handle things correctly, I need to test Http.Request for equality.
>> Is that safe to do or does it incorporate a function somewhere — e.g., in a
>> decoder — and hence does comparing it for equality risk a runtime
>> exception? How would I know without looking inside the implementation of
>> Http.Request and potentially everything it references?
>>
>> Mark
>>
>> (*) The specific use case I'm thinking about is a variation of
>> RemoteData.WebData to support setting the desired request as a way to drive
>> it. Thinking about it further, tasks might be even better since they exist
>> at a lower level but similar concerns over equality testing generating
>> runtime exceptions would apply.
>
>
>

-- 
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: Function equality again

[Mark Hamburg]

Here is a very simple failure case that shows that comparing tasks isn't
necessarily safe (though it does succeed if I create two success tasks):

import Html exposing (..)

import Http

task1 = Http.getString "http://somewhere;

task2 = Http.getString "http://somewhere;

main = text <| if task1 == task2 then "Match" else "No match"


What in this was supposed to clue me in that it might throw a runtime
exception other than the use of ==?

Mark

On Tue, Oct 25, 2016 at 3:18 PM, Mark Hamburg  wrote:

> I just thought of another example where the ability to test function
> equality matters:
>
> Picking up on a discussion on elm-dev regarding the new HTTP rate limiting
> logic, I thought about moving my case away from using rate limit and
> instead just creating the model code to manage buffering HTTP requests.
> This is pretty easy to do with the new Http.Request. (It would also have
> been straightforward with tasks but might have felt a bit less natural.)
> But to handle things correctly, I need to test Http.Request for equality.
> Is that safe to do or does it incorporate a function somewhere — e.g., in a
> decoder — and hence does comparing it for equality risk a runtime
> exception? How would I know without looking inside the implementation of
> Http.Request and potentially everything it references?
>
> Mark
>
> (*) The specific use case I'm thinking about is a variation of
> RemoteData.WebData to support setting the desired request as a way to drive
> it. Thinking about it further, tasks might be even better since they exist
> at a lower level but similar concerns over equality testing generating
> runtime exceptions would apply.

-- 
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] Function equality again

[Mark Hamburg]

I just thought of another example where the ability to test function equality 
matters:

Picking up on a discussion on elm-dev regarding the new HTTP rate limiting 
logic, I thought about moving my case away from using rate limit and instead 
just creating the model code to manage buffering HTTP requests. This is pretty 
easy to do with the new Http.Request. (It would also have been straightforward 
with tasks but might have felt a bit less natural.) But to handle things 
correctly, I need to test Http.Request for equality. Is that safe to do or does 
it incorporate a function somewhere — e.g., in a decoder — and hence does 
comparing it for equality risk a runtime exception? How would I know without 
looking inside the implementation of Http.Request and potentially everything it 
references?

Mark

(*) The specific use case I'm thinking about is a variation of 
RemoteData.WebData to support setting the desired request as a way to drive it. 
Thinking about it further, tasks might be even better since they exist at a 
lower level but similar concerns over equality testing generating runtime 
exceptions would apply.

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

On Tue, Oct 25, 2016 at 11:12 PM, Did  wrote:

> Now is the hardest part for me : the update function. Since elm is a
> functional language, I suppose I have to recreate a new cells list with the
> value of the box concerned by the click. In OOP languages, I'd just take
> the reference of the box from the list, change the player and that's it...
> Here is the update function with some not working changes...
>
> CELLS_WITH_BOX_UPDATED would be the new cells list updated but I don't
> understand how to do this...
>

 `cells` is a list of lists.
updated cells would mean that you would have to update all the list in the
main list, in other words, update every row

let
currentBox = List.map (filterRow boxId) model.cells
updateRow row = List.map (\box -> if boxId == box.id then {box | shape
= Just model.current } else box) row
in
case currentBox of
Nothing ->
{ model | cells = List.map updateRow model.cells, current
= changePlayer
model.current }
Just _ ->
model  -- nothing changes (cannot click over a previous ticked
cell)



-- 
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] tictactoe game with elm (newbie)

[Did]

Ok so now I have moved my area (which I renamed cells) into the model :

type alias Model = 
{
player1: Player
   ,player2: Player
   ,current: Player
   ,boxClicked: Maybe Int
   ,cells: List (List Box)
}

I initialize the cells like this :

cells: List (List Box)
cells = 
  [
[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 player1 player2 player1 Nothing cells, Cmd.none)

The boxStyle function is now like this (the background image url is taken 
from a website I found quickly on the internet for my shapes to display. 
Thanks jimdscott by the way!) :

boxStyle player =
  case player of
Nothing -> 
  [
  ("border", "1px solid black")
 ,("width", "64px")
 ,("height", "64px")
 ,("display", "inline-block")
  ]
Just p ->
  [
  ("border", "1px solid black")
 ,("width", "64px")
 ,("height", "64px")
 ,("display", "inline-block")
 ,("background-image", 
"http://jimdscott.com/static/images/tic-tac-toe-; ++ p.shape ++ ".png")
  ]

Now is the hardest part for me : the update function. Since elm is a 
functional language, I suppose I have to recreate a new cells list with the 
value of the box concerned by the click. In OOP languages, I'd just take 
the reference of the box from the list, change the player and that's it... 
 Here is the update function with some not working changes...

CELLS_WITH_BOX_UPDATED would be the new cells list updated but I don't 
understand how to do this...

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

ClickBox boxId ->
let
  currentBox = List.map (filterRow boxId) model.cells
  -- not working : currentBox.player = model.current
  currentPlayer = changePlayer model.current
in
(Model model.player1 model.player2 currentPlayer (Just boxId) 
CELLS_WITH_BOX_UPDATED, Cmd.none)

Le mardi 25 octobre 2016 14:16:00 UTC+2, Peter Damoc a écrit :
>
> On Tue, Oct 25, 2016 at 2:57 PM, Did  
> wrote:
>
>> Thanks Peter for your help! I could go further but now, there's another 
>> issue. I would like to display the current player's shape when he clicks on 
>> a cell. The thing is I don't know how to interact with the DOM in this 
>> case. I know how to define an onClick event on each cell (displayed as a 
>> div), but I don't know how to interact with a cell to display a shape in 
>> its div).
>>
>
> You're making great progress. 
> Now, it should be obvious that you need to change/update the  "area" on 
> clicks to reflect the current state of the game. 
>
> move the area into the model and on each click check to see if it is a 
> valid click and if it is a valid click, change the value of the box and 
> switch to the other player. 
>
> the view should also be changed to handle the move of the area into the 
> model and you should change the rendering of the box to take into 
> consideration the shape. ;) 
> I've already started that work in the previous code when I parameterized 
> the boxStyle but that's only one of the ways to handle it (style the div 
> with a background image). 
> another way to approach it is to add the image (or a plain piece of text) 
> as a child of the box div. 
>
>
> -- 
> 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] Proposal: rename foldl til foldLeft and foldr to foldRight

[Juan Soto]

I'm an observer (not an Elm programmer) but these discussions are 
interesting to me. I guess the question Elm programmers have to ask 
themselves is what Elm's purpose is? Haskell/traditional Functional ML 
language in the browser? PureScript fits that mold already, but if so the 
recent changes and this one go against that. A functional ML language aimed 
at the general population? Then I agree with the changes for readability, 
though to be honest `foldr` and `foldRight` are pretty close so I'd opts 
for an alias until 1.0.0.

On Tuesday, October 25, 2016 at 12:18:00 PM UTC-4, Robin Heggelund Hansen 
wrote:
>
> Once, that I remember, after a refactoring. But this is more to do with 
> the ease of reading code. I've several times seen foldr and read foldl. In 
> general, I find names that differ by only a single letter a bad thing. Like 
> wether and whether. Sure, now that i've pointed out that there is a 
> difference here, it's easy enough to point it out. But given the proper 
> context it can be easy to confuse one with the other, especially when the 
> compiler (or the spell checker) don't point it out for you.
>
> tirsdag 25. oktober 2016 17.36.02 UTC+2 skrev Rupert Smith følgende:
>>
>> On Tuesday, October 25, 2016 at 1:45:35 PM UTC+1, James Hamilton wrote:
>>>
>>> I agree with your sentiment in principle. I suppose the underlying 
 question is whether or not this is actually going to be such a benefit to 
 future users of elm that it would be worth inconveniencing current users 
 who want to upgrade. Personally I'm quite comfortable with foldr and foldl 
 but I understand the foldLeft and foldRight are more expressive. 

>>>
>>> I used to use ember and its constant churn drove me to find an 
>>> alternative which led me to elm. Not that the community elm behaves 
>>> anything like ember in this regard, but still this blog post 
>>> 
>>>  rather 
>>> sums up the danger of making a lot of inconvenient changes for apparently 
>>> abstract reasons. 
>>>
>>
>> Also, have you ever actually encountered a bug which was caused by 
>> misreading foldl for foldr or the other way around? I really don't find it 
>> hard to tell them apart. 
>>
>

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

[Robin Heggelund Hansen]

Once, that I remember, after a refactoring. But this is more to do with the 
ease of reading code. I've several times seen foldr and read foldl. In 
general, I find names that differ by only a single letter a bad thing. Like 
wether and whether. Sure, now that i've pointed out that there is a 
difference here, it's easy enough to point it out. But given the proper 
context it can be easy to confuse one with the other, especially when the 
compiler (or the spell checker) don't point it out for you.

tirsdag 25. oktober 2016 17.36.02 UTC+2 skrev Rupert Smith følgende:
>
> On Tuesday, October 25, 2016 at 1:45:35 PM UTC+1, James Hamilton wrote:
>>
>> I agree with your sentiment in principle. I suppose the underlying 
>>> question is whether or not this is actually going to be such a benefit to 
>>> future users of elm that it would be worth inconveniencing current users 
>>> who want to upgrade. Personally I'm quite comfortable with foldr and foldl 
>>> but I understand the foldLeft and foldRight are more expressive. 
>>>
>>
>> I used to use ember and its constant churn drove me to find an 
>> alternative which led me to elm. Not that the community elm behaves 
>> anything like ember in this regard, but still this blog post 
>> 
>>  rather 
>> sums up the danger of making a lot of inconvenient changes for apparently 
>> abstract reasons. 
>>
>
> Also, have you ever actually encountered a bug which was caused by 
> misreading foldl for foldr or the other way around? I really don't find it 
> hard to tell them apart. 
>

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

['Rupert Smith' via Elm Discuss]

On Tuesday, October 25, 2016 at 1:45:35 PM UTC+1, James Hamilton wrote:
>
> I agree with your sentiment in principle. I suppose the underlying 
>> question is whether or not this is actually going to be such a benefit to 
>> future users of elm that it would be worth inconveniencing current users 
>> who want to upgrade. Personally I'm quite comfortable with foldr and foldl 
>> but I understand the foldLeft and foldRight are more expressive. 
>>
>
> I used to use ember and its constant churn drove me to find an alternative 
> which led me to elm. Not that the community elm behaves anything like ember 
> in this regard, but still this blog post 
> 
>  rather 
> sums up the danger of making a lot of inconvenient changes for apparently 
> abstract reasons. 
>

Also, have you ever actually encountered a bug which was caused by 
misreading foldl for foldr or the other way around? I really don't find it 
hard to tell them apart. 

-- 
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: D3 4.0 or D3-shape

[Jakub Hampl]

I'm the author of the aforementioned library. Arc generators happen to be next 
on my roadmap, which you can see on 
https://github.com/gampleman/elm-visualization/projects/1. I've marked things 
that should be reasonably easy contributions there as well :)

-- 
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: Is there any way to use a type instead of a string for the value of an option

[OvermindDL1]

`option` is supposed to match to the html , thus only strings, any 
marshalling you will need to perform yourself, such as by, for example, 
wrapping up option into something like `optionMyType t = option [ value 
(myTypeSerialize t) ]` or so for ease of use.  :-)


On Tuesday, October 25, 2016 at 6:45:26 AM UTC-6, James Hamilton wrote:
>
> Hello!
>
> I suppose this really only applies to instances of , but there may 
> be other examples. 
>
> When using  with , it's necessary to set a value on the 
>  using  which accepts a String. However, I usually actually 
> want to refer to a Type which I have to represent as a String and marshal 
> it back to its correct type when updating the model. 
>
> Is there a way of doing this using a type, and if not could it be done? I 
> think it's a reasonable thing to expect to be able to do with an , 
> but then again I'm pretty new to this so please tell me if I'm asking for 
> something complicated!
>
>

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

[Kasey Speakman]

So to phrase what I previously said a different way, a database is the 
wrong level of abstraction to be shooting for. A database is just one 
integration that most business systems have.

The system itself exposes use cases and queries. Whether and which 
databases are involved (and their structural details, I contend) should be 
of no concern to client apps. The client apps exist to help the user 
fulfill the system's use cases, not just to connect to a database.

On Tuesday, October 25, 2016 at 6:02:45 AM UTC-5, Rupert Smith wrote:
>
> On Tuesday, October 25, 2016 at 10:01:48 AM UTC+1, Peter Damoc wrote:
>>
>> On Tue, Oct 25, 2016 at 11:27 AM, 'Rupert Smith' via Elm Discuss <
>> elm-d...@googlegroups.com> wrote:
>>
>>> If your 'persistence API' requires the application to behave correctly 
>>> in order to not store invalid or maliciously altered data, you cannot 
>>> guarantee that. 
>>>
>>
>> This actually sounds more like a challenge to be faced rather that a 
>> technical impossibility. 
>> Maybe some kind of declarative access control embedded in a shared schema 
>> could solve this. 
>>
>
> Declaring what the access rights are to the client UI is useful, yes - it 
> is just that they still need to be enforced by the server because you 
> cannot fully trust the client to take care of it. This is actually what I 
> am doing (in some cases), because when a user logs in they get back a JWT 
> token. This token contains some information about who the user is, and what 
> permissions they have. The UI can use this to only render screens and 
> functionality that the user is allowed to use. This is merely to be helpful 
> and provide a nice user experience, the permissions are always checked 
> whenever a restricted API endpoint is invoked.
>
> I don't always use the JWT tokens as bearer tokens in an HTTP 
> Authorization header field, or as a secure cookie because they can grow 
> quite large. However, I generally do provide an endpoint in my API where 
> the JWT token can be requested in order to inspect the users declared 
> access rights.
>  
>
>>  I do think that these server side responsibilities are not really within 
>>> the domain of Elm.
>>
>>
>> Look at what happened with Javascript. Once it got useful in the client 
>> people wanted it on the server and then we got Node. 
>> We are nowhere near the popularity of javascript and yet, I already see 
>> frequent enough questions about using Elm on the server-side. 
>>
>> There are two ways to address this: 
>> 1. allocating resources to making Elm viable on the server
>> 2. making the server part as small and automatic as possible as to not 
>> require much coding. 
>>
>> To me, option 2 is much more attractive. 
>>
>
> Ok, I think I now get a better idea of what you are after.  As per John 
> Kellys PostgREST code: https://github.com/john-kelly/elm-postgrest. Have 
> a way of defining a data model in Elm, and use that description to 
> automatically generate a suitable server to persist it.
>
> In this case defining the access rights in the Elm code would be ok, as 
> the server that you generate would also securely check them at runtime.
>

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

[Robin Heggelund Hansen]

I did a lot of work in ember myself, and I feel your pain, but this is 
still a 0.x product, and so it should be expected that some breakage is 
performed while we reach the best possible state of the language. It's 
different for Ember, which had a lot of breakage post 1.0.

tirsdag 25. oktober 2016 14.45.35 UTC+2 skrev James Hamilton følgende:
>
> I agree with your sentiment in principle. I suppose the underlying 
>> question is whether or not this is actually going to be such a benefit to 
>> future users of elm that it would be worth inconveniencing current users 
>> who want to upgrade. Personally I'm quite comfortable with foldr and foldl 
>> but I understand the foldLeft and foldRight are more expressive. 
>>
>
> I used to use ember and its constant churn drove me to find an alternative 
> which led me to elm. Not that the community elm behaves anything like ember 
> in this regard, but still this blog post 
> 
>  rather 
> sums up the danger of making a lot of inconvenient changes for apparently 
> abstract reasons. 
>

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

Thanx to you guys, I'm so close to what I wanted to do.

I have summed up my findings 
here: http://stackoverflow.com/q/40240254/592641
Hop on if you have an idea!

Carlos, sorry, i'm not sure what are you doing inside ESLint : ) please 
elaborate your discoveries.

-- 
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 any way to use a type instead of a string for the value of an option

[James Hamilton]

Hello!

I suppose this really only applies to instances of , but there may 
be other examples. 

When using  with , it's necessary to set a value on the 
 using  which accepts a String. However, I usually actually 
want to refer to a Type which I have to represent as a String and marshal 
it back to its correct type when updating the model. 

Is there a way of doing this using a type, and if not could it be done? I 
think it's a reasonable thing to expect to be able to do with an , 
but then again I'm pretty new to this so please tell me if I'm asking for 
something complicated!

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

[James Hamilton]

>
> I agree with your sentiment in principle. I suppose the underlying 
> question is whether or not this is actually going to be such a benefit to 
> future users of elm that it would be worth inconveniencing current users 
> who want to upgrade. Personally I'm quite comfortable with foldr and foldl 
> but I understand the foldLeft and foldRight are more expressive. 
>

I used to use ember and its constant churn drove me to find an alternative 
which led me to elm. Not that the community elm behaves anything like ember 
in this regard, but still this blog post 

 rather 
sums up the danger of making a lot of inconvenient changes for apparently 
abstract reasons. 

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

On Tue, Oct 25, 2016 at 2:57 PM, Did  wrote:

> Thanks Peter for your help! I could go further but now, there's another
> issue. I would like to display the current player's shape when he clicks on
> a cell. The thing is I don't know how to interact with the DOM in this
> case. I know how to define an onClick event on each cell (displayed as a
> div), but I don't know how to interact with a cell to display a shape in
> its div).
>

You're making great progress.
Now, it should be obvious that you need to change/update the  "area" on
clicks to reflect the current state of the game.

move the area into the model and on each click check to see if it is a
valid click and if it is a valid click, change the value of the box and
switch to the other player.

the view should also be changed to handle the move of the area into the
model and you should change the rendering of the box to take into
consideration the shape. ;)
I've already started that work in the previous code when I parameterized
the boxStyle but that's only one of the ways to handle it (style the div
with a background image).
another way to approach it is to add the image (or a plain piece of text)
as a child of the box div.


-- 
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] tictactoe game with elm (newbie)

[Did]

Thanks Peter for your help! I could go further but now, there's another 
issue. I would like to display the current player's shape when he clicks on 
a cell. The thing is I don't know how to interact with the DOM in this 
case. I know how to define an onClick event on each cell (displayed as a 
div), but I don't know how to interact with a cell to display a shape in 
its div).

Here's my code. Hope you can help me!

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

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

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

type alias Model = 
{
player1: Player
   ,player2: Player
   ,current: Player
   ,boxClicked: Maybe Int
}

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

player1: Player
player1 =
  {id = 1, name = "Player 1", shape = "X", score = 0 }
  
player2: Player
player2 =
  {id = 2, name = "Player 2", shape = "O", score = 0}

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 player1 player2 player1 Nothing, Cmd.none)

type Msg = None | ClickBox Int

changePlayer: Player -> Player
changePlayer player =
  case player.id of
1 ->
  player2
_ ->
  player1


filterRow: Int -> List Box -> Maybe Box
filterRow boxId row =
  row
  |> List.filter (\box -> box.id == boxId)
  |> List.head

renderClickedBox: Maybe Int -> String
renderClickedBox boxId =
  case boxId of
Nothing -> "No box clicked yet"
Just b -> "Box " ++ (toString b) ++ " clicked"

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

ClickBox boxId ->
let
  currentBox = area
 |> List.map (filterRow boxId)
 
  currentPlayer = changePlayer model.current
in
(Model model.player1 model.player2 currentPlayer (Just boxId), 
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 model)
   |> div[]
 ]
,div[][text (renderClickedBox model.boxClicked)]
,div[][text model.current.name]
]

viewRow: Model -> List Box -> Html Msg
viewRow model row =
  row
  |> List.map (\box -> div [id (toString box.id), style (boxStyle 
box.player), onClick (ClickBox box.id)][])
  |> div[]
  
boxStyle shape =
  [
("border", "1px solid black")
   ,("width", "64px")
   ,("height", "64px")
   ,("display", "inline-block")
  ]

Le lundi 24 octobre 2016 14:36:48 UTC+2, Peter Damoc a écrit :
>
> 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")]]
>  ]
> ]
> 
> 
> 

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

['Andrew Radford' via Elm Discuss]

As people pointed out - it's a BDFL call, but it feels to me that this is 
the closest candidate to the spirit of the recent 'Let's go mainstream' 
BDFL calls. 
(Assuming that foldRight is sufficiently less commonly used so as to not 
make the ample suffix 'Right' burdensome, and the lack of suffix for fold 
reasonable)

On Tuesday, 25 October 2016 10:48:30 UTC+1, Robin Heggelund Hansen wrote:
>
> fold and foldRight then?
>
>
>

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

['Rupert Smith' via Elm Discuss]

On Tuesday, October 25, 2016 at 10:01:48 AM UTC+1, Peter Damoc wrote:
>
> On Tue, Oct 25, 2016 at 11:27 AM, 'Rupert Smith' via Elm Discuss <
> elm-d...@googlegroups.com > wrote:
>
>> If your 'persistence API' requires the application to behave correctly in 
>> order to not store invalid or maliciously altered data, you cannot 
>> guarantee that. 
>>
>
> This actually sounds more like a challenge to be faced rather that a 
> technical impossibility. 
> Maybe some kind of declarative access control embedded in a shared schema 
> could solve this. 
>

Declaring what the access rights are to the client UI is useful, yes - it 
is just that they still need to be enforced by the server because you 
cannot fully trust the client to take care of it. This is actually what I 
am doing (in some cases), because when a user logs in they get back a JWT 
token. This token contains some information about who the user is, and what 
permissions they have. The UI can use this to only render screens and 
functionality that the user is allowed to use. This is merely to be helpful 
and provide a nice user experience, the permissions are always checked 
whenever a restricted API endpoint is invoked.

I don't always use the JWT tokens as bearer tokens in an HTTP Authorization 
header field, or as a secure cookie because they can grow quite large. 
However, I generally do provide an endpoint in my API where the JWT token 
can be requested in order to inspect the users declared access rights.
 

>  I do think that these server side responsibilities are not really within 
>> the domain of Elm.
>
>
> Look at what happened with Javascript. Once it got useful in the client 
> people wanted it on the server and then we got Node. 
> We are nowhere near the popularity of javascript and yet, I already see 
> frequent enough questions about using Elm on the server-side. 
>
> There are two ways to address this: 
> 1. allocating resources to making Elm viable on the server
> 2. making the server part as small and automatic as possible as to not 
> require much coding. 
>
> To me, option 2 is much more attractive. 
>

Ok, I think I now get a better idea of what you are after.  As per John 
Kellys PostgREST code: https://github.com/john-kelly/elm-postgrest. Have a 
way of defining a data model in Elm, and use that description to 
automatically generate a suitable server to persist it.

In this case defining the access rights in the Elm code would be ok, as the 
server that you generate would also securely check them at runtime.

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

[Robin Heggelund Hansen]

fold and foldRight then?

tirsdag 25. oktober 2016 11.42.00 UTC+2 skrev Wouter In t Velt følgende:
>
> Op dinsdag 25 oktober 2016 02:20:29 UTC+2 schreef Max Goldstein:
>>
>> Changing things makes upgrading harder, invalidates old code, and gives 
>> the larger community the impression that Elm is not stable.
>>
>
> The question is whether different naming for "foldl" and "foldr" would 
> bring enough benefits to be worth all these (temporary) drawbacks.
> So:
>
>- "foldLeft" and "foldRight" are easier to keep apart/ more readable - 
>regardless of someone's previous language
>- "reduce" and ("foldr" or nothing or something else) would be more 
>familiar to people coming from JS (and possibly other languages too)
>
> My own background is JS, so "reduce" is familiar. 
> But at the same time, I use "foldl" way more often in Elm than I ever used 
> "reduce" in JS, and in very different ways.
>
> What I see as a structural drawback to "foldLeft" and "foldRight" is the 
> length of the function names: shorter names are better, and (for me at 
> least) the extra characters in the function names do not give me any 
> relevant info or benefits.
> 90% of the time I use any fold, my output is the same in both directions. 
> (like .sum or .maximum etcetera). 
> I have never used "foldr" (yet).
>

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

[Wouter In t Velt]

Op dinsdag 25 oktober 2016 02:20:29 UTC+2 schreef Max Goldstein:
>
> Changing things makes upgrading harder, invalidates old code, and gives 
> the larger community the impression that Elm is not stable.
>

The question is whether different naming for "foldl" and "foldr" would 
bring enough benefits to be worth all these (temporary) drawbacks.
So:

   - "foldLeft" and "foldRight" are easier to keep apart/ more readable - 
   regardless of someone's previous language
   - "reduce" and ("foldr" or nothing or something else) would be more 
   familiar to people coming from JS (and possibly other languages too)

My own background is JS, so "reduce" is familiar. 
But at the same time, I use "foldl" way more often in Elm than I ever used 
"reduce" in JS, and in very different ways.

What I see as a structural drawback to "foldLeft" and "foldRight" is the 
length of the function names: shorter names are better, and (for me at 
least) the extra characters in the function names do not give me any 
relevant info or benefits.
90% of the time I use any fold, my output is the same in both directions. 
(like .sum or .maximum etcetera). 
I have never used "foldr" (yet).

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

On Tue, Oct 25, 2016 at 11:27 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> If your 'persistence API' requires the application to behave correctly in
> order to not store invalid or maliciously altered data, you cannot
> guarantee that.
>

This actually sounds more like a challenge to be faced rather that a
technical impossibility.
Maybe some kind of declarative access control embedded in a shared schema
could solve this.

 I do think that these server side responsibilities are not really within
> the domain of Elm.


Look at what happened with Javascript. Once it got useful in the client
people wanted it on the server and then we got Node.
We are nowhere near the popularity of javascript and yet, I already see
frequent enough questions about using Elm on the server-side.

There are two ways to address this:
1. allocating resources to making Elm viable on the server
2. making the server part as small and automatic as possible as to not
require much coding.

To me, option 2 is much more attractive.



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

['Rupert Smith' via Elm Discuss]

On Tuesday, October 25, 2016 at 9:27:58 AM UTC+1, Rupert Smith wrote:
>
> On Tuesday, October 25, 2016 at 8:08:11 AM UTC+1, Peter Damoc wrote:
>>
>> Browsers can provide a trusted environment through the use of https. This 
>> is what Gmail and Facebook and all other webapps are doing. 
>>
>
> What I mean is, there is nothing to stop whoever is running your 
> application from subverting it.
>

There are ways that untrusted code can be made to work to update shared 
state accross many actors whilst ensuring the integrity of the data - 
blockchain databases.

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

['Rupert Smith' via Elm Discuss]

On Tuesday, October 25, 2016 at 8:08:11 AM UTC+1, Peter Damoc wrote:
>
> Why not just freeze dry your entire application state to some key/value 
>> store (on every update), then you have a simple way to rehydrate the whole 
>> application after a period of inactivity?
>>
>
> This is not an option on large datasets. I gave the example with the Music 
> database in an earlier message specifically to address this. 
> Pagination is a very real concern that seldom appears in toy examples.
>

Its not an option on shared data. Going with your MusicBrainz example, 
there is a shared data set. You could write an application that lets users 
read and write that data. I would think that such an application would only 
ever hold a small amount of the data at any one time, so serializing the 
application state is not the same thing as saving the whole MusicBrainz 
database. Also, this technique only saves the state for one user, there is 
no mechanism for integrating the changes made by several users into a 
single database.

Here is an example where it would be relevant: a single player game. I 
might periodically dump the game state (perhaps not the entire Elm model, 
but enough to be able to continue playing from last position). Each users 
game state is their own, and I don't really care if they cheat, for example 
by using curl on the command line to poke at the persistence API, perhaps 
changing game level from 11 to 12 say.

This is another very good reason that persistence is typically the concern 
of a server - globally, over the whole application state over all users, 
updates are being made concurrently. It is usually the responsibility of 
the server side to coordinate this concurrent state machine, in order to 
ensure it does not enter illegal states. The server is ideally positioned 
to take on this responsibility, being the hub in a hub and spokes model of 
your application. That said, a server centric model is not the only one 
possible.

Client side storage, such as sessionStorage and localStorage and Web SQL 
database are relevant to Elm. I do think that these server side 
responsibilities are not really within the domain of Elm.

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

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

['Rupert Smith' via Elm Discuss]

On Tuesday, October 25, 2016 at 8:08:11 AM UTC+1, Peter Damoc wrote:
>
> Browsers can provide a trusted environment through the use of https. This 
> is what Gmail and Facebook and all other webapps are doing. 
>

What I mean is, there is nothing to stop whoever is running your 
application from subverting it. In the browser, there are even a lot of 
things you can do with the javascript console. If your 'persistence API' 
requires the application to behave correctly in order to not store invalid 
or maliciously altered data, you cannot guarantee that. This is one very 
good reason why business logic is typically implemented on the server 
behind an API that only provides the specific operations that a user is 
allowed to perform, whether they perform them through your application or 
otherwise.

You can use secure cookies with HTTPS. There is nothing to stop someone 
using a hacked version of the browser that lets them get the secure cookie 
in order to make malicious calls to your 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.

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

[Peter Damoc]

On Tue, Oct 25, 2016 at 3:20 AM, Max Goldstein 
wrote:

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


Old code is already invalid for other reasons and getting to a highly
polished 1.0 justifies the trouble that we, the innovators have to go
through.
Also, changes like these are mechanical and some kind of tooling could make
it very easy to upgrade a large codebase.

*reduce* has a lot of notoriety built into it due to MapReduce.

People frequently equate familiarity with good. :)



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

[Peter Damoc]

On Tue, Oct 25, 2016 at 2:06 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> I think the model that has the lowest 'cognitive overload' for a beginner
> is to simply work with the request/response model of HTTP, and to request
> data when needed, and POST data when you want to update something. Its a
> pretty obvious abstraction and fits nicely with Elms event handling.
>

You are right if by "beginner" you understand someone new to Elm. This
might not be true for someone who is using Elm to start learning to
program.


> I would say that persistence is not really the concern of the UI. It is
> nice to experiment with clever technologies that let the UI code build
> whatever query it needs, or update whatever data it needs but you have to
> remember that most of the time your UI is not runnning in a trusted
> environment - in the case of Elm/javascript its running in someones
> browsers. Therefore it is almost a necessity that you create an API and
> think carefully about what data can be seen through it, and what data
> updated by whom. That said, Overmind has provided some clear details of how
> access rights to data are protected when using graphql. Not sure if
> PostgREST provides any assistance with access rights?
>

Browsers can provide a trusted environment through the use of https. This
is what Gmail and Facebook and all other webapps are doing.
Also, you are right, persistence is not the concern of UI but Elm is not
exclusively about the UI.
What I dream to have available is more like full stack in the browser.
Something more like what  Abadi Kurniawaan demoed at elm-conf.
This is doable with the current technologies and would be a killer feature
if Elm could do it right.



> Coming back to the 'cognitive overload'... I have found that simply
> setting up and working with the HTTP requests in Elm is a lot of work - you
> need encoders, decoders, functions to help build the requests, functions to
> help decode the responses and deal with errors, msgs to pass to update
> functions to update your model based on responses and so on. There is a lot
> of boilerplate in simply working with an API, although this has nothing to
> do with databases and persistence as such.
>

I have had a similar experience and this is what motivated this topic.
It is not that I mind the boilerplate all that much, it's that *I lose
cognitive resources by not having an official/semi-official way to do it*.
I keep asking myself if I took the right approach when I should be focusing
on implementing some other feature.


Why not just freeze dry your entire application state to some key/value
> store (on every update), then you have a simple way to rehydrate the whole
> application after a period of inactivity?
>

This is not an option on large datasets. I gave the example with the Music
database in an earlier message specifically to address this.
Pagination is a very real concern that seldom appears in toy examples.




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