[elm-discuss] Select box works different in Firefox vs Chrome

[Zachary Kessin]

I have this code  that generates the lines of an option box. When I run it
in firefox it works correctly and the event gets sent. But when I run it in
chrome nothing happens. Obviously this is kind of an issue. how can I fix
this?

Zach


  option[
  onClick <| event menuItem.latitude menuItem.longitude
 ][text menuItem.name]


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

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

[elm-discuss] How to implement that if I want to add a function to record the score?

[cassiedqs]

User can get score if he helps the bird avoid the attack of the walls 
successfully. How to implement that?

import Color exposing (..)
import Graphics.Collage exposing (..)
import Graphics.Element exposing (..)
import Keyboard
import Text
import Time exposing (..)
import Window

-- SIGNALS

bird = { x=0, y=0, vx=0, vy=0 }

-- moves the walls only
physics t (b, w1, w2, w1x, w2x) = if w1x < w2x then
   ({ b | y = b.y + t*b.vy , x = b.x + t*b.vx }, 
   w1 |> move (5,0),
   w2 |> move (-5,0),
   w1x + 5,
   w2x - 5
   )   
   else if (b.x < w1x || b.x > w2x )then
   (b, w2, w1,  -gameWidth/2 + 100,  gameWidth/2 - 
100)
   else
   (b, w1, w2, w1x, w2x)


-- moves the bird only
walk {x,y} (b, w1, w2, w1x, w2x) = ({ b | vx = toFloat x, vy = toFloat y }, 
w1, w2, w1x,  w2x)

step (dt, keys) =
  walk keys >> physics dt

(gameWidth,gameHeight) = (500,500)


wall1 = toForm (collage gameWidth gameHeight
  [   rect 100 100 |> filled (rgb 250 230 0) |> move (50-gameWidth/2, 
gameHeight/2-50)
  ,rect 80 100  |> filled (rgb 250 230 0) |> move (40-gameWidth/2, 
gameHeight/2-150)
  , rect 50 100  |> filled (rgb 250 230 0) |> move (25-gameWidth/2, 
gameHeight/2-250)
  , rect 100 100 |> filled (rgb 250 230 0) |> move (50-gameWidth/2, 
gameHeight/2-350)
  , rect 80 100  |> filled (rgb 250 230 0) |> move (40-gameWidth/2, 
gameHeight/2-450)
  
  ])
  
wall2 = toForm (collage gameWidth gameHeight
 [ rect 100 100 |> filled (rgb 250 230 0) |> move (gameWidth/2-50, 
gameHeight/2-50)
  , rect 120 100  |> filled (rgb 250 230 0) |> move (gameWidth/2-60, 
gameHeight/2-150)
  , rect 50 100  |> filled (rgb 250 230 0) |> move (gameWidth/2-25, 
gameHeight/2-250)
  , rect 100 100 |> filled (rgb 250 230 0) |> move (gameWidth/2-50, 
gameHeight/2-350)
  , rect 120 100  |> filled (rgb 250 230 0) |> move (gameWidth/2-60, 
gameHeight/2-450)]) 


render (w',h') (bird, wall1, wall2, w1x, w2x) =
  let (w,h) = (toFloat w', toFloat h')
  src = "bee.PNG" 
  in collage w' h'

  [ rect gameWidth gameHeight |> filled (rgb 174 238 238)
  , toForm (image 50 50 src) |> move (bird.x, bird.y)
  , wall1
  , wall2
  -- text (Text.fromString (toString (w1x, w2x)))
  ]  


-- bird
input = let delta = Signal.map (\t -> t/10) (fps 10)
in  Signal.sampleOn delta (Signal.map2 (,) delta Keyboard.arrows)

main = Signal.map2 render Window.dimensions (Signal.foldp step (bird, 
wall1, wall2, -gameWidth/2 + 100, gameWidth/2 - 100) input)

-- 
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 Game about Attack

[cassiedqs]

Like this?
physics t (b, w1, w2, w1x, w2x) = if w1x < w2x then
   ({ b | y = b.y + t*b.vy , x = b.x + t*b.vx }, 
   w1 |> move (5,0),
   w2 |> move (-5,0),
   w1x + 5,
   w2x - 5
   )   
   else if (bird.x < w1x || bird.x > w2x )then
   (b, w1, w2)
   else
   (b, w1, w2, w1x, w2x)

在 2016年6月21日星期二 UTC+8下午12:09:03，Nick H写道：
>
> You will need to add another if-else condition to your physics function, 
> where you compare b.x with w1x and w2x.
>
> On Mon, Jun 20, 2016 at 8:47 PM,  wrote:
>
>> Below is my whole code. The wall is moving. I wonder know how to 
>> determine whether the bird touch the two walls. The bird will die if it 
>> touch the walls when the walls stop moving. 
>>
>>
>>
>>
>> import Color exposing (..)
>> import Graphics.Collage exposing (..)
>> import Graphics.Element exposing (..)
>> import Keyboard
>> import Text
>> import Time exposing (..)
>> import Window
>>
>> -- SIGNALS
>>
>> bird = { x=0, y=0, vx=0, vy=0 }
>>
>> -- moves the walls only
>> physics t (b, w1, w2, w1x, w2x) = if w1x < w2x then
>>({ b | y = b.y + t*b.vy , x = b.x + t*b.vx }, 
>>w1 |> move (5,0),
>>w2 |> move (-5,0),
>>w1x + 5,
>>w2x - 5
>>)   
>>else 
>>(b, w1, w2, w1x, w2x)
>>
>> -- moves the bird only
>> walk {x,y} (b, w1, w2, w1x, w2x) = ({ b | vx = toFloat x, vy = toFloat y 
>> }, w1, w2, w1x,  w2x)
>>
>> step (dt, keys) =
>>   walk keys >> physics dt
>>
>> (gameWidth,gameHeight) = (500,500)
>>
>>
>> wall1 = toForm (collage gameWidth gameHeight
>>   [   rect 100 100 |> filled (rgb 250 230 0) |> move (50-gameWidth/2, 
>> gameHeight/2-50)
>>   ,rect 80 100  |> filled (rgb 250 230 0) |> move (40-gameWidth/2, 
>> gameHeight/2-150)
>>   , rect 50 100  |> filled (rgb 250 230 0) |> move (25-gameWidth/2, 
>> gameHeight/2-250)
>>   , rect 100 100 |> filled (rgb 250 230 0) |> move (50-gameWidth/2, 
>> gameHeight/2-350)
>>   , rect 80 100  |> filled (rgb 250 230 0) |> move (40-gameWidth/2, 
>> gameHeight/2-450)
>>   
>>   ])
>>   
>> wall2 = toForm (collage gameWidth gameHeight
>>  [ rect 100 100 |> filled (rgb 250 230 0) |> move (gameWidth/2-50, 
>> gameHeight/2-50)
>>   , rect 120 100  |> filled (rgb 250 230 0) |> move (gameWidth/2-60, 
>> gameHeight/2-150)
>>   , rect 50 100  |> filled (rgb 250 230 0) |> move (gameWidth/2-25, 
>> gameHeight/2-250)
>>   , rect 100 100 |> filled (rgb 250 230 0) |> move (gameWidth/2-50, 
>> gameHeight/2-350)
>>   , rect 120 100  |> filled (rgb 250 230 0) |> move (gameWidth/2-60, 
>> gameHeight/2-450)]) 
>>
>>
>> render (w',h') (bird, wall1, wall2, w1x, w2x) =
>>   let (w,h) = (toFloat w', toFloat h')
>>   src = "bee.PNG" 
>>   in collage w' h'
>>
>>   [ rect gameWidth gameHeight |> filled (rgb 174 238 238)
>>   , toForm (image 50 50 src) |> move (bird.x, bird.y)
>>   , wall1
>>   , wall2
>>   -- text (Text.fromString (toString (w1x, w2x)))
>>   ]  
>>
>>
>> -- bird
>> input = let delta = Signal.map (\t -> t/10) (fps 10)
>> in  Signal.sampleOn delta (Signal.map2 (,) delta Keyboard.arrows)
>>
>> main = Signal.map2 render Window.dimensions (Signal.foldp step (bird, 
>> wall1, wall2, -gameWidth/2 + 100, gameWidth/2 - 100) input)
>>
>> -- 
>> 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] Elm Game about Attack

[cassiedqs]

Oh, get it, thank you!

在 2016年6月21日星期二 UTC+8下午12:09:03，Nick H写道：
>
> You will need to add another if-else condition to your physics function, 
> where you compare b.x with w1x and w2x.
>
> On Mon, Jun 20, 2016 at 8:47 PM,  wrote:
>
>> Below is my whole code. The wall is moving. I wonder know how to 
>> determine whether the bird touch the two walls. The bird will die if it 
>> touch the walls when the walls stop moving. 
>>
>>
>>
>>
>> import Color exposing (..)
>> import Graphics.Collage exposing (..)
>> import Graphics.Element exposing (..)
>> import Keyboard
>> import Text
>> import Time exposing (..)
>> import Window
>>
>> -- SIGNALS
>>
>> bird = { x=0, y=0, vx=0, vy=0 }
>>
>> -- moves the walls only
>> physics t (b, w1, w2, w1x, w2x) = if w1x < w2x then
>>({ b | y = b.y + t*b.vy , x = b.x + t*b.vx }, 
>>w1 |> move (5,0),
>>w2 |> move (-5,0),
>>w1x + 5,
>>w2x - 5
>>)   
>>else 
>>(b, w1, w2, w1x, w2x)
>>
>> -- moves the bird only
>> walk {x,y} (b, w1, w2, w1x, w2x) = ({ b | vx = toFloat x, vy = toFloat y 
>> }, w1, w2, w1x,  w2x)
>>
>> step (dt, keys) =
>>   walk keys >> physics dt
>>
>> (gameWidth,gameHeight) = (500,500)
>>
>>
>> wall1 = toForm (collage gameWidth gameHeight
>>   [   rect 100 100 |> filled (rgb 250 230 0) |> move (50-gameWidth/2, 
>> gameHeight/2-50)
>>   ,rect 80 100  |> filled (rgb 250 230 0) |> move (40-gameWidth/2, 
>> gameHeight/2-150)
>>   , rect 50 100  |> filled (rgb 250 230 0) |> move (25-gameWidth/2, 
>> gameHeight/2-250)
>>   , rect 100 100 |> filled (rgb 250 230 0) |> move (50-gameWidth/2, 
>> gameHeight/2-350)
>>   , rect 80 100  |> filled (rgb 250 230 0) |> move (40-gameWidth/2, 
>> gameHeight/2-450)
>>   
>>   ])
>>   
>> wall2 = toForm (collage gameWidth gameHeight
>>  [ rect 100 100 |> filled (rgb 250 230 0) |> move (gameWidth/2-50, 
>> gameHeight/2-50)
>>   , rect 120 100  |> filled (rgb 250 230 0) |> move (gameWidth/2-60, 
>> gameHeight/2-150)
>>   , rect 50 100  |> filled (rgb 250 230 0) |> move (gameWidth/2-25, 
>> gameHeight/2-250)
>>   , rect 100 100 |> filled (rgb 250 230 0) |> move (gameWidth/2-50, 
>> gameHeight/2-350)
>>   , rect 120 100  |> filled (rgb 250 230 0) |> move (gameWidth/2-60, 
>> gameHeight/2-450)]) 
>>
>>
>> render (w',h') (bird, wall1, wall2, w1x, w2x) =
>>   let (w,h) = (toFloat w', toFloat h')
>>   src = "bee.PNG" 
>>   in collage w' h'
>>
>>   [ rect gameWidth gameHeight |> filled (rgb 174 238 238)
>>   , toForm (image 50 50 src) |> move (bird.x, bird.y)
>>   , wall1
>>   , wall2
>>   -- text (Text.fromString (toString (w1x, w2x)))
>>   ]  
>>
>>
>> -- bird
>> input = let delta = Signal.map (\t -> t/10) (fps 10)
>> in  Signal.sampleOn delta (Signal.map2 (,) delta Keyboard.arrows)
>>
>> main = Signal.map2 render Window.dimensions (Signal.foldp step (bird, 
>> wall1, wall2, -gameWidth/2 + 100, gameWidth/2 - 100) input)
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [elm-discuss] Re: Is there a reason Date has no setters?

[Wouter In t Velt]

For something similar to your need, I have actually created my own SimpleDate 
type ( year, month, day, weekday) without time.
Born out of frustration after endless mapping of Result types. 

The very first SimpleDate created from a String is a Result (using 
.fromString). But after that, helper functions allow you to create new 
SimpleDates by passing in a valid SimpleDate and an offset in days, or go to 
first of week, month, year etc etc.
I used it for building a simple date picker.
If anyone is interested, I can add some basic documentation and try sharing on 
GitHub.

But off course I would welcome similar extended date methods in the core 
(preferably returning valid dates, not Results BTW).

-- 
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] Appropriate infix synonym for Maybe.map and Maybe.withDefault

[William Casarin]

Hey Tim,

On Mon, Jun 20, 2016 at 3:08 PM, Tim Stewart  wrote:
> I'm interested in what others think about this specific use of infix.

The issue with infix operators is they add a few extra thing you have
to worry about:

  * precedence, aka. order of operations
  * it's easy to screw up what's getting applied to what without lots
of explicit parens sometimes
  * It can make code harder to parse for humans when overused. This is
the number complaint I got from co-workers reading my code with lots
of operators.
  * can be sometimes difficult to compose with other functions (like
the pipeline example)

As for this particular operator, I had a similar operator in my
Haskell codebase. Over time I abandoned it for the reasons above.

Cheers,
William

---
https://jb55.com

-- 
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] Learning Elm and feeling alone in the world

[Wouter In t Velt]

Great discussion! I am looking forward to seeing progress on the Learn You an 
Elm.

Having learned quite a few languages in my days, I actually find it quite 
refreshing to dive into a new and promising language as Elm.
With many other languages (Java anyone?) it was a nightmare to find a suitable 
(and not outdated) starting point among gazillions of options, tutorials, 
courses, libraries, frameworks etc.

Yes Elm has gaps to be filled, tutorials and guides still in development, and 
libraries to mature. And for many questions the answer is not yet out there or 
hard to find, especially for the infix stuff (try Googling what "::"  means).

And I find the community very supportive (evidence in this threat).
The docs on elm-Lang.org got me a long way, and I hope I can continue to steer 
clear of docs from other languages like Haskell (haven't read LYaH).

-- 
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] Appropriate infix synonym for Maybe.map and Maybe.withDefault

[Nick H]

The question mark infix used to be in the core library. It was removed for
exactly the reasons described in the Design Guidelines. (I predict the
exclamation point will meet the same fate.)

I personally have not found this infix useful because I am usually using
Maybe.withDefault as part of a pipeline of operations. For example:

operation
|> anotherOperation
|> Maybe.withDefault "default"
|> letsDoSomethingElse



On Mon, Jun 20, 2016 at 3:08 PM, Tim Stewart 
wrote:

> I just saw an example which used ? infix operator as a shorthand for
> Maybe.withDefault:
>
> user.title ? ""
>
> Looking into it further I note that this is provided as the example of how
> infix operators are defined in the Elm syntax guide:
>
> http://elm-lang.org/docs/syntax#infix-operators
>
> This seems like a great shorthand, very readable, reminiscent of related
> concepts in other languages (null check operator in Groovy, optional types
> in Swift).
>
> But then I read here and in the Design Guidelines that this is
> discouraged, not idiomatic and just plain dumb.
>
> http://package.elm-lang.org/help/design-guidelines#avoid-infix-operators
>
> I'm interested in what others think about this specific use of infix.
>
>
> On Monday, March 14, 2016 at 8:42:23 AM UTC+11, Max Goldstein wrote:
>>
>> Oh, I make the same error, really wish it was flatmap. But, I think
>> andThen works better for things that aren't obviously data structures, like
>> tasks and random value generation. The nice thing about not having type
>> classes is that you don't have to make crazy compromises that work in all
>> cases. For example, sometimes "singleton" is better, sometimes "constant"
>> is better, and I personally will take the inconsistency over something
>> uselessly vague like "return".
>>
> --
> 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] Appropriate infix synonym for Maybe.map and Maybe.withDefault

[Tim Stewart]

I just saw an example which used ? infix operator as a shorthand for 
Maybe.withDefault:

user.title ? ""

Looking into it further I note that this is provided as the example of how 
infix operators are defined in the Elm syntax guide:

http://elm-lang.org/docs/syntax#infix-operators

This seems like a great shorthand, very readable, reminiscent of related 
concepts in other languages (null check operator in Groovy, optional types 
in Swift).

But then I read here and in the Design Guidelines that this is discouraged, 
not idiomatic and just plain dumb.

http://package.elm-lang.org/help/design-guidelines#avoid-infix-operators

I'm interested in what others think about this specific use of infix. 
 

On Monday, March 14, 2016 at 8:42:23 AM UTC+11, Max Goldstein wrote:
>
> Oh, I make the same error, really wish it was flatmap. But, I think 
> andThen works better for things that aren't obviously data structures, like 
> tasks and random value generation. The nice thing about not having type 
> classes is that you don't have to make crazy compromises that work in all 
> cases. For example, sometimes "singleton" is better, sometimes "constant" 
> is better, and I personally will take the inconsistency over something 
> uselessly vague like "return".
>

-- 
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: String Interpolation Proposal

[Tim Stewart]

This proposal would be a great language enhancement making for improved 
code readability in a very common use case, and the proposed syntax seems 
ideal. 

On Friday, April 3, 2015 at 5:23:16 PM UTC+11, Richard Feldman wrote:
>
> I created a String Interpolation Proposal issue 
>  on the compiler 
> GitHub repo, and as Evan pointed out, it's probably overdue to be posted to 
> this list!
>

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

Re: [elm-discuss] Learning Elm and feeling alone in the world

[Joey Eremondi]

I started learn you an Elm, and it's far from ready for reccomending to
anyone. Learning Haskell is definitely not the ideal way to learn Elm.
On Jun 20, 2016 12:13 PM, "Håkon Rossebø"  wrote:

> After I've started learning Elm, I agree that the documentation for "basic
> functional programming" could be improved. "Learn You a Haskell" is a great
> resource  and I'm surprised that "Learn You an Elm" has not been mentioned
> here yet - http://learnyouanelm.github.io/. The first chapters from
> "Learn You a Haskell" has already been adapted. I hope the community can
> contribute more to this project -
> https://github.com/learnyouanelm/learnyouanelm.github.io
>
>
> fredag 13. november 2015 20.26.36 UTC+1 skrev Joey Eremondi følgende:
>>
>> It's worth noting that LYAH is licensed under Creative Commons, so it's
>> potentially possible that we could make a copy of it and adapt it for Elm,
>> while keeping most of the great material (and humour). As long as it was
>> not for profit, and we gave credit to the original, it is allowed.
>>
>> On Fri, Nov 13, 2015 at 10:08 AM, Jason Zoladz 
>> wrote:
>>
>>>
>>> "Learn You a Haskell" isn't "Haskell documentation."  (That's a straw
>>> man, and you know it.)  It's a book about how to *think* in a certain
>>> paradigm.  And a lot of that paradigm translates to Elm.
>>>
>>> When someone finds a task or concept hard, it's usually because they
>>> don't fully understand the fundamentals.  Someone struggling with Elm
>>> likely isn't having difficulty with the syntax.  (Evan has done a great job
>>> of setting it out succinctly.)  If you're struggling with Elm, and/or if
>>> Elm is your first language, you probably need to work through the
>>> "Structure and Interpretation of Computer Programs."  It *is* a
>>> *beginner's* book.  And there are tons of online courses that teach
>>> programming through it.
>>>
>>> So, yes, I think we should sometimes point people to sources outside of
>>> Elm if only because translating the greatest-hits-of-computation-books into
>>> Elm is a bit wasteful.
>>>
>>> As for your assertion that directing folks to Haskell guarantees
>>> failure, I think you underestimate your students.  Students -- heck, people
>>> generally for that matter -- don't need to coddled.  They need to
>>> encouraged to confront the fact that the real learning happens through
>>> struggling with new ideas.  Programming is hard.  You're not going to learn
>>> how to do it simply by reading "The Elm Architecture" and a few blog posts.
>>>
>>> FYI...  ("Concepts, Techniques and Models of Computer Programming" isn't
>>> about Haskell at all.  In fact, the author isn't a big fan of Haskell.
>>> It's the perhaps the successor to the SICP.)
>>>
>>>
>>>
>>> On Friday, November 13, 2015 at 11:09:02 AM UTC-5, Christopher Anand
>>> wrote:

 It is great that you have learned about FP in your first year of
 programming, but that probably puts you in a pretty small minority.

 I wanted to know what issues beginners have so I could address them for
 people learning ELM as their first programming language.  In many ways it
 is a very good first language, but pointing people into Haskell
 documentation is pretty much guaranteed to fail.

 Christopher

 On Nov 12, 2015, at 8:03 AM, Jason Zoladz  wrote:

 It doesn't make sense to pretend that Elm wasn't influenced by, and
 doesn't inhabit, a broader functional landscape.  Pardon the pun, but Elm
 has roots. If someone has a problem with a concept, it seems completely
 reasonable to say:  You can read about that concept here, albeit in another
 dialect of FP.

 (For example, Elm has a parsing library -- elm-combine.  You wouldn't
 refer someone to Parsec tutorials to learn how it works?)

 There are so many fantastic resources in the broader world of FP (e.g.,
 pretty much anything written by Richard Bird) that can help someone write
 programs in Elm.  Why wouldn't we take advantage of those resources?

 One of the things that bothers me about the Elm community is (my
 perception) that the community: (1) wants to pretend that programming is
 effortless; and (2) believes that folks coming from Javascript are
 intimidated by the depth of new ideas that Elm exposes.

 Look, I don't have any formal (i.e., university) CS education.   I
 started programming in my spare time little more than a year ago.  The
 (unfortunate?) reality is:  there are some things in this world that you
 must tackle by sitting down with a thick book.


 On Tuesday, November 10, 2015 at 8:54:49 AM UTC-5, Christopher Anand
 wrote:
>
> Simon,
>
> Are those the only/main things Learn You a Haskell is good for?  These
> are the things we should be putting into beginner ELM books and tutorials.
> Not that Learn You a Haskell is not a 

[elm-discuss] Re: SVG element collapses?

[Ian McCowan]

On Monday, June 20, 2016 at 12:21:20 PM UTC-7, Frederick Yankowski wrote:
>
> In your view function try changing the bare svg to Svg.svg.
> ​
>

Perfect, that fixed it. Thank you. I see that I was accidentally using the 
svg from Html.

-- 
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] Learning Elm and feeling alone in the world

[Håkon Rossebø]

After I've started learning Elm, I agree that the documentation for "basic 
functional programming" could be improved. "Learn You a Haskell" is a great 
resource  and I'm surprised that "Learn You an Elm" has not been mentioned 
here yet - http://learnyouanelm.github.io/. The first chapters from "Learn 
You a Haskell" has already been adapted. I hope the community can 
contribute more to this project 
- https://github.com/learnyouanelm/learnyouanelm.github.io


fredag 13. november 2015 20.26.36 UTC+1 skrev Joey Eremondi følgende:
>
> It's worth noting that LYAH is licensed under Creative Commons, so it's 
> potentially possible that we could make a copy of it and adapt it for Elm, 
> while keeping most of the great material (and humour). As long as it was 
> not for profit, and we gave credit to the original, it is allowed.
>
> On Fri, Nov 13, 2015 at 10:08 AM, Jason Zoladz  > wrote:
>
>>
>> "Learn You a Haskell" isn't "Haskell documentation."  (That's a straw 
>> man, and you know it.)  It's a book about how to *think* in a certain 
>> paradigm.  And a lot of that paradigm translates to Elm.
>>
>> When someone finds a task or concept hard, it's usually because they 
>> don't fully understand the fundamentals.  Someone struggling with Elm 
>> likely isn't having difficulty with the syntax.  (Evan has done a great job 
>> of setting it out succinctly.)  If you're struggling with Elm, and/or if 
>> Elm is your first language, you probably need to work through the 
>> "Structure and Interpretation of Computer Programs."  It *is* a 
>> *beginner's* book.  And there are tons of online courses that teach 
>> programming through it.
>>
>> So, yes, I think we should sometimes point people to sources outside of 
>> Elm if only because translating the greatest-hits-of-computation-books into 
>> Elm is a bit wasteful.
>>
>> As for your assertion that directing folks to Haskell guarantees failure, 
>> I think you underestimate your students.  Students -- heck, people 
>> generally for that matter -- don't need to coddled.  They need to 
>> encouraged to confront the fact that the real learning happens through 
>> struggling with new ideas.  Programming is hard.  You're not going to learn 
>> how to do it simply by reading "The Elm Architecture" and a few blog posts.
>>
>> FYI...  ("Concepts, Techniques and Models of Computer Programming" isn't 
>> about Haskell at all.  In fact, the author isn't a big fan of Haskell.  
>> It's the perhaps the successor to the SICP.)
>>
>>
>>
>> On Friday, November 13, 2015 at 11:09:02 AM UTC-5, Christopher Anand 
>> wrote:
>>>
>>> It is great that you have learned about FP in your first year of 
>>> programming, but that probably puts you in a pretty small minority.
>>>
>>> I wanted to know what issues beginners have so I could address them for 
>>> people learning ELM as their first programming language.  In many ways it 
>>> is a very good first language, but pointing people into Haskell 
>>> documentation is pretty much guaranteed to fail.
>>>
>>> Christopher
>>>
>>> On Nov 12, 2015, at 8:03 AM, Jason Zoladz  wrote:
>>>
>>> It doesn't make sense to pretend that Elm wasn't influenced by, and 
>>> doesn't inhabit, a broader functional landscape.  Pardon the pun, but Elm 
>>> has roots. If someone has a problem with a concept, it seems completely 
>>> reasonable to say:  You can read about that concept here, albeit in another 
>>> dialect of FP.
>>>
>>> (For example, Elm has a parsing library -- elm-combine.  You wouldn't 
>>> refer someone to Parsec tutorials to learn how it works?)  
>>>
>>> There are so many fantastic resources in the broader world of FP (e.g., 
>>> pretty much anything written by Richard Bird) that can help someone write 
>>> programs in Elm.  Why wouldn't we take advantage of those resources?
>>>
>>> One of the things that bothers me about the Elm community is (my 
>>> perception) that the community: (1) wants to pretend that programming is 
>>> effortless; and (2) believes that folks coming from Javascript are 
>>> intimidated by the depth of new ideas that Elm exposes.
>>>
>>> Look, I don't have any formal (i.e., university) CS education.   I 
>>> started programming in my spare time little more than a year ago.  The 
>>> (unfortunate?) reality is:  there are some things in this world that you 
>>> must tackle by sitting down with a thick book.
>>>
>>>
>>> On Tuesday, November 10, 2015 at 8:54:49 AM UTC-5, Christopher Anand 
>>> wrote:

 Simon,

 Are those the only/main things Learn You a Haskell is good for?  These 
 are the things we should be putting into beginner ELM books and tutorials. 
  
 Not that Learn You a Haskell is not a great book, but there are probably a 
 lot of people who are intimidated by the suggestion that you need to learn 
 Haskell first.

 Christopher

 On Nov 10, 2015, at 2:34 AM, Simon  wrote:

 When I first met 

[elm-discuss] Re: SVG element collapses?

[Ian McCowan]

Small update: I revised the Elm code in the gist to remove some extraneous 
stuff and get it to work in http://elm-lang.org/try, where it exhibits the 
same problem.

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

[elm-discuss] SVG element collapses?

[Ian McCowan]

Hi,

I'm having trouble with a pretty basic svg element. See the following gist. 
https://gist.github.com/valrus/ee6c40a19cc928a1e6d67bf986ed67d6

The Elm code is supposed to allow drawing in the svg but it generates a 
page with a "collapsed" svg element whose dimensions are 2 x 21, even 
though the width and height are explicitly specified as 400 and 300. But I 
copied the plain-HTML part (i.e. basically dropping the script tag from the 
rendered Elm output) and the svg displays with the correct dimensions.

I feel like I'm probably missing something obvious here, but I can't tell 
what it might be. Can anyone help?

Thanks,
Ian

-- 
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 a reason Date has no setters?

[Maxime Dantec]

Another fact about to consider IMHO: Libraries can be fat in pure Elm 
thanks to the efficient dead-code elimination in 0.17 -- if a function is 
not referenced in your code, or the code you call, it will not be exported 
-- while the native parts of them is only left to something like closure or 
uglify. So, it is better to have pure elm libraries, and their raw size is 
only relevant if you use all the features.


On Sunday, June 19, 2016 at 10:31:22 PM UTC+2, Dan P wrote:
>
> I realize elm-date-extra  exists, 
> but it's bloated, (apparently) unstable, reproduces working JS APIs, and is 
> not likely to be merged to core any time soon[1]. I'm considering making a 
> simplified fork of the former, but this rejected pull request 
>  gives me pause. Can anyone 
> more familiar with the Elm ecosystem please advise?
>
> [1]: Not to say that it doesn't also provide useful functionality! But 
> core.Date is a little spartan, don't you think?
>
>
> On Sunday, June 19, 2016 at 3:03:51 PM UTC-4, Dan P wrote:
>>
>> (e.g. Date.setDate() in JS)
>>
>> Or would a pull request not be in vain?
>>
>> Compare:
>> http://package.elm-lang.org/packages/elm-lang/core/4.0.1/Date
>>
>>
>> https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date
>>
>>

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

Re: [elm-discuss] Re: Is there a reason Date has no setters?

[Ian Mackenzie]

I think one other thing to keep in mind is that Evan has expressed a lot of 
interest in other (non-JavaScript) compilation targets in the future, so I 
think he would be very cautious about tying core library functionality too 
closely to exactly how JavaScript happens to do things. Especially for 
stuff like date/time manipulation which (correct me if I'm wrong) is 
unlikely to be a performance bottleneck, I think the best long-term 
solution is going to be a well thought out pure-Elm library using common 
Elm patterns and idioms - which would probably look very different than a 
direct wrapper over JavaScript. Perhaps that is something that will be 
implemented as a core library at some point, but right now I'd imagine a 
lot of other things are a higher priority.

On Monday, 20 June 2016 08:00:00 UTC+10, Dan P wrote:
>
> I appreciate the immutability part, but we can make these setters into 
> pure functions by creating new Date objects with each call.
>
> Secondly, when you're rewriting pure functions provided by the JS API 
> itself, the only thing you do is increase the chance of an implementation 
> mistake. The only thing that isn't totally uniform across browsers is 
> Date.parseString(). There are things that can be improved, like how Haskell 
> uses types to distinguish UTCTime and LocalTime, but don't fix what ain't 
> broke.
>
>
> On Sunday, June 19, 2016 at 5:37:15 PM UTC-4, Joey Eremondi wrote:
>>
>>  reproduces working JS APIs
>>
>>
>> This is the goal! Reproducing libraries in pure Elm is much safer and 
>> more desirable than writing wrappers around JS.
>>
>> Make sure that whatever you do, you respect Elm's philosophy: all data is 
>> immutable, and side-effects are always wrapped in a Task or a Cmd.
>>
>> On Sun, Jun 19, 2016 at 1:31 PM, Dan P  wrote:
>>
>>> I realize elm-date-extra  
>>> exists, 
>>> but it's bloated, (apparently) unstable, reproduces working JS APIs, and is 
>>> not likely to be merged to core any time soon[1]. I'm considering making a 
>>> simplified fork of the former, but this rejected pull request 
>>>  gives me pause. Can anyone 
>>> more familiar with the Elm ecosystem please advise?
>>>
>>> [1]: Not to say that it doesn't also provide useful functionality! But 
>>> core.Date is a little spartan, don't you think?
>>>
>>>
>>>
>>> On Sunday, June 19, 2016 at 3:03:51 PM UTC-4, Dan P wrote:

 (e.g. Date.setDate() in JS)

 Or would a pull request not be in vain?

 Compare:
 http://package.elm-lang.org/packages/elm-lang/core/4.0.1/Date


 https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date

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