Re: [elm-discuss] Re: Unit testing what else

[Nick H]

Elm Test does support test case minimization. From the Fuzz documentation
:

Fuzzers will often generate edge cases likely to find bugs. If the fuzzer
> can make your test fail, it also knows how to "shrink" that failing input
> into more minimal examples, some of which might also cause the tests to
> fail. In this way, fuzzers can usually find the smallest or simplest input
> that reproduces a bug.


I don't think it's possible to unit test ports. Since they are interfaces
to another environment, they would need to be integration tests. And I am
pretty sure such tests are not possible within Elm at the moment. To quote
again from the elm-test (that sure is some educational documentation!)

For integration or end-to-end testing, use your favorite PhantomJS or
> Selenium webdriver, such as Capybara.


As far as unit testing type constructors goes, the question I would ask is,
"Is it possible for this test to fail?" In the example you provide, I think
the answer is no. If the record you are constructing has multiple fields
with the same type, then you could get a test failure by mixing up the
order you pass the arguments. But even so, this would be implicitly tested
by every other unit test that used that type, wouldn't it?

On Fri, Mar 17, 2017 at 7:27 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Thursday, March 16, 2017 at 6:52:04 PM UTC, Pedro Castilho wrote:
>>
>> I believe Elm lends itself best to property-based testing
>> 
>> of pure code rather than unit testing. Property-based testing can make
>> stronger assertions than unit testing, as long as your code is pure (yet
>> another reason for why you should keep the part of your code that interacts
>> with the "real world" minimal)
>>
>> In general, you do not need to test whether a constructor creates an item
>> of a given type - that's what the type system is for (and a small part of
>> the beauty of using a strongly-typed language)
>>
>
> Hi, elm-test provides Fuzzers for property based testing. Is it missing
> something though compared with Scala Check (and possibly QuickCheck, but
> never used that)? That would be automatic test case minimization, is that
> in elm-test or some other testing library for Elm?
>
> The idea is that if you present say a list to a test case, and that list
> fails the test, the test code will then try the same list again but with
> one element missing, and it will continue repeating that and report the
> smallest list that fails the test.
>
> --
> 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] Wrong package not found reported using elm-make 0.18.0

[Nick H]

This is a nice detailed description of the bug! I see this behavior too.

BUT this is not an issue with elm-make. It is an issue with elm-package.
And there is already a bug report open there
. (elm-make is running
elm-package silently, and it is elm-package that is giving the erroneous
"Package configured successfully".)

On Fri, Mar 3, 2017 at 12:05 PM, hossameldeenfci 
wrote:

> The purpose of this post is for someone to double-check on me before I
> post an issue to elm-make .
>
> *Summary*
> When a *non-existent package version* is specified (let's call the
> package *Foo*), instead of *elm-make* saying the error is with package
> Foo, it says the *error* is with another package *Bar* whose *version* is
> *correct*.
>
> *Simplest elm-package.json that causes the problem:*
>
> {
>   "version": "1.0.0",
>   "summary": "My personal website written in Elm",
>   "repository": "https://github.com/user/project.git;,
>   "license": "All Rights Reserved",
>   "source-directories": [
> "."
>   ],
>   "exposed-modules": [],
>   "dependencies": {
> "evancz/url-parser": "2.1.0 <= v < 3.0.0",
> "evancz/elm-markdown": "3.0.1 <= v < 4.0.0"
>   },
>   "elm-version": "0.18.0 <= v < 0.19.0"
> }
>
>
> *Expected:*
>
>
>
> *Error: Your .elm/packages/ directory may be corrupted. I was led to
> believe thatevancz/url-parser existed, but I could not find anything when I
> went to look upthe published versions of this package.*
> Or some error on `url-parser`'s version. Because the newest version is
> 2.0.1, no 2.1.0 version exists.
>
> *Actual:*
> Packages configured successfully!
> Could not find package evancz/elm-markdown.
>
>
> Maybe your elm-stuff/ directory has been corrupted? You can usually fix
> stuff
> like this by deleting elm-stuff/ and rebuilding your project.
> The problems here are:
> - First, it says `Package configured successfully`. I don't think that's a
> correct statement since `url-parser:2.1.0` doesn't exist.
> - The more important part: `elm-markdown`'s versions are configured
> correctly, the problem is with `url-parser`.
>
> *Extra info:*
> - I'm in some project, my elm-package.json and elm files are inside elm/
> - command run: (cd elm && rm -rf elm-stuff && elm-make Main.elm
> --output=../assets/gen/javascripts/elm-main.js)
> - npm elm Version: 0.18.0
> - OS: Ubuntu.
>
>
> *So, could someone try this out to see if the same behaviour occurs and
> confirm if they also think this behaviour is faulty, please?*
>
> Thanks in advance!
>
> --
> 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] Html.Attributes.selected in Html.select

[Nick H]

OK, upon double-checking the MDN docs for select
<https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select>and input
<https://developer.mozilla.org/en-US/docs/Web/Events/input>, I can confirm
that select does not fire "onInput". Elm does not have a built-in
"onChange" event handler, so I think that the custom event handler is the
only solution. And now I will stop pinging the thread :-)

On Mon, Feb 27, 2017 at 10:17 AM, Nick H <falling.maso...@gmail.com> wrote:

> (and Attr is an alias for Html.Attributes)
>
> On Mon, Feb 27, 2017 at 10:16 AM, Nick H <falling.maso...@gmail.com>
> wrote:
>
>> I am looking through some code where I successfully implemented a
>> drop-down menu, and it appears I wrote a custom event handler. "onInput"
>> did not work for me.
>>
>> Here is the function that I wrote (Evt is an alias for Html.Events).
>>
>> select : (String -> a) -> String -> List ( String, String ) -> Html a
>> select sendMsg selection options =
>> let
>> toOption ( value, label ) =
>> Html.option
>> [ Attr.selected (selection == value)
>> , Attr.value value
>> ]
>> [ Html.text label ]
>>
>> handler =
>> Evt.on "change" (Json.map sendMsg Evt.targetValue)
>> in
>> Html.select [ handler ] (List.map toOption options)
>>
>> On Mon, Feb 27, 2017 at 6:53 AM, <agjf.tuc...@gmail.com> wrote:
>>
>>> I have been trying to use Html.select (the drop-down menu).
>>> Unfortunately the selected attribute doesn't seem to work for me.
>>>   Some context: I am attempting the exercises at the bottom of
>>> https://guide.elm-lang.org/architecture/effects/http.html.  As new
>>> topics are entered in the input box, they should be added to the drop-down
>>> menu.  I found this would sporadically cause the menu selection to jump
>>> around, so I tried to handle it manually using the selected attribute.
>>>   Anybody have any ideas how to do this so it works?  The relevant piece
>>> of code looks something like this:
>>>
>>> view : Model -> Html Msg
>>> view model =
>>> div []
>>> [ input [ onInput ChangeTopic ] []
>>> , select [ onInput SelectTopic ]
>>> (List.map
>>> (makeOption model.selectedTopic)
>>> (Set.toList model.allTopics)
>>> )
>>> , button [ onClick MorePlease ] [ text "Go!" ]
>>> , img [ src model.gifUrl ] []
>>> ]
>>>
>>> makeOption : String -> String -> Html msg
>>> makeOption selectedTopic topic =
>>> option
>>> (if topic == selectedTopic then
>>> [ value topic, selected True ]
>>>  else
>>> [ value topic ]
>>> )
>>> [ text topic ]
>>>
>>> --
>>> 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] Html.Attributes.selected in Html.select

[Nick H]

(and Attr is an alias for Html.Attributes)

On Mon, Feb 27, 2017 at 10:16 AM, Nick H <falling.maso...@gmail.com> wrote:

> I am looking through some code where I successfully implemented a
> drop-down menu, and it appears I wrote a custom event handler. "onInput"
> did not work for me.
>
> Here is the function that I wrote (Evt is an alias for Html.Events).
>
> select : (String -> a) -> String -> List ( String, String ) -> Html a
> select sendMsg selection options =
> let
> toOption ( value, label ) =
> Html.option
> [ Attr.selected (selection == value)
> , Attr.value value
> ]
> [ Html.text label ]
>
> handler =
> Evt.on "change" (Json.map sendMsg Evt.targetValue)
> in
> Html.select [ handler ] (List.map toOption options)
>
> On Mon, Feb 27, 2017 at 6:53 AM, <agjf.tuc...@gmail.com> wrote:
>
>> I have been trying to use Html.select (the drop-down menu).
>> Unfortunately the selected attribute doesn't seem to work for me.
>>   Some context: I am attempting the exercises at the bottom of
>> https://guide.elm-lang.org/architecture/effects/http.html.  As new
>> topics are entered in the input box, they should be added to the drop-down
>> menu.  I found this would sporadically cause the menu selection to jump
>> around, so I tried to handle it manually using the selected attribute.
>>   Anybody have any ideas how to do this so it works?  The relevant piece
>> of code looks something like this:
>>
>> view : Model -> Html Msg
>> view model =
>> div []
>> [ input [ onInput ChangeTopic ] []
>> , select [ onInput SelectTopic ]
>> (List.map
>> (makeOption model.selectedTopic)
>> (Set.toList model.allTopics)
>> )
>> , button [ onClick MorePlease ] [ text "Go!" ]
>> , img [ src model.gifUrl ] []
>> ]
>>
>> makeOption : String -> String -> Html msg
>> makeOption selectedTopic topic =
>> option
>> (if topic == selectedTopic then
>> [ value topic, selected True ]
>>  else
>> [ value topic ]
>> )
>> [ text topic ]
>>
>> --
>> 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] Html.Attributes.selected in Html.select

[Nick H]

I am looking through some code where I successfully implemented a drop-down
menu, and it appears I wrote a custom event handler. "onInput" did not work
for me.

Here is the function that I wrote (Evt is an alias for Html.Events).

select : (String -> a) -> String -> List ( String, String ) -> Html a
select sendMsg selection options =
let
toOption ( value, label ) =
Html.option
[ Attr.selected (selection == value)
, Attr.value value
]
[ Html.text label ]

handler =
Evt.on "change" (Json.map sendMsg Evt.targetValue)
in
Html.select [ handler ] (List.map toOption options)

On Mon, Feb 27, 2017 at 6:53 AM,  wrote:

> I have been trying to use Html.select (the drop-down menu).  Unfortunately
> the selected attribute doesn't seem to work for me.
>   Some context: I am attempting the exercises at the bottom of
> https://guide.elm-lang.org/architecture/effects/http.html.  As new topics
> are entered in the input box, they should be added to the drop-down menu.
> I found this would sporadically cause the menu selection to jump around, so
> I tried to handle it manually using the selected attribute.
>   Anybody have any ideas how to do this so it works?  The relevant piece
> of code looks something like this:
>
> view : Model -> Html Msg
> view model =
> div []
> [ input [ onInput ChangeTopic ] []
> , select [ onInput SelectTopic ]
> (List.map
> (makeOption model.selectedTopic)
> (Set.toList model.allTopics)
> )
> , button [ onClick MorePlease ] [ text "Go!" ]
> , img [ src model.gifUrl ] []
> ]
>
> makeOption : String -> String -> Html msg
> makeOption selectedTopic topic =
> option
> (if topic == selectedTopic then
> [ value topic, selected True ]
>  else
> [ value topic ]
> )
> [ text topic ]
>
> --
> 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-lang/http and evancz/elm-http

[Nick H]

Gordon, I think I beat you to it. https://github.com/evancz/elm-http/pull/54

On Sat, Feb 4, 2017 at 2:59 AM, Gordon Klaus <gordon.kl...@gmail.com> wrote:

> I also stumbled over the switch from evancz/elm-http to elm-lang/http.  So
> I created https://github.com/evancz/elm-http/pull/56.  I suggest you do
> the same for other moved packages.
>
> A complementary enhancement would be to automatically display the
> `elm-version` string on each package.elm-lang.org page.  Maybe even
> showing it in bright red when it doesn't include the latest Elm version.
> Thoughts?
>
>
> On Tuesday, January 31, 2017 at 7:37:50 AM UTC+1, Andrew Radford wrote:
>>
>> This sort of thing happens a lot (that and re-naming like
>> elm-linear-algebra to just linear-algebra). bit of a trap for new users.
>> I wonder if there is a formal way to leave a trail to the superseding
>> package. The old packages usually still get a lot of hits from Google and
>> references from projects still using them.
>>
>>
>> On Tuesday, 31 January 2017 04:17:18 UTC, Nick H wrote:
>>>
>>> They are the same library. elm-http was migrated from evancz/ to
>>> elm-lang/ when 0.18 was released, so only the latter will work. I guess the
>>> URL function was removed.
>>>
>>>
>>>
>>> On Mon, Jan 30, 2017 at 3:05 PM, Brian Marick <mar...@exampler.com>
>>> wrote:
>>>
>>>> I’m confused by the relationship between these two libraries. They seem
>>>> to overlap in functionality, but only the latter has `url` (
>>>> http://package.elm-lang.org/packages/evancz/elm-http/latest/Http#url)
>>>> which seems pretty basic.
>>>>
>>>> Where’s the right place to find a URL-construction function?
>>>>
>>>> --
>>>> 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] elm-lang/http and evancz/elm-http

[Nick H]

They are the same library. elm-http was migrated from evancz/ to elm-lang/
when 0.18 was released, so only the latter will work. I guess the URL
function was removed.



On Mon, Jan 30, 2017 at 3:05 PM, Brian Marick  wrote:

> I’m confused by the relationship between these two libraries. They seem to
> overlap in functionality, but only the latter has `url` (
> http://package.elm-lang.org/packages/evancz/elm-http/latest/Http#url)
> which seems pretty basic.
>
> Where’s the right place to find a URL-construction function?
>
> --
> 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] Modeling units of measure with phantom types

[Nick H]

In the same way that a vector is usually represented by a line segment, a
bivector can be represented by a parallelogram where the component vectors
form the sides. I was imagining a naive representation where you just store
the component vectors.

type alias Bivector = { a : Vector, b : Vector }

So if force and position are 3D vectors, then the torque bivector is 6D.
(But you could come up with more efficient representations that use fewer
components.)





On Sun, Jan 22, 2017 at 5:58 PM, Max Goldstein 
wrote:

> I think the quantities you meant to compare are torque and energy (both of
>> which have units of force*length).
>>
>
> Yup, sorry.
>
>
>> Torque, although sometimes expressed as a scalar or a vector, is actually
>> best represented as a bivector (two components per spatial dimension in
>> whatever system we are looking at).
>>
>
> How so? I know that the force and length are orthogonal, but that would
> still be one component per spatial dimension.
>
> --
> 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] Why are unbound type variables forbidden for functions in records?

[Nick H]

OK, I understand... you're up in the stratosphere somewhere :-)

I can't offer anymore insight, but to back up Maxime. toString and the
equality operators are the only functions that take arguments of
unspecified type and return a value with a fixed type.

On Fri, Jan 20, 2017 at 11:06 AM, Martin Cerny <cern...@gmail.com> wrote:

> Thanks for the ideas, but neither is satisfactory for my (crazy and
> contrived) use case :-)
>
> @Maxime:
> Once again, I maybe missing something, but Basic.toString is not the only
> function that does that. My particular aim was to combine native functions
> and functions that simply ignore the parameter which are both examples of
> functions that can accept anything.
>
> Also, more broadly you could have definitions such as:
> type alias Mapper a =
> { map : List b -> (b -> a) -> List a
> }
>
> now - due to the erasing implementation of Elm, I can execute the map
> function safely for any type of input as long as the first two parameters
> match. Now this latter case would require the compiler to infer things like
> m : Mapper Int
>
> x = m.map ["a" "b"]
> --x: (String -> Int) -> List Int
>
> Which may and may not be the exact same thing the compiler already does
> for regular functions.
> There might even be a non-crazy use case for that :-)
>
> @Nick:
> I am aware of that possiblity, but adding type variables is not an option
> in my use case. I need to be able to call things like (highly contrived for
> brevity),
> func: Convertor a -> Int -> String -> (a,a)
> func conv i s =
>   (conv.convert i, conv.convert s)
>
> which I could not do if I bind the type variable outside the individual
> subexpressions.
>
> In case you are wondering why would I want such madness, I was toying with
> the idea of having automatic serialization/deserialization (JSON/XML etc.)
> of arbitrary non-function types (records and possibly also union types) in
> almost pure Elm, with only a single magic native function. The idea was
> like that:
> --pure Elm type
> type TypeInfo a = ...
>
> --JavaScript magic
> getTypeInfo: a -> TypeInfo a
>
> --pure Elm
> decoder: TypeInfo a -> Json.Decode.Decoder a
>
> However, I ended up requiring the functions of the aforementioned weird
> form in TypeInfo a so it probably cannot work. I am aware of cases that
> could not be solved in principle without help from compiler even if
> everything worked as I hoped it would (and maybe there are other problems I
> missed), but I had fun trying :-)
>
> Still curious, if this idea could work in general or if it implies some
> problems for the whole type system...
>
> Thanks
> Martin
>
>
> On Friday, 20 January 2017 19:52:48 UTC+1, Nick H wrote:
>>
>> All type variables need to be mentioned on the left side of the type
>> alias definition. But that doesn't mean you need to bind them. This
>> compiles fine:
>>
>> type alias Convertor b a =
>> { convert : b -> a
>> }
>>
>> c: Convertor b String
>> c = {convert = convertString}
>>
>> In other words, the unbound type variable needs to be mentioned in the
>> type signature, even if you are wrapping more abstractions over it.
>>
>> On Fri, Jan 20, 2017 at 3:06 AM, Martin Cerny <cer...@gmail.com> wrote:
>>
>>> Hi all,
>>> I was trying to do some Elm Voodoo and I stumbled upon a funny thing. It
>>> is probably deeply wrong, but I want to understand why it is wrong :-)
>>>
>>> What I was trying to do was to define a type like this:
>>>
>>> type alias Convertor a =
>>> { convert : b -> a
>>> }
>>>
>>>
>>> Here I get "Type alias `Convertor` must declare its use of type variable
>>> b"
>>> Now, I understand, why you cannot have
>>>
>>> type alias X a =  { field1: a, field2: b }
>>>
>>> But with the source type of functions, things are IMHO different than
>>> with values. You cannot write values of unbound types and you could not
>>> decide whether two instances of X are really the same type.
>>> But you can easily write functions that have unbound source types - like
>>> this one:
>>>
>>> convertString: a -> String
>>> convertString x =
>>> (toString x) ++ "_Foo"
>>>
>>>
>>> And since all of functions with this signature really have the same type
>>> at JavaScript level, two instances of 'Convertor a' would always had the
>>> same type.
>>>
>>> Now if I had
>>> c: Convertor 

Re: [elm-discuss] Why are unbound type variables forbidden for functions in records?

[Nick H]

All type variables need to be mentioned on the left side of the type alias
definition. But that doesn't mean you need to bind them. This compiles fine:

type alias Convertor b a =
{ convert : b -> a
}

c: Convertor b String
c = {convert = convertString}

In other words, the unbound type variable needs to be mentioned in the type
signature, even if you are wrapping more abstractions over it.

On Fri, Jan 20, 2017 at 3:06 AM, Martin Cerny  wrote:

> Hi all,
> I was trying to do some Elm Voodoo and I stumbled upon a funny thing. It
> is probably deeply wrong, but I want to understand why it is wrong :-)
>
> What I was trying to do was to define a type like this:
>
> type alias Convertor a =
> { convert : b -> a
> }
>
>
> Here I get "Type alias `Convertor` must declare its use of type variable b"
> Now, I understand, why you cannot have
>
> type alias X a =  { field1: a, field2: b }
>
> But with the source type of functions, things are IMHO different than with
> values. You cannot write values of unbound types and you could not decide
> whether two instances of X are really the same type.
> But you can easily write functions that have unbound source types - like
> this one:
>
> convertString: a -> String
> convertString x =
> (toString x) ++ "_Foo"
>
>
> And since all of functions with this signature really have the same type
> at JavaScript level, two instances of 'Convertor a' would always had the
> same type.
>
> Now if I had
> c: Convertor String
> c = {convert = convertString}
> the whole thing seems type-safe...
>
> So my question is:
> Is this syntax forbidden, because it is an obscure feature that is not
> worth supporting, or would this syntax really allow for some type unsafe
> code?
>
> Thanks!
>
> Martin
>
>
> --
> 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] State of Elm Survey 2017 is live

[Nick H]

>
> The same would apply to people working alone as freelancers.
>

I just put in 10 :-)

On Wed, Jan 18, 2017 at 3:48 PM, Matthieu Pizenberg <
matthieu.pizenb...@gmail.com> wrote:

> Hey, I just participated in the survey :)
> A few remarks before forgetting:
> - I am not sure large scale notations (0->10) with only indications of
> what the 2 ends are, are a good thing in surveys. 0 to 3 is very often
> enough (not at all / small / medium / high )
> - The question "What is your level of influence within your team?" may
> not apply to everyone. I am currently a PhD student in image processing, so
> I can't really say "let's use elm" ^^. The same would apply to people
> working alone as freelancers.
>
> On Wednesday, January 18, 2017 at 9:15:35 PM UTC+1, Brian Hicks wrote:
>>
>> You're right that there are a large number of people using Elm for side
>> projects. I'm still interested in their professional experiences. We want
>> to reduce the activation energy to go from hobby to production.
>>
>> There are about a hundred responses so far! Keep them coming!
>>
>> Also for those curious, here are the results from last year:
>> https://www.brianthicks.com/post/2016/04/22/state-of-elm-2016-results/ Forgot
>> to include that before!
>>
>> On Jan 18, 2017, 1:57 PM -0600, Martin DeMello ,
>> wrote:
>>
>> the survey seemed overly focused on people whose day job was web
>> development. i'm guessing a significant fraction of the elm community are
>> people developing side projects.
>>
>> martin
>>
>> --
> 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] OK, or very very wrong?

[Nick H]

Your particular example can be rewritten easily to not use functions (and
with even less duplication):

type Msg
= Add Int

view model =
div []
[ button [ onClick (Add -1) ] [ text "-" ]
, div [] [ text (toString model) ]
, button [ onClick (Add 1) ] [ text "+" ]
]

update msg model =
case msg of
Add delta ->
model + delta


On Tue, Jan 17, 2017 at 11:31 PM, Nick H <falling.maso...@gmail.com> wrote:

> I would come down on the side of very very wrong. Functions can't be
> converted into strings, and they can't be checked for equality. So if you
> need to debug your program (say, with the interactive debugger), There is
> no way to examine the data being passed in your commands.
>
>
> On Tue, Jan 17, 2017 at 7:24 PM, Marshall handheld Flax <
> m.droid.f...@gmail.com> wrote:
>
>> Is it wrong for Cmds to contain functions (as opposed to data within
>> constructors)?  If it is a reasonable practice, it would allow for more
>> functional component-like modules, but does this violate the Elm
>> architecture?  If it does, is it explicitly mentioned in the docs -- I
>> don't remember seeing it. Here's http://elm-lang.org/examples/buttons
>> rewritten in the Cmd-contains-functions style. Thank you!
>>
>> module Main exposing (..)
>>
>> import Html exposing (beginnerProgram, div, button, text)
>> import Html.Events exposing (onClick)
>>
>> main =
>> beginnerProgram { model = 0, view = view, update = update }
>>
>> type Msg
>> = Transform (Int -> Int)
>>
>> view model =
>> div []
>> [ button [ onClick (Transform ((+) -1)) ] [ text "-" ]
>> , div [] [ text (toString model) ]
>> , button [ onClick (Transform ((+) 1)) ] [ text "+" ]
>> ]
>>
>> update msg model =
>> case msg of
>> Transform xform ->
>> xform model
>>
>>
>> --
>> 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] OK, or very very wrong?

[Nick H]

I would come down on the side of very very wrong. Functions can't be
converted into strings, and they can't be checked for equality. So if you
need to debug your program (say, with the interactive debugger), There is
no way to examine the data being passed in your commands.


On Tue, Jan 17, 2017 at 7:24 PM, Marshall handheld Flax <
m.droid.f...@gmail.com> wrote:

> Is it wrong for Cmds to contain functions (as opposed to data within
> constructors)?  If it is a reasonable practice, it would allow for more
> functional component-like modules, but does this violate the Elm
> architecture?  If it does, is it explicitly mentioned in the docs -- I
> don't remember seeing it. Here's http://elm-lang.org/examples/buttons
> rewritten in the Cmd-contains-functions style. Thank you!
>
> module Main exposing (..)
>
> import Html exposing (beginnerProgram, div, button, text)
> import Html.Events exposing (onClick)
>
> main =
> beginnerProgram { model = 0, view = view, update = update }
>
> type Msg
> = Transform (Int -> Int)
>
> view model =
> div []
> [ button [ onClick (Transform ((+) -1)) ] [ text "-" ]
> , div [] [ text (toString model) ]
> , button [ onClick (Transform ((+) 1)) ] [ text "+" ]
> ]
>
> update msg model =
> case msg of
> Transform xform ->
> xform model
>
>
> --
> 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] Convert String to symbol (previously `Text.fromString`, like Haskell's `read`)

[Nick H]

I'm not sure such a feature would have any uses. Right now, all Elm
functions have well-typed return values.

Ports are the one place where a type annotation is used to enforce a type
at runtime. So I suppose ports are Elm's analog to "read". There has been
lots of discussion about improving ports, to translate JavaScript objects
into ADTs. It's possible that change might happen at some point.


On Tue, Jan 17, 2017 at 9:07 AM, Josh Szmajda <jos...@gmail.com> wrote:

> Ah yes this makes sense, we'd need the explicit type annotation. Has that
> functionality been discussed? I know I saw a talk where Evan mentioned
> adding features to the language over time intentionally to help drive
> adoption.
>
> Thanks!
>
> On Monday, January 16, 2017 at 9:06:50 PM UTC-5, Nick H wrote:
>>
>> I doubt such a function will be introduced any time soon, because it's
>> not a properly typed operation. In Haskell, you have to add the type
>> annotation to the function call because read's return type is ambiguous.
>> However, Elm doesn't have any similar ability.
>>
>> For converting Strings to numeric types, there are String.toInt and
>> String.toFloat.
>>
>> For doing what your example does, I might consider using a dictionary
>> mapping strings to states. Maybe Something like:
>>
>> viewStates = Dict.fromList [ ("ViewDocList", ViewDocList),
>> ("ViewDocument", ViewDocument) ]
>>
>> locationUpdate location =
>>   case Dict.get location viewStates of
>> Just state ->
>>   ViewState state
>>
>> Nothing ->
>>   App.NoOp
>>
>> You still need to manually associate strings with view states, but now
>> locationUpdate has the form you want.
>>
>> On Mon, Jan 16, 2017 at 12:44 PM, Josh Szmajda <jos...@gmail.com> wrote:
>>
>>> Hey folks!
>>>
>>> This is in reference to https://github.com/elm-lang/core/issues/805
>>>
>>> I'm looking for a function to convert a String to an internal symbol
>>> (signature `String -> a`). Previously this was in `Text.fromString` but
>>> apparently that has been removed.
>>>
>>> The use-case I have in mind is this router:
>>>
>>> ```
>>> locationUpdate : Navigation.Location -> App.Msg
>>> locationUpdate location =
>>>   case (String.dropLeft 2 location.hash) of
>>>
>>> "ViewDocList" -> ViewState ViewDocList
>>>
>>> "ViewDocument" -> ViewState ViewDocument
>>>
>>> _ -> App.NoOp
>>>
>>> -- Would rather code this as:
>>> -- case Text.fromString msg of
>>> --   Just value -> ViewState value
>>> --   Nothing-> App.NoOp
>>> ```
>>>
>>> In Haskell this would be `read`:
>>>
>>> ```
>>> Prelude> read "4.5" :: Float
>>> 4.5
>>> Prelude> :t read "4.5" :: Float
>>> read "4.5" :: Float :: Float
>>> ```
>>>
>>> Any ideas on when this might come back?
>>>
>>> Thanks!
>>> -Josh
>>>
>>> --
>>> 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] Convert String to symbol (previously `Text.fromString`, like Haskell's `read`)

[Nick H]

I doubt such a function will be introduced any time soon, because it's not
a properly typed operation. In Haskell, you have to add the type annotation
to the function call because read's return type is ambiguous. However, Elm
doesn't have any similar ability.

For converting Strings to numeric types, there are String.toInt and
String.toFloat.

For doing what your example does, I might consider using a dictionary
mapping strings to states. Maybe Something like:

viewStates = Dict.fromList [ ("ViewDocList", ViewDocList), ("ViewDocument",
ViewDocument) ]

locationUpdate location =
  case Dict.get location viewStates of
Just state ->
  ViewState state

Nothing ->
  App.NoOp

You still need to manually associate strings with view states, but now
locationUpdate has the form you want.

On Mon, Jan 16, 2017 at 12:44 PM, Josh Szmajda  wrote:

> Hey folks!
>
> This is in reference to https://github.com/elm-lang/core/issues/805
>
> I'm looking for a function to convert a String to an internal symbol
> (signature `String -> a`). Previously this was in `Text.fromString` but
> apparently that has been removed.
>
> The use-case I have in mind is this router:
>
> ```
> locationUpdate : Navigation.Location -> App.Msg
> locationUpdate location =
>   case (String.dropLeft 2 location.hash) of
>
> "ViewDocList" -> ViewState ViewDocList
>
> "ViewDocument" -> ViewState ViewDocument
>
> _ -> App.NoOp
>
> -- Would rather code this as:
> -- case Text.fromString msg of
> --   Just value -> ViewState value
> --   Nothing-> App.NoOp
> ```
>
> In Haskell this would be `read`:
>
> ```
> Prelude> read "4.5" :: Float
> 4.5
> Prelude> :t read "4.5" :: Float
> read "4.5" :: Float :: Float
> ```
>
> Any ideas on when this might come back?
>
> Thanks!
> -Josh
>
> --
> 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] Cannot find module "String"...

[Nick H]

I'm curious, what happens if you remove the "import String" line
altogether? String should now be imported by default.

On Mon, Jan 9, 2017 at 9:00 AM, Rex van der Spuy 
wrote:

> Hi Everyone,
>
> Here's a strange puzzle!
> While upgrading some old 0.17 to 0.18. I received this error message:
>
> ```
> I cannot find module 'String'.
>
> Module 'Adventure' is trying to import it.
>
> Potential problems could be:
>   * Misspelled the module name
>   * Need to add a source directory or new dependency to elm-package.json
> ```
>
> Here's the section of the `Adventure` module that's trying to import
> `String`:
>
> ```
> module Adventure exposing (..)
>
> import Html exposing (..)
> import Html.Attributes exposing (..)
> import Html.Events exposing (..)
> import String
>
> ```
> I know that `String` is part of `core`, and checking my
> `elm-stuff/exact-dependencies.json` file, I can see that the latest
> version of `core` is installed:
>
> ```
> {
> "elm-lang/animation-frame": "1.0.1",
> "mdgriffith/elm-style-animation": "3.5.1",
> "elm-lang/virtual-dom": "2.0.3",
> "elm-lang/html": "2.0.0",
> "elm-community/list-extra": "4.0.0",
> "elm-lang/svg": "2.0.0",
> "elm-lang/core": "5.0.0"
> }
> ```
> And checking the `packages/elm-lang` confirms that it's there.
>
> I've tried deleting `elm-stuff` and rebuilding, but that doesn't fix the
> problem.
>
> Can anyone suggest where I should look next, or what I should try?
> Thanks!!
>
>
> --
> 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: Emphasizing /r/elm more

[Nick H]

I have never really used Reddit, but I am happy to try it out! That second
bullet point in particular has really been wearing down my morale lately.

Don't forget, elm-discuss still has top billing on the community page


On Mon, Jan 2, 2017 at 8:23 PM, Mark Hamburg  wrote:

> The web interface to Reddit is abysmal. Email isn't great but Reddit seems
> incredibly tedious.
>
> On Mon, Jan 2, 2017 at 7:21 PM, Charlie Koster 
> wrote:
>
>> I just wanted to confirm one of your assertions anecdotally. In the past
>> week I wrote two Elm blog posts and opted to post them to /r/elm rather
>> than elm-discuss for precisely the first two bullet points you listed. A
>> linear discussion would have been largely unhelpful and distracting.
>>
>> I also wanted to reinforce the importance of good moderation. I've seen
>> small subreddits grow and die due to a lack of moderation, but the ones
>> that have good moderation that encourage productive discussion end up doing
>> 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.
>>
>
> --
> 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: Tuple indexing?

[Nick H]

I don't think the internal storage of tuples vs records is the difficulty
that Max is pointing out. (I think your assumption is correct, that they
are built similarly "under the hood.") Rather, the difficulty is that these
tuple accessors would require a major extension to Elm's type system.

On Tue, Dec 27, 2016 at 8:49 AM, Mike MacDonald  wrote:

> I was assuming the mechanism used for records with a certain field (types
> like `{ a | field : t }` could be reused here, but maybe the internal
> storage of records and tuples is divergent.
>
>
> On Tuesday, December 27, 2016 at 11:38:24 AM UTC-5, Max Goldstein wrote:
>>
>> This solution would require some not-currently-in-place polymorphism
>> since .0 can access the first field in tuples of many sizes. That is, you'd
>> need one signature that comprises all of:
>>
>> .0 : (a, b) -> a
>> .0 : (a, b, c) -> a
>> .0 : (a, b, c, d) -> a
>> ... and so on
>>
>> It sounds like the third-party library should be using records; maybe you
>> can ask them to change their API? I haven't seen many good uses of
>> n-tuples, n > 2, recently.
>>
>>
>> --
> 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: DOM geometry / SVG library

[Nick H]

Yes, I agree with Rex. The DOM is write-only by design. Going forward, I
don't expect there ever to be a generic way to read the DOM... if specific
problems come up that absolutely require it, they will be solved by
specific APIs, such as in elm-lang/window and elm-lang/dom.

On Thu, Dec 22, 2016 at 5:57 AM, Rex van der Spuy 
wrote:

>
>  Currently the solution seems to be 1) compute the bounding box manually
>> inside the update function whenever the selection  is modified, 2) keep
>> the bounding box data in the model and 3) use the bounding box from the
>> model when the update function performs other operations on the model (e.g.
>> detect if a click is inside).
>>
>
> That's how us game developers do it: all the geometry and position data is
> in the model. That data is then used to blindly draw the shapes in the
> view.
>
> --
> 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: Combining subscriptions under 0.18

[Nick H]

I think what you have in your first post is just fine. The
combineSubscriptions seems like overkill for a two-item list.

If it bugs you to have to pass the model to a bunch of different functions,
I'm curious how complicated the "viewSubscriptions" and "webSubscriptions"
functions are, and whether it would make more sense to pull them up into
your main module. In particular... the Elm "view" function is just the HTML
output, so putting Keyboard subscriptions in a module called "View" doesn't
seem necessary.

Of course I don't know anything else about your program, so this is just me
thinking out loud :)

On Tue, Dec 20, 2016 at 12:46 PM, Marshall handheld Flax <
m.droid.f...@gmail.com> wrote:

> Thinking about this a little more...should the Sub module just have
> something like the following?
>
> combineSubscriptions : List (m -> Sub msg) -> (m -> Sub msg)
> combineSubscriptions list model =
> Sub.batch (List.map ((|>) model) list)
>
> Thanks again!
>
> Marshall
>
>
> On Tuesday, December 20, 2016 at 1:39:43 PM UTC-5, Marshall handheld Flax
> wrote:
>>
>> My main program has two types of subscriptions: UI subscriptions (e.g. on
>> Keyboard.downs) defined in my View.elm, and Websocket.Listen subscriptions
>> defined in my State.elm.  But to batch them together, I need to create an
>> anonymous function to factor the model through.  Is this idiomatic or is
>> there a better way?
>>
>> Thank you!!!
>>
>> Marshall
>>
>> main =
>> Html.program
>> { init = State.init
>> , update = State.update
>> , view = View.root
>> , subscriptions = \model -> Sub.batch [ View.viewSubscriptions
>> model, State.webSubscriptions model ]
>> }
>>
>>
>> --
> 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] What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

[Nick H]

It hasn't been updated in 7 months, and it won't work with the latest
version of Elm, so I would reckon it is not.

On Sun, Dec 18, 2016 at 12:56 PM, Joel  wrote:

> I came across elm-webaudio... Is it up-to-snuff?
>
> https://github.com/trotha01/elm-webaudio
>
> Joel
>
>
> On Monday, December 12, 2016 at 12:00:00 PM UTC-6, Rex van der Spuy wrote:
>>
>>
>> For me, these things would be nice to have:
>>>   * WebAudio API
>>>
>>
>> That's a big one for me too because I use Elm exclusively for game and
>> "interactive multimedia" development.
>> At the moment I have to drop into ports for Audio - I'd love to it all in
>> Elm.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Nick H]

One thing you might want to also test is how your code deals with negative
numbers. In particular, negative numbers that round to zero!

On Fri, Dec 16, 2016 at 1:42 PM, Nick H <falling.maso...@gmail.com> wrote:

> There's nothing in the standard libraries (that I know of) to help with
> number formatting. There have been a few libraries written, but this
> <http://package.elm-lang.org/packages/krisajenkins/formatting/4.0.6/Formatting>
> is the only one I see that is up-to-date with 0.18.
>
> My personal guideline for when to publish something is just whenever I
> have something I want to use in multiple projects.  Your code solves a
> problem... I say publish it! You can always improve or expand it later if
> you want.
>
> The README for elm-package <https://github.com/elm-lang/elm-package>
> walks you through the steps of publishing something to the package manager.
> In my experience, the elm-package command is pretty user friendly... if you
> forget something like documentation, or bumping the version number, it will
> let you know. But if there is anything confusing, we'll be happy to clear
> it up :-)
>
> On Fri, Dec 16, 2016 at 12:53 PM, Eduardo Cuducos <cudu...@gmail.com>
> wrote:
>
>> Hi peeps,
>>
>> I needed to format some floats (eg. from 1234.56 to 1,234.56) and I
>> couldn't find a ready-made solution. I confess I haven't searcher much but
>> all I've found was this 3 years old topic
>> <https://groups.google.com/forum/#!topic/elm-discuss/mVPrEqWBGKw> from
>> this forum, and some 2 years old packages such as Aron's one
>> <https://github.com/avh4/elm-number-format>.
>>
>> This is the solution I wrote
>> <https://github.com/datasciencebr/jarbas/blob/b063c888d20778f421515e26341a268d480174a6/jarbas/frontend/elm/Format/Number.elm>
>> (not sure about the quality though, I'm still a beginner). There are some 
>> some
>> simple tests
>> <https://github.com/datasciencebr/jarbas/blob/b063c888d20778f421515e26341a268d480174a6/jarbas/frontend/tests/elm-tests/Tests.elm#L36-L51>
>>  too.
>>
>> The questions are:
>>
>>- Was it a waste of time writing it all fro scratch? What have I
>>missed?
>>- If it wasn't… does it worth it to (try to) publish to elm-packages?
>>If so, is there a recommended  tutorial, documentation about how to pack &
>>send it?
>>
>> Many many thanks,
>>
>> --
>> 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] Formating numbers

[Nick H]

There's nothing in the standard libraries (that I know of) to help with
number formatting. There have been a few libraries written, but this

is the only one I see that is up-to-date with 0.18.

My personal guideline for when to publish something is just whenever I have
something I want to use in multiple projects.  Your code solves a
problem... I say publish it! You can always improve or expand it later if
you want.

The README for elm-package  walks
you through the steps of publishing something to the package manager. In my
experience, the elm-package command is pretty user friendly... if you
forget something like documentation, or bumping the version number, it will
let you know. But if there is anything confusing, we'll be happy to clear
it up :-)

On Fri, Dec 16, 2016 at 12:53 PM, Eduardo Cuducos  wrote:

> Hi peeps,
>
> I needed to format some floats (eg. from 1234.56 to 1,234.56) and I
> couldn't find a ready-made solution. I confess I haven't searcher much but
> all I've found was this 3 years old topic
>  from
> this forum, and some 2 years old packages such as Aron's one
> .
>
> This is the solution I wrote
> 
> (not sure about the quality though, I'm still a beginner). There are some some
> simple tests
> 
>  too.
>
> The questions are:
>
>- Was it a waste of time writing it all fro scratch? What have I
>missed?
>- If it wasn't… does it worth it to (try to) publish to elm-packages?
>If so, is there a recommended  tutorial, documentation about how to pack &
>send it?
>
> Many many thanks,
>
> --
> 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: Why is "port" forbidden as field name inside record?

[Nick H]

Ah, I guess you would run into typing issues if you tried to use a Dict...
that's just my knee-jerk response when people ask about doing things with
records that you can't do with records :-|


On Thu, Dec 15, 2016 at 4:06 PM, Nick H <falling.maso...@gmail.com> wrote:

> If you want something that can hold arbitrary string keys like a
> JavaScript object, you can use a Dict.
>
> Making keywords context-sensitive would be a language designer's
> nightmare. I don't think most languages allow this. Which contexts would
> the keywords be reserved, and which would they not be? Even if you can
> specify the special rules consistently, your compiler will become more
> complicated, more prone to bugs. And if you get everything working, the
> only benefit you've gained is fixing this one slightly inconvenient use
> case.
>
>
> On Thu, Dec 15, 2016 at 2:15 PM, Paul Dijou <paul.di...@gmail.com> wrote:
>
>> Both solutions are valid (I'm actually using both depending on the
>> situation) but my main question is why is there such a limitation? Reserved
>> keywords could (should?) depend on the context. You cannot define a real
>> port inside a record, you just want a string to name a property.
>>
>> For example, in JavaScript, you can create an object with any property
>> you want, including reserved keywords, because, at the end of the day, it's
>> just string names. Some old browsers required to wrap the key inside quotes
>> so I would be fine with writing { "port" = 80 } in Elm if that would solve
>> the problem.
>>
>> Le jeudi 15 décembre 2016 16:20:25 UTC+1, Paul Dijou a écrit :
>>>
>>> Hi,
>>>
>>> I understand that "port" is a reserved keyword when writing Elm code but
>>> is there a reason to fail compilation when used as the name of a record
>>> field? It's a bummer when sending records through a port (a real one) and
>>> the JavaScript is expecting the property "port" (in the record).
>>>
>>> Thanks
>>>
>> --
>> 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: Why is "port" forbidden as field name inside record?

[Nick H]

If you want something that can hold arbitrary string keys like a JavaScript
object, you can use a Dict.

Making keywords context-sensitive would be a language designer's nightmare.
I don't think most languages allow this. Which contexts would the keywords
be reserved, and which would they not be? Even if you can specify the
special rules consistently, your compiler will become more complicated,
more prone to bugs. And if you get everything working, the only benefit
you've gained is fixing this one slightly inconvenient use case.


On Thu, Dec 15, 2016 at 2:15 PM, Paul Dijou  wrote:

> Both solutions are valid (I'm actually using both depending on the
> situation) but my main question is why is there such a limitation? Reserved
> keywords could (should?) depend on the context. You cannot define a real
> port inside a record, you just want a string to name a property.
>
> For example, in JavaScript, you can create an object with any property you
> want, including reserved keywords, because, at the end of the day, it's
> just string names. Some old browsers required to wrap the key inside quotes
> so I would be fine with writing { "port" = 80 } in Elm if that would solve
> the problem.
>
> Le jeudi 15 décembre 2016 16:20:25 UTC+1, Paul Dijou a écrit :
>>
>> Hi,
>>
>> I understand that "port" is a reserved keyword when writing Elm code but
>> is there a reason to fail compilation when used as the name of a record
>> field? It's a bummer when sending records through a port (a real one) and
>> the JavaScript is expecting the property "port" (in the record).
>>
>> Thanks
>>
> --
> 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] Why is "port" forbidden as field name inside record?

[Nick H]

Think about how you would construct such a record...

myRecord =
  { port = ...
  }

That's a reserved keyword appearing in an incorrect place. This won't work
for any Elm keyword!

I can't think of a way to solve your problem besides changing the JS that
calls the port. In the Elm HTML library, when there is a conflict between
keywords and function names, they use an underscore. For example, the
function to create a "type" DOM attribute is "type_". Maybe you do
something similar?

On Thu, Dec 15, 2016 at 2:51 AM, Paul Dijou  wrote:

> Hi,
>
> I understand that "port" is a reserved keyword when writing Elm code but
> is there a reason to fail compilation when used as the name of a record
> field? It's a bummer when sending records through a port (a real one) and
> the JavaScript is expecting the property "port" (in the record).
>
> Thanks
>
> --
> 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] “TypeError: domNode is undefined” and other errors with Elm and 3rd party JS libraries

[Nick H]

I think the way to work cleanly with a DOM-rewriting library is to decide
which parts of your page you want Elm to control and which parts you want
JS to control.

You can use Elm.Main.embed to restrict your Elm program to only controlling
a part of the page. Or you could use Platform.program to run Elm
headlessly, with no view at all. Either way, you can use ports to
communicate with external JavaScript, which can in turn control the non-Elm
DOM.

There has also been some talk on the list about Polymer and Web
Components... maybe you can find a more satisfactory solution with those
tools. But I don't know anything about that.

On Mon, Dec 12, 2016 at 3:19 PM,  wrote:

> I posted this over on Stack Overflow
> ,
> but thought I would ask here too.
>
> I have been trying to use Elm applications to work with a handful of "UI
> Widget" type libraries. In particular I have been working with highlight.js
> and CodeMirror.
>
> This  is a set of
> pared down code snippets from the project. The "Simple" example is just the
> raw elm app with no 3rd party libraries to show the expected result of the
> application. "Highligh JS" is a version showing errors working with the
> highlight.js library. Finally "CodeMirror" shows issues working with the
> CodeMirror library.
>
> The source code for the above examples can be found here
> . The pertinent files are
> /src/*.elm and docs/*.html
>
> The CodeMirror example gives the error from the title while the Highlight
> JS example results in a "corrupted" DOM.
>
> Many 3rd party JS libraries modify the DOM. How do you work with those
> libraries cleanly in Elm?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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-lang/Navigation with hash and query string

[Nick H]

Maybe Bogdanp/elm-querystring  could be helpful?

On Sun, Dec 11, 2016 at 2:23 PM, Charlie Koster  wrote:

> I don't disagree with anything your wrote there, but I still have this
> problem to deal with now. The path of least resistance happens to also be
> the path that uses query strings that are technically correct (nevermind
> about technically correct URLs).
>
> If a library comes along and makes parsing hashes that contain semantic
> query strings easy, then I'll consider using that library. At the moment
> the solution I have now contains a very small workaround and has unblocked
> me from being able to use query string parameters.
>
> --
> 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: Documentation storage : IN or OUT ?

[Nick H]

Yes, I'm curious what exactly your concerns are with the current
documentation system. Seems like removing all documentation from the source
code would just make it harder to notice mistakes.

On Sun, Dec 11, 2016 at 9:52 AM, Max Goldstein 
wrote:

> You're going to be more specific about what concerns you about the current
> format. The Elm community likes to work together towards solutions, not get
> into debates. To that end, the tooling and conventions create a
> multi-layered system of documentation:
>
> As in any language, *code comments* are used to document *individual
> lines of code* whose meaning is not obvious.
>
> *Declaration comments* with the {-| prefix are used to document *public
> values and types*. (A "value" is a function or a definition.) These work
> in concert with the type annotation. Because the comment and annotation are
> displayed together in the rendered docs, they are written together in code.
>
> The *module comment* at the top of the *file/module* gives information
> about the module: why it exists as a logical grouping of code. This comment
> also includes @docs declarations to define the order that public functions
> are documented. They are usually separated by headers (it's just markdown)
> and each section may also include a comment. Elm encourages library authors
> to use these features so that their module docs are sensible when read top
> to bottom. There is also a way to preview docs
>  prior to publication.
>
> The *README* for each *package* includes information about what the
> package does, how to start using it, and what to look for in the more
> detailed module docs. They may also include instructions for filing bugs or
> upgrading from previous versions of the package or language.
>
> Finally *guides and blog posts* will go into depth and examples on how to
> accomplish a* useful unit of work*, such as JSON decoding or refactoring
> a union type. These may focus on a module from the core library, one or
> more third-party libraries working together, or a language feature.
>
> You will notice that READMEs and guides are not source code files, but are
> valuable parts of the hierarchical documentation system.
>
> --
> 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-lang/Navigation with hash and query string

[Nick H]

I would call this not a bug, since it conforms to the URL standard
. in your second example, ?a=b=d
is not a query string, but a part of the fragment string.

This is just one of several ways that URL syntax can lead you down a dark
alley and steal your wallet.

On Fri, Dec 9, 2016 at 5:53 PM, Charlie Koster  wrote:

> I submitted an issue
>  to
> evancz/url-parser but it ended up being human error on my part. However,
> I'm making this post because of my closing comment
> 
> on that issue.
>
> To summarize, I'm using `UrlParser.parseHash` along with `Url.stringParam`
> and I can't get that parser to work. After some digging I noticed that
> elm-lang/Navigation is providing me a `Location` that doesn't have a search
> attribute. Here are two examples.
>
> Navigate to http://localhost:8080*/test?a=b=d*
> Logging the Location gives me:
> { href = "http://localhost:8080/test?a=b=d;, host = "localhost:8080",
> hostname = "localhost", protocol = "http:", origin = "
> http://localhost:8080;, port_ = "8080", pathname = "/test", search =
> "?a=b=d", hash = "", username = , password = <
> internal structure> }
>
> Notice the search attribute as my query string.
>
> Navigate to http://localhost:8080*/#test?a=b=d*
> Logging the Location gives me:
> { href = "http://localhost:8080/#test?a=b=d;, host = "localhost:8080",
> hostname = "localhost", protocol = "http:", origin = "
> http://localhost:8080;, port_ = "8080", pathname = "/", search = "", hash
> = "#test?a=b=d", username = , password =  structure> }
>
> Notice the search attribute is an empty string and the hash attribute
> contains both the hash and the query string
>
> My question to the community.. Is this a bug with elm-lang/Navigation,
> evancz/url-parser, or not a bug at all because that's how hashes work and I
> have to deal with this manually?
>
> --
> 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: fold function argument order

[Nick H]

expection to this exceptation.

On Fri, Dec 9, 2016 at 2:17 PM, Nick H <falling.maso...@gmail.com> wrote:

> I would disagree with "not expected in general." In general -- when a and
> b are different types -- Elm's API design guidelines should set you up to
> always expect a -> b -> b and never b -> a -> b. If the definition of foldl
> were changed to take the latter, it would be the only exception to this
> expectation.
>
> On Fri, Dec 9, 2016 at 7:03 AM, Kasey Speakman <kjspeak...@gmail.com>
> wrote:
>
>> Ok, correction
>>
>> List.foldl (-) 0 [1, 2, 3]
>> -- returns 2
>> -- expands to 3 - (2 - (1 - 0)) = 2
>>
>> During my testing last night, I had a typo (foldr instead of foldl) when
>> I was testing the expansions. That was the center-building behavior.
>>
>> Using the form a -> b -> b is right-building regardless of the order the
>> list is traversed. Traversing from head to tail is equivalent to reversing
>> the list and building right. This is obviously broken for left-associative
>> only operations and not expected in general.
>>
>> On Friday, December 9, 2016 at 8:44:25 AM UTC-6, Kasey Speakman wrote:
>>>
>>> Sorry, that last bit was an example of what happens in Elm when folding
>>> with string concat (++). That's unexpected behavior from a left fold.
>>>
>>> List.foldl (++) "" ["The ", "quick ", "brown "]  -- returns "brown quick
>>> The "
>>>
>>> On Friday, December 9, 2016 at 8:26:17 AM UTC-6, Kasey Speakman wrote:
>>>>
>>>> You're confusing pipe's syntax and infix. Pipe is defined like this:
>>>>
>>>> (|>) x f = f x
>>>>
>>>> And used like this
>>>>
>>>> x |> f == f x
>>>>
>>>> So pipe has an inherent flip because it is used to chain otherwise
>>>> right-building statements.
>>>>
>>>> e.g.
>>>>
>>>> List.sum (List.filter isOdd [1, 2, 3])
>>>>
>>>> vs
>>>>
>>>> [1, 2, 3]
>>>> |> List.filter isOdd
>>>> |> List.sum
>>>>
>>>> Pipe is inherently right-building, so operations like subtract or
>>>> string concatenation are not suitable for it since they are only left
>>>> associative.
>>>>
>>>> List.foldl (++) "" ["The ", "quick ", "brown "]  -- returns "brown
>>>> quick The "
>>>>
>>>> On Friday, December 9, 2016 at 1:05:56 AM UTC-6, Aaron VonderHaar wrote:
>>>>>
>>>>> What's confusing here is how currying works with infix operators.
>>>>> It's idiomatic in Elm to have your accumulator be the last argument, and,
>>>>> for instance, if you were writing your own data type, you would want to
>>>>> write your functions so that they can be chained together easily:
>>>>>
>>>>> myMatrix
>>>>> |> scale 2
>>>>> |> subtract 5
>>>>> |> subtractMatrix myOtherMatrix
>>>>> |> normalize
>>>>>
>>>>>
>>>>> But as an infix operator (-) is not able to follow that convention;
>>>>>
>>>>> 5
>>>>> |> (-) 3
>>>>> |> (-) 1
>>>>>
>>>>> is confusingly equivalent to `(1 - (3 - 5))` rather than to `5 - 3 - 1`
>>>>>
>>>>>
>>>>> If you had a function `subtract` such that
>>>>>
>>>>> 5 |> subtract 3 |> subtract 1 == (5 - 3 - 1)
>>>>>
>>>>> then you could use that function with fold as you intend
>>>>>
>>>>> List.foldl subtract 0 [1, 2, 3, 4]  ==  -10
>>>>>
>>>>> You can achieve the same result with
>>>>>
>>>>> List.foldl (flip (-)) 0 [1, 2, 3, 4]  ==  -10
>>>>>
>>>>>
>>>>> Another way to put it is, in Elm, folds expand in the following way:
>>>>>
>>>>> List.foldl f x [b, c, d]  ==  x |> f b |> f c |> f d
>>>>> List.foldr f x [b, c, d]  ==  f b <| f c <| f d <| x
>>>>>
>>>>>
>>>>> On Thu, Dec 8, 2016 at 7:50 PM, Kasey Speakman <kjspe...@gmail.com>
>>>>> wrote:
>>>>>
>&g

Re: [elm-discuss] Re: fold function argument order

[Nick H]

I would disagree with "not expected in general." In general -- when a and b
are different types -- Elm's API design guidelines should set you up to
always expect a -> b -> b and never b -> a -> b. If the definition of foldl
were changed to take the latter, it would be the only exception to this
expectation.

On Fri, Dec 9, 2016 at 7:03 AM, Kasey Speakman  wrote:

> Ok, correction
>
> List.foldl (-) 0 [1, 2, 3]
> -- returns 2
> -- expands to 3 - (2 - (1 - 0)) = 2
>
> During my testing last night, I had a typo (foldr instead of foldl) when I
> was testing the expansions. That was the center-building behavior.
>
> Using the form a -> b -> b is right-building regardless of the order the
> list is traversed. Traversing from head to tail is equivalent to reversing
> the list and building right. This is obviously broken for left-associative
> only operations and not expected in general.
>
> On Friday, December 9, 2016 at 8:44:25 AM UTC-6, Kasey Speakman wrote:
>>
>> Sorry, that last bit was an example of what happens in Elm when folding
>> with string concat (++). That's unexpected behavior from a left fold.
>>
>> List.foldl (++) "" ["The ", "quick ", "brown "]  -- returns "brown quick
>> The "
>>
>> On Friday, December 9, 2016 at 8:26:17 AM UTC-6, Kasey Speakman wrote:
>>>
>>> You're confusing pipe's syntax and infix. Pipe is defined like this:
>>>
>>> (|>) x f = f x
>>>
>>> And used like this
>>>
>>> x |> f == f x
>>>
>>> So pipe has an inherent flip because it is used to chain otherwise
>>> right-building statements.
>>>
>>> e.g.
>>>
>>> List.sum (List.filter isOdd [1, 2, 3])
>>>
>>> vs
>>>
>>> [1, 2, 3]
>>> |> List.filter isOdd
>>> |> List.sum
>>>
>>> Pipe is inherently right-building, so operations like subtract or string
>>> concatenation are not suitable for it since they are only left associative.
>>>
>>> List.foldl (++) "" ["The ", "quick ", "brown "]  -- returns "brown quick
>>> The "
>>>
>>> On Friday, December 9, 2016 at 1:05:56 AM UTC-6, Aaron VonderHaar wrote:

 What's confusing here is how currying works with infix operators.  It's
 idiomatic in Elm to have your accumulator be the last argument, and, for
 instance, if you were writing your own data type, you would want to write
 your functions so that they can be chained together easily:

 myMatrix
 |> scale 2
 |> subtract 5
 |> subtractMatrix myOtherMatrix
 |> normalize


 But as an infix operator (-) is not able to follow that convention;

 5
 |> (-) 3
 |> (-) 1

 is confusingly equivalent to `(1 - (3 - 5))` rather than to `5 - 3 - 1`


 If you had a function `subtract` such that

 5 |> subtract 3 |> subtract 1 == (5 - 3 - 1)

 then you could use that function with fold as you intend

 List.foldl subtract 0 [1, 2, 3, 4]  ==  -10

 You can achieve the same result with

 List.foldl (flip (-)) 0 [1, 2, 3, 4]  ==  -10


 Another way to put it is, in Elm, folds expand in the following way:

 List.foldl f x [b, c, d]  ==  x |> f b |> f c |> f d
 List.foldr f x [b, c, d]  ==  f b <| f c <| f d <| x


 On Thu, Dec 8, 2016 at 7:50 PM, Kasey Speakman 
 wrote:

> (deleted and corrected original post with proper expansion of Elm's
> foldl)
>
> I know this is a really old thread, but I ran into this precise
> question and thought I would add a perspective.
>
> The form a -> b -> b is not left-building, regardless of the direction
> you are traversing the list.
>
> An example: Starting from zero, subtract the numbers 1, 2, and 3. The
> expected answer is -6.
>
> List.foldl (-) 0 [1, 2, 3]
> -> returns -6 in Haskell (well, actually tested in F# which uses same
> order as Haskell)
> expands to: ((0 - 1) - 2) - 3 = -6
> -> returns 2 in Elm
> expands to: 3 - ((1 - 0) - 2)
>
> Elm's expansion is wonky for this. It appears to be center-building:
> List.foldl (-) 0 [1] -- returns 1, expands 1 - 0
> List.foldl (-) 0 [1, 2] -- returns -1, expands (1 - 0) - 2
> List.foldl (-) 0 [1, 2, 3] -- returns 2, expands 3 - ((1 - 0) - 2)
> List.foldl (-) 0 [1, 2, 3, 4] -- returns -2, expands (3 - ((1 - 0)
> - 2)) - 4
>
> When a and b are the same type it will only return the correct answer
> if the fold operation is also commutative or if flip is used to
> correct the ordering. When a and b are not the same type, the compiler 
> will
> provide an error for wrong ordering of course.
>
> I started out on the side that a -> b -> b was correct as that feels
> like proper "reduction" or chainable syntax. But after exploring it, it is
> clearly not left-building. Makes sense when you consider this form is used
> with pipe to convert 

Re: [elm-discuss] `Case of` branches grouping

[Nick H]

>
> I generally don't like using equality test on union types because that
> makes your code more prone to errors - later on you might decide to add /
> remove some types from union type.


I'm on board with that. I try to avoid catch-all underscores in case
statements for the same reason. But if your case statement is really as
redundant as the ones in your examples, I think these are both options
worth considering (as is refactoring -- as Wouter suggested -- which is
often the best decision).

How is this handled in other languages like OCaml or Haskell?


Haskell does not allow this either. (At least it didn't 5 years ago, when this
proposal <https://wiki.haskell.org/MultiCase> was made). The difference is,
the formatting conventions for Haskell are much more compact. But in Elm,
its perfectly valid to compress your case statement into this:

case someTypeValue of
A -> stuff1
B _ -> stuff2
C _ _ -> stuff2
D _ _ _ -> stuff2

On Fri, Dec 9, 2016 at 8:08 AM, Petr Huřťák <petr.hur...@gmail.com> wrote:

> I generally don't like using equality test on union types because that
> makes your code more prone to errors - later on you might decide to add /
> remove some types from union type.
>
> On Friday, December 9, 2016 at 4:57:48 PM UTC+1, Nick H wrote:
>>
>> You can also do equality tests on type values, which means in your first
>> two cases you can use an if statement.
>>
>> if someValue == A then
>>   stuff1
>> else
>>   stuff2
>>
>> This only works if your type values aren't storing any data.
>>
>> On Fri, Dec 9, 2016 at 7:25 AM, Petr Huřťák <petr@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I would like hear some discussion on grouping of branches in `case of`
>>> statement . Currently it is not possible to use one branch for multiple
>>> conditions.
>>>
>>> Something along these lines:
>>>
>>> case someTypeValue of
>>> A ->
>>> -- code
>>>
>>> B ->
>>> C ->
>>> D ->
>>> -- different code
>>>
>>>
>>> Current alternative is this
>>>
>>> case someTypeValue of
>>> let
>>> stuff2 =
>>> -- code
>>> in
>>> A ->
>>> -- different code
>>>
>>> B ->
>>> stuff2
>>>
>>> C ->
>>> stuff2
>>>
>>> D ->
>>> stuff2
>>>
>>>
>>> Which is unnecessarily verbose and harder to read.
>>>
>>> One question is how this would work when there in cases where matched
>>> patterns have some values attached to them
>>>
>>> case someTypeValue of
>>> A ->
>>> -- stuff1
>>>
>>>
>>> B _ ->
>>> C _ _ ->
>>> D _ _ _ ->
>>> -- stuff2
>>>
>>> How is this handled in other languages like OCaml or Haskell?
>>>
>>> NOTE: moved from https://groups.google.com/forum/#!topic/elm-dev/DtUT2ie
>>> YTDo
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: how to make a port compnent

[Nick H]

Forgot to say... that's a really cool idea! :-)


On Fri, Dec 9, 2016 at 10:25 AM, Nick H <falling.maso...@gmail.com> wrote:

> I would love for somebody to disagree with me, but I really don't think
> Elm is a good choice for this project.
>
> Elm does not have any audio support yet, so that would all be done through
> ports. You've said the code editor will not be in Elm... and it sounds like
> that is going to be a major part of the UI. There might be a way to wire it
> all up with ports and web-components, but I think trying to get this all to
> work will be an unhappy and frustrating experience.
>
>
> On Fri, Dec 9, 2016 at 9:50 AM, أحمد حبنكة <ahmad13932...@gmail.com>
> wrote:
>
>> well the application is going to be like this : the user will create
>> tutorials like this : user starts recording audio, while speaking he/she
>> enters code in the code editor , when user ends recording the course shall
>> be created.
>>
>> Now someone will watch the course, when the course is started the audio
>> is played and text shall be entered in the code editor by the program
>> synchronizing with the audio, the watcher will be able to pause the audio
>> and enter his/her own code and run it.
>>
>> you can watch this kind of behavior at www.khanacademy.com :) .
>>
>> I predict a component for the audio shall exist and the main component
>> will synchronize between the code editor and the audio.
>>
>> بتاريخ الأربعاء، 7 ديسمبر، 2016 5:13:56 م UTC+2، كتب أحمد حبنكة:
>>
>>> I'm going to build a project in which I need to build a code editor
>>> component, Right now I plan to use microsoft's monaco editor, I want to
>>> wrap as an Elm component using port.
>>>
>>> I know from experience that the view has to be managed in JS side , what
>>> I don't know is how to make this as a component that other components can
>>> build on, how do I write a Component that has Html code alongside JS ?
>>>
>>>
>>> --
>> 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: how to make a port compnent

[Nick H]

I would love for somebody to disagree with me, but I really don't think Elm
is a good choice for this project.

Elm does not have any audio support yet, so that would all be done through
ports. You've said the code editor will not be in Elm... and it sounds like
that is going to be a major part of the UI. There might be a way to wire it
all up with ports and web-components, but I think trying to get this all to
work will be an unhappy and frustrating experience.


On Fri, Dec 9, 2016 at 9:50 AM, أحمد حبنكة  wrote:

> well the application is going to be like this : the user will create
> tutorials like this : user starts recording audio, while speaking he/she
> enters code in the code editor , when user ends recording the course shall
> be created.
>
> Now someone will watch the course, when the course is started the audio is
> played and text shall be entered in the code editor by the program
> synchronizing with the audio, the watcher will be able to pause the audio
> and enter his/her own code and run it.
>
> you can watch this kind of behavior at www.khanacademy.com :) .
>
> I predict a component for the audio shall exist and the main component
> will synchronize between the code editor and the audio.
>
> بتاريخ الأربعاء، 7 ديسمبر، 2016 5:13:56 م UTC+2، كتب أحمد حبنكة:
>
>> I'm going to build a project in which I need to build a code editor
>> component, Right now I plan to use microsoft's monaco editor, I want to
>> wrap as an Elm component using port.
>>
>> I know from experience that the view has to be managed in JS side , what
>> I don't know is how to make this as a component that other components can
>> build on, how do I write a Component that has Html code alongside JS ?
>>
>>
>> --
> 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] Why latest versions of elm-compiler not available on Hackage?

[Nick H]

You need to build from source.

The elm compiler moved from hackage to npm. It was never maintained in both
places at once.

On Fri, Dec 9, 2016 at 1:51 AM, Jan Hrček  wrote:

> Hello,
>
> is there a distribution of latest (0.18) elm-compiler available as haskell
> library? I checked hackage
>  but that only has
> version 0.15. Or do I need to build it from sources?
> I'd like to make use of the elm parsing capabilities of the library to use
> in my project..
> Or is there some reason why Evan is no longer publishing latest versions
> of the package on hackage?
>
> --
> 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: how to make a port compnent

[Nick H]

I am pretty sure it is impossible to "wrap" a JS component with Elm,
especially if it is as complicated as a code editor. This thing is going to
have loads of code that already manages rendering and event handling. Its
not going to play nicely with the VDOM.

What is the rest of your program doing? Are there a subset of events from
the code editor that you are interested in capturing?

On Fri, Dec 9, 2016 at 3:28 AM, أحمد حبنكة  wrote:

> Is there a solution to my problem or are native modules my only solution ?
>
>
> بتاريخ الأربعاء، 7 ديسمبر، 2016 5:13:56 م UTC+2، كتب أحمد حبنكة:
>>
>> I'm going to build a project in which I need to build a code editor
>> component, Right now I plan to use microsoft's monaco editor, I want to
>> wrap as an Elm component using port.
>>
>> I know from experience that the view has to be managed in JS side , what
>> I don't know is how to make this as a component that other components can
>> build on, how do I write a Component that has Html code alongside JS ?
>>
>>
>> --
> 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] Using Elm with JSON when you do not know the names and types of the properties at compile time

[Nick H]

What sorts of widgets are we talking about?

If you know what sorts of widgets you are displaying, then you should also
know what types of data they need. If this is true, then you could decode
your JSON to simple "Dict String Json.Value". Then your widgets will have
more fine-grained decoders connected to them. You can pass them the values
for properties x, y, and z from the Dict, and the widgets will try to
decode further.

On Tue, Dec 6, 2016 at 11:50 AM, Hans Rune Bergheim 
wrote:

> Hi!
>
>
> I'd like to create a simple dashboard in Elm, that displays some graphs
> and numbers from json-data. The dashboard should be fully configurable,
> meaning that the users should have a config-file saying they would like to
> get data from service foo, and want to display widget a, b and c, using
> properties x,y, and z of the data. The names and contents of the properties
> may be any name and type, as the data source could be any webservice.
>
>
>
> I've been trying to wrap my head around how to do this in elm, but I'm
> coming up short. Is Elm a bad fit for this type of application, or am I
> just missing a clever way of doing it? I've seen multiple examples of
> dynamic JSON (like this: https://www.brianthicks.com/
> post/2016/10/03/decoding-json-with-dynamic-keys/) , but they all know
> what kind(s) of object(s) that's being decoded at compile time, which is
> not the case here.
>
>
>
> This is fairly straightforward to do in JavaScript, but I'm trying to get
> as much Elm-time as I can these days :-)
>
>
> PS: Coming from JS and .Net-land, I'm having a pretty hard time getting to
> know Elm, but a big shoutout to Richard Feldman and his Elm In Action-book!
> I am really enjoying each chapter so far :) Highly recommended!
>
>
> Hans
>
> --
> 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] towards enact-like coding? ideas for future directions

[Nick H]

Think "12 Monkeys" instead of "Back to the Future"!

On Mon, Dec 5, 2016 at 12:57 PM, Duane Johnson <duane.john...@gmail.com>
wrote:

> No traveling!? I think this should be called the Archeological Debugger. :)
>
> On Mon, Dec 5, 2016 at 1:35 PM, Nick H <falling.maso...@gmail.com> wrote:
>
>> Thanks for sharing your thoughts!
>>
>> The "time split" you describe actually used to be a feature of the time
>> travel debugger. But judging from Evan's comments on elm-dev, it doesn't
>> sound like it is going to come back. For example:
>>
>> (Source
>> <https://groups.google.com/forum/#%21searchin/elm-dev/status$20update%7Csort:relevance/elm-dev/5Tm5_x7AfyQ/a5Kj8TNeCAAJ>
>> )
>>
>>> In the old debugger, you could go back in time, and then choose a
>>> *different* future.
>>>
>>> This works *within* Elm, but as soon as you are interacting with a
>>> database or JS or a server that *doesn't* know about time travel, you
>>> are can introduce all sorts of subtle bugs. It's like in the time-travel
>>> movies. It doesn't really work if you think about it.
>>>
>>> So I think the new version well let you go back, but only let you
>>> "resume". Basically, you can travel to the past, but you can't change it.
>>> You are just an observer, and when you are done looking around, you come
>>> back to the present.
>>>
>>
>>
>>
>> On Mon, Dec 5, 2016 at 5:49 AM, Ruud Steltenpool <goo...@steltenpower.com
>> > wrote:
>>
>>> Hello all,
>>>
>>> What I tweeted and was unsurprisingly not clear to @rtfeldman (of Elm
>>> fame):
>>>
>>> interactiveProgramming
>>> +eventRecorder
>>> +timeTravel Debugger
>>> +ifThen timeSplit
>>> +refactorTool finding similarities
>>> =enactLikeCoding? @rtfeldman
>>>
>>> Let me try in slightly longer form:
>>> (me = doesn't code much at all, thinks a lot about
>>> data/structures/working together/design)
>>>
>>> Hopefully there's something in there for you smart routined
>>> coders/designers)
>>>
>>> Interactive Programming to me means: your code and variables stay in
>>> memory even when the end of the code is reached. When you add something
>>> afterwards, the code will continue. REPL is a flavour. I could imagine
>>> also being able to PAUSE, CHANGE code somewhere in the middle, RESUME.
>>>
>>> Event Recorder: all (user?) events are logged
>>>
>>> Time Travel Debugger: You can time travel through state, see what
>>> variables you had with what values at any point in time
>>>
>>> If-Then Time-Split, let's just call it time split, or parallel universe:
>>> Flow through code is not just 'one straight line through time', but the
>>> route is dependent on values through If-Then, Case-Switch, etc.  So if
>>> you travel back in time to a point before such a decision and change a
>>> value and see how the code goes from there you will not only get
>>> different values, it will even give a new flow through your code. Maybe
>>> a Time Travel Debugger already support keeping (in parallel) the part in
>>> future you're changing aka doing differently in parallel, if not, I
>>> think it should and the next bit hopefully explains why
>>>
>>> refactor Tool finding similarities: what if your coding environment
>>> facilitated a more experimental style of coding, learning and improving
>>> while doing probably doing some coding along the way that is not nearly
>>> the quality you need as an end result. When the tool shows you
>>> similarities as you type, it helps you structure your code. Then it's
>>> less bad to repeat yourself, cause the tool helps you to
>>> DontRepeatYourself in the 'final' version.
>>>
>>> Maybe with all that in place maybe you can get to something I call
>>> enact-like Coding. It's sort of a mix of getting the specs right,
>>> prototyping/implementing and user testing: A potential user interacts
>>> with your 'GUI canvas' and you code, while talking about what it should
>>> do. While you log his/her actions (and maybe record the audio/video of
>>> your meeting together) and build a prototype that can be very simple as
>>> you're right there (in reality or over appear.in) to explain it. After
>>> the meeting you and your colleagues turn the prototype into an alpha
>>> version and then have another meeting with

Re: [elm-discuss] towards enact-like coding? ideas for future directions

[Nick H]

Thanks for sharing your thoughts!

The "time split" you describe actually used to be a feature of the time
travel debugger. But judging from Evan's comments on elm-dev, it doesn't
sound like it is going to come back. For example:

(Source

)

> In the old debugger, you could go back in time, and then choose a
> *different* future.
>
> This works *within* Elm, but as soon as you are interacting with a
> database or JS or a server that *doesn't* know about time travel, you are
> can introduce all sorts of subtle bugs. It's like in the time-travel
> movies. It doesn't really work if you think about it.
>
> So I think the new version well let you go back, but only let you
> "resume". Basically, you can travel to the past, but you can't change it.
> You are just an observer, and when you are done looking around, you come
> back to the present.
>



On Mon, Dec 5, 2016 at 5:49 AM, Ruud Steltenpool 
wrote:

> Hello all,
>
> What I tweeted and was unsurprisingly not clear to @rtfeldman (of Elm
> fame):
>
> interactiveProgramming
> +eventRecorder
> +timeTravel Debugger
> +ifThen timeSplit
> +refactorTool finding similarities
> =enactLikeCoding? @rtfeldman
>
> Let me try in slightly longer form:
> (me = doesn't code much at all, thinks a lot about
> data/structures/working together/design)
>
> Hopefully there's something in there for you smart routined
> coders/designers)
>
> Interactive Programming to me means: your code and variables stay in
> memory even when the end of the code is reached. When you add something
> afterwards, the code will continue. REPL is a flavour. I could imagine
> also being able to PAUSE, CHANGE code somewhere in the middle, RESUME.
>
> Event Recorder: all (user?) events are logged
>
> Time Travel Debugger: You can time travel through state, see what
> variables you had with what values at any point in time
>
> If-Then Time-Split, let's just call it time split, or parallel universe:
> Flow through code is not just 'one straight line through time', but the
> route is dependent on values through If-Then, Case-Switch, etc.  So if
> you travel back in time to a point before such a decision and change a
> value and see how the code goes from there you will not only get
> different values, it will even give a new flow through your code. Maybe
> a Time Travel Debugger already support keeping (in parallel) the part in
> future you're changing aka doing differently in parallel, if not, I
> think it should and the next bit hopefully explains why
>
> refactor Tool finding similarities: what if your coding environment
> facilitated a more experimental style of coding, learning and improving
> while doing probably doing some coding along the way that is not nearly
> the quality you need as an end result. When the tool shows you
> similarities as you type, it helps you structure your code. Then it's
> less bad to repeat yourself, cause the tool helps you to
> DontRepeatYourself in the 'final' version.
>
> Maybe with all that in place maybe you can get to something I call
> enact-like Coding. It's sort of a mix of getting the specs right,
> prototyping/implementing and user testing: A potential user interacts
> with your 'GUI canvas' and you code, while talking about what it should
> do. While you log his/her actions (and maybe record the audio/video of
> your meeting together) and build a prototype that can be very simple as
> you're right there (in reality or over appear.in) to explain it. After
> the meeting you and your colleagues turn the prototype into an alpha
> version and then have another meeting with the/a user. As certainly for
> the first meeting you probably need the person in charge of the money
> describing your task, this will force him/her in the role of the user,
> thereby making him more open to proper usability/user-friendliness.
>
> Also makes me think of the only bit of 'start-to-end pair programming' I
> did almost 25 years ago:
> I was typing the algorithm, next to me someone interrogating me about
> what things meant and what was going on and I told him 'shortcuts' I was
> taking to later fix so I could keep my higher-level train of thought. He
> typed that all on his completely unrelated system, so it took more
> manual labor to combine than it would take nowadays
>
> bonus: the system shouldn't care too much about where you change your
> system, change CSS, DOM-state, HTML, javascript, some other file/state
>
> It feels like there are some similarities with git, build on that where
> possible
>
> Hoping this wasn't a complete waste of your valuable time,
>
> Kind regards,
>
> Ruud
>
> PS: Hoping to finally code something in Elm during Christmas break
>
> --
> 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
> 

Re: [elm-discuss] Re: Maximum call stack size exceeded while parsing generated code

[Nick H]

Glad you found a solution!

On Sun, Dec 4, 2016 at 8:43 PM, Iain Gray  wrote:

> It turned out to be an instance of this
> . I have a list of
> time-zones that I use for a drop-down list, which was big enough to cause
> the stack overflow. As the issue-poster mentioned, I was able to fix it by
> splitting my list into multiple pieces and List.concat'ing them together.
>
> Thanks for the suggestions everyone!
>
>
> On Saturday, December 3, 2016 at 7:40:41 PM UTC-6, Iain Gray wrote:
>>
>> I'm having a strange problem and was wondering if anyone had any
>> suggestions on how to pinpoint what is causing it.
>>
>> I have an Elm app that compiles in 0.18, but the generated javascript
>> code is throwing a "RangeError: Maximum call stack size exceeded" as soon
>> as the javascript file is loaded into Chrome. I do not have this problem in
>> Firefox, but I can reproduce it in nodejs/esprima as follows:
>>
>> var esprima = require('esprima');
>> var fs = require('fs');
>> var filePath = path.join('.', 'elm.js');
>>
>> fs.readFile(filePath, 'utf8', function(err, data) {
>>   console.log(esprima.parse(data));
>> });
>>
>> RangeError: Maximum call stack size exceeded
>> at isKeyword (.../node_modules/esprima/esprima.js:359:23)
>> at scanIdentifier (.../node_modules/esprima/esprima.js:729:20)
>> at advance (.../node_modules/esprima/esprima.js:1573:21)
>> at lex (.../node_modules/esprima/esprima.js:1691:78)
>> at expect (.../node_modules/esprima/esprima.js:2521:21)
>> at parseObjectInitializer (.../node_modules/esprima/esprima.js:3047:9
>> )
>> at inheritCoverGrammar (.../node_modules/esprima/esprima.js:2681:18)
>> at parsePrimaryExpression (.../node_modules/esprima/esprima.js:3247:
>> 20)
>> at inheritCoverGrammar (.../node_modules/esprima/esprima.js:2681:18)
>> at parseLeftHandSideExpressionAllowCall (.../node_modules/esprima/
>> esprima.js:3414:20)
>>
>> If I start node with --stack-size=1200, I no longer get the error and
>> esprima can successfully parse the code. Unfortunately, I can't seem to do
>> this with Chrome. I tried:
>>
>>   
>> Error.stackTraceLimit = 1200;
>> var js = document.createElement("script");
>> js.type = "text/javascript";
>> js.src = './elm.js';
>> document.body.appendChild(js);
>>   
>>
>> ... which doesn't seem to change anything.
>>
>> I've been commenting out different sections of my code in an attempt to
>> see what part is ultimately causing this, but that has been pretty painful.
>> If anyone has any suggestions, I'd love some advice.
>>
>> Thanks,
>> Iain
>>
>> --
> 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] Maximum call stack size exceeded while parsing generated code

[Nick H]

In my case, a recursive function was written in such a way that it couldn't
benefit from tail-call optimization. It was in 0.17. That was the only time
I've encountered the error.

On Sun, Dec 4, 2016 at 3:58 PM, Richard Feldman  wrote:

> Is this true only when the debugger is running? I've heard of people
> hitting this when the debugger is running (e.g. in elm-reactor, which
> always has the debugger running) but not so much with a plain old elm-make.
>
> On Saturday, December 3, 2016 at 8:01:13 PM UTC-8, Nick Hollon wrote:
>>
>> I have run into this before. It can be caused by runaway recursion. Can
>> you share your Elm code with us?
>>
>> On Dec 2, 2016, at 8:42 AM, Iain Gray  wrote:
>>
>> I'm having a strange problem and was wondering if anyone had any
>> suggestions on how to pinpoint what is causing it.
>>
>> I have an Elm app that compiles in 0.18, but the generated javascript
>> code is throwing a "RangeError: Maximum call stack size exceeded" as soon
>> as the javascript file is loaded into Chrome. I do not have this problem in
>> Firefox, but I can reproduce it in nodejs/esprima as follows:
>>
>> var esprima = require('esprima');
>> var fs = require('fs');
>> var filePath = path.join('.', 'elm.js');
>>
>> fs.readFile(filePath, 'utf8', function(err, data) {
>>   console.log(esprima.parse(data));
>> });
>>
>> RangeError: Maximum call stack size exceeded
>> at isKeyword (.../node_modules/esprima/esprima.js:359:23)
>> at scanIdentifier (.../node_modules/esprima/esprima.js:729:20)
>> at advance (.../node_modules/esprima/esprima.js:1573:21)
>> at lex (.../node_modules/esprima/esprima.js:1691:78)
>> at expect (.../node_modules/esprima/esprima.js:2521:21)
>> at parseObjectInitializer (.../node_modules/esprima/esprima.js:3047:9
>> )
>> at inheritCoverGrammar (.../node_modules/esprima/esprima.js:2681:18)
>> at parsePrimaryExpression (.../node_modules/esprima/esprima.js:3247:
>> 20)
>> at inheritCoverGrammar (.../node_modules/esprima/esprima.js:2681:18)
>> at parseLeftHandSideExpressionAllowCall (.../node_modules/esprima/
>> esprima.js:3414:20)
>>
>> If I start node with --stack-size=1200, I no longer get the error and
>> esprima can successfully parse the code. Unfortunately, I can't seem to do
>> this with Chrome. I tried:
>>
>>   
>> Error.stackTraceLimit = 1200;
>> var js = document.createElement("script");
>> js.type = "text/javascript";
>> js.src = './elm.js';
>> document.body.appendChild(js);
>>   
>>
>> ... which doesn't seem to change anything.
>>
>> I've been commenting out different sections of my code in an attempt to
>> see what part is ultimately causing this, but that has been pretty painful.
>> If anyone has any suggestions, I'd love some advice.
>>
>> Thanks,
>> Iain
>>
>> --
>> 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] Cmd.andThen

[Nick H]

This does sound like a useful addition. Unlike most of the functions that
people suggest adding to core, I don't think Cmd.andThen can be written by
an end user (or library author).

On Wed, Nov 30, 2016 at 7:19 AM, Mark Hamburg  wrote:

> A bigger issue going forward is that with effects managers, commands
> aren't just shims around tasks. So, the notion that a module should expose
> both a command-based interface and a task-based interface doesn't hold up
> well in the long term. That leads me back to the notion that if commands
> are the way to specify work to be done, then they need more of the
> facilities that tasks offered.
>
> That said, I have no idea what Cmd.andThen would do with a batch command.
> But are the batches for commands and subscriptions really better than lists?
>
> Mark
>
> On Wed, Nov 30, 2016 at 7:12 AM Max Goldstein 
> wrote:
>
>> Austin, you're exactly correct. Cmd is meant to be passed out to the
>> runtime, that's it.
>>
>> The reason Http allows you to skip Task is for learnability. You can make
>> a simple request without learning what a Task is. But we shouldn't be
>> hobbled by that when we want to compose different types of effects.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Advantages of the module - exposing syntax

[Nick H]

The module's interface is an entity unto itself. When I am visiting
unfamiliar code, I often want to know what its API looks like. Having
everything there at the top is way easier than having to scan through
search results for Ctrl-F "exposed".

It also helps with design. Seeing the entire interface written out in one
place helps you recognize what's missing, what's redundant, what's
unnecessary. Plenty of times in Java land, I would run into methods that
didn't have the appropriate access modifier. That sort of thing is much
easier to spot and fix when it's all in one place.

When you are adding documentation to the module, the table of contents gets
defined at the top of the file also. (The functions can be organized
differently in the docs than they are in the code itself). Once that's
there, having the API listed there makes more sense.

On the other hand, with the documentation in place, your function names are
repeated in *three* places. Which I admit is kind of annoying when you need
to move or rename something.

On Wed, Nov 30, 2016 at 9:02 AM, Joey Eremondi 
wrote:

> This is something that is probably solved by having better IDE/editor
> tools to manage imports/exports, rather than changing the language.
>
> The import syntax has gone through many iterations, so I wouldn't be
> surprised if it's pretty stable where it is.
>
> On Wed, Nov 30, 2016 at 8:33 AM, Matthew Griffith 
> wrote:
>
>>
>> I find exposing functions/types at the top gives a nice summary of what
>> is exposed when reading a new module.  I can usually get a good idea of how
>> the module works by seeing the names of the things that are exposed next to
>> each other.  That would be harder to do if the exposed annotation is
>> throughout the module.
>>
>> I haven't really noticed the expose syntax as being a pain in
>> refactoring/reorganization, though it is an additional step when moving, so
>> I see your point.  However, in my experience the additional step is pretty
>> trivial/quick to handle, especially with the compiler guiding you.
>>
>> -Matt
>>
>>
>>
>> On Wednesday, November 30, 2016 at 9:07:15 AM UTC-5, Martin Cerny wrote:
>>>
>>> Hi all,
>>> coming from Java, C++ and C#, I find the module X exposing (A,B,C)
>>> syntax weird - to be short, it feels a bit like C/C++ header files, in that
>>> you repeat entity names at multiple places, making refactoring harder. I
>>> however guess the syntax was chosen for a reason - so I am asking: what are
>>> the advantages of
>>>
>>> module Foo exposing (bar)
>>>
>>> bar: Int
>>>
>>> over something like
>>>
>>> module Foo
>>>
>>> exposed bar: Int
>>>
>>> Hope the answers will help me better understand Elm
>>>
>>> Thanks
>>> Martin
>>>
>> --
>> 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] Cmd.andThen

[Nick H]

I can't picture how this function would work. Could you give an example of
where you would want to use it? Is this just a shortcut around having to
make two passes through the update function?

On Tue, Nov 29, 2016 at 1:27 PM, Mark Hamburg  wrote:

> With various libraries only returning commands instead of tasks, would it
> be reasonable to add the following function (and could it be added without
> going inside of the implementation for Cmd)?
>
> Cmd.andThen : (x -> Cmd y) -> Cmd x -> Cmd y
>
> The slippery slope is that we end up recreating much of Task in Cmd, but
> the distinction between the two is somewhat vague — two constructs to cover
> slightly more than one concept.
>
> Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Firebase package - should be an effect module or native module?

[Nick H]

(I mentioned version 0.16 because I think that is when the native review
process was officially discontinued, but actually I bet the community
packages on the whitelist are older even than that.)

On Tue, Nov 29, 2016 at 11:33 AM, Nick H <falling.maso...@gmail.com> wrote:

> There is no process for adding new packages to the whitelist. Everything
> on there, besides some newer elm-lang packages, has been around since
> version 0.16.
>
> But that aside, you should never use native modules if there is another
> option.
>
> On Tue, Nov 29, 2016 at 10:58 AM, Ed Ilyin <eduard.il...@gmail.com> wrote:
>
>> What if I'm going to write elm-firebase package - should I write it as an
>> effect module or native module to have a chance to be whitelisted?
>>
>> Ed Ilyin
>>
>> --
>> 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] Inter triplets communication.

[Nick H]

Sergii, not every interaction with the "UserInfo" module needs to go
through a function called "update". Just because the top-level Elm
architecture uses a single update function and a single view function does
not mean that you should automatically mirror this setup throughout your
program. As Richard points out, trying to do this leads to awkward design
problems that don't need to exist.

Also... I don't know what a triplet is. The only place I've heard that word
is referring to a three-member tuple. What do you mean when you use it?



On Tue, Nov 29, 2016 at 6:45 AM, <sergii.kamens...@zalando.de> wrote:

> @Rupert Smith
> Your module for pub/sub looks great! I will be useful for a lot of people
> like me. I think you should publish it.
> Can you add a README or provide few examples how to use it properly?
>
> @Nick H
> I also thought about this
>
>> type Action = Loaded | UserInfo UserInfo.Action | Ratings Ratings.Action
>>
> But then I should also change this
>  Cmd.map UserInfo effect
> to
>  Cmd.map effect
> and in UserInfo.update use global actions everywhere. And this also brakes
> encapsulation, so I cannot use
> this triplet in my other apps with different main action type.
>
>
> --
> 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: elm-make: Map.!: given key is not an element in the map

[Nick H]

The situation should be much improved now in 0.18. I don't see it mentioned
in the release notes, but from the beta announcement
:

Fix elm-make bug where build artifacts could get corrupted, requiring
> delete of elm-stuff/build-artifacts/
>

But it appears that we still need to delete elm-stuff sometimes. So it's
probably a workaround for more than one bug.

Anthony, the situation you describe sounds like it must be related to
elm-package. If you can reproduce your problem and there isn't already a
relevant bug report
,
I would recommend opening one!

On Mon, Nov 28, 2016 at 10:02 AM, Rex van der Spuy 
wrote:

>
> I'm assuming this should actually never happen.
>>
>
> Yes, "have you tried deleting elm-stuff?" is a bit of oral tradition
> folklore that can magically cure all manner of ailments.
> It's Elm's take on "Have you tried turning it off and on again?"
> It burned me as a beginner too, and has been a problem since I started
> using Elm with 0.15
>
> Does anyone know if it's possible to prevent this from being necessary?
> Or is there a technical reason why the complier can't forcibly clear the
> elm-stuff cache?
>
> --
> 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] ANN: style-elements v2 published

[Nick H]

Looks awesome! Can't wait to try it out.

On Mon, Nov 28, 2016 at 7:51 AM, Matthew Griffith 
wrote:

>
> v2.0.0 of the style-elements
>  library is now released!
>
> The library is an experiment in handling style in elm, focusing on
> simplifying css as much as possible.
>
> It does this by
>
>- removing parts of css that cause the most trouble
>- limiting available properties without limiting functionality (i.e.
>trying to make the CSS language smaller)
>- setting defaults
>- providing clean interfaces to the good parts like media queries,
>flex-box and animations.
>
> It's meant to be a css preprocessor with css best practices built in.
>
>
>
> --
> 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] Inter triplets communication.

[Nick H]

>
> (In the UserInfo "update" function if cannot return a command(effect)
> "Ratings Reload" directly, because of this "Cmd.map UserInfo effect")
>

It seems to me that you should not be wrapping "Loaded" in a "UserInfo"
action. Judging from your update function, I am guess your main action type
looks like:

type Action = UserInfo UserInfo.Action | Ratings Ratings.Action

Here, these are wrappers for actions that are dealt with in one module of
your program or another. I suggest that you modify this to be

type Action = Loaded | UserInfo UserInfo.Action | Ratings Ratings.Action

Because "Loaded" has consequences in both of your components, it ought to
be dealt with in your main update function.


On Mon, Nov 28, 2016 at 5:37 AM,  wrote:

> Hi All,
> I know that Elm doesn't have the concept of components but instead it has
> triplets. They should behave similar to components, they encapsulate
> internal implementations.
> I use this concept in my App and I faced some architectural questions.
> What is the proper or better way to communicate between triplets without
> breaking encapsulation?
> For example, let say I have two "widgets", UserInfo and Ratings. In main
> "update" function I have this
>
>Ratings act ->
>   let
> ( ratings, effect ) =
>   Ratings.update act model.ratings
>   in
> ( { model | ratings = ratings }, Cmd.map Ratings effect )
>
> UserInfo act ->
>   let
> ( userInfo, effect ) =
>   UserInfo.update act model.app
>   in
> ( { model | userInfo = userInfo }, Cmd.map UserInfo effect )
>
>
>
> I have a button "Login" in the UserInfo widget. It will call backend API
> and return the user state.
> Then I want to load and update the Rating widget.
> How and where do this?
>
>
> Should I catch "UserInfo Loaded" event in the main "update"?
> (In the UserInfo "update" function if cannot return a command(effect)
> "Ratings Reload" directly, because of this "Cmd.map UserInfo effect")
>
>Ratings act ->
>   let
> ( ratings, effect ) =
>   Ratings.update act model.ratings
>   in
> ( { model | ratings = ratings }, Cmd.map Ratings effect )
>
> UserInfo act ->
>   let
> ( userInfo, effect ) =
>   UserInfo.update act model.app
>
>   cmd =
> if act==Loaded
> then Cmd.batch [ Cmd.map UserInfo effects, Cmd.message
> (Ratings Reload) ]
> else  Cmd.map UserInfo effects
>   in
> ( { model | userInfo = userInfo },  cmd )
>
>
>
> I feel it will be too messy to keep all this inter-triplet logic here. Is
> there a better way? Maybe  something similar to pub/sub or I'm
> fundamentally wrong here?
>
> --
> 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] Noob HTTP questions

[Nick H]

I would recommend having another read through the "Linked List" and
"Generic Data Structures" sections of the union types
 page. The types you are
asking questions about behave the same way that the "List a" does.

1) Msg is a type. "Cmd Msg", "Sub Msg", and "Html Msg" are also types.

But without the Msg, "Cmd", "Sub", and "Html" are incomplete types. Let's
look at the "List a" type in the guide. You can have a value with "List
Int" or "List String" or "List Msg". The second word is required, but it
can be any type.


2) The parentheses are just for grouping.

If we write "NewGif (Result Http.Error String)", that means that NewGif is
a type constructor that takes 1 argument, and that argument has the type
"Result Http.Error String".

If instead we write "NewGif Result Http.Error String", that means that
NewGif is a type constructor that takes 3 arguments, of types Result,
Http.Error, and String. This would not compile, because Result is not a
type.

"Result Http.Error String" is a parameterized type, just like List a. The
difference is that Result needs 2 type variables filled, not just one. The
type definition for Result is

type Result a b = Err a | Ok b


3) If you change the type definition that way, then you need to change all
of the code in your program that is using the "NewGif" and "MorePlease"
type constructors. That means rewriting the update function, the view
function, and the getRandomGif function.



On Fri, Nov 25, 2016 at 2:01 AM, Justin  wrote:

> Hi,
>
> I have some questions re the Elm http example
>
> http://elm-lang.org/examples/http
>
> I pretty much grok this, but
>
> 1) What type of a thing are 'Cmd Msg', 'Sub Msg', 'Http Msg' ?
>
> Obv 'Msg' is a type. 'Cmd', 'Sub', 'Http' sound from the docs like tasks
> the Elm runtime is going to perform; so is (eg) 'Cmd Msg' something like a
> function or a closure which is passed to the runtime for execution ?
>
> 2) type Msg = MorePlease | NewGif (Result Http.Error String)
>
> What role exactly do '(Result Http.Error String)' play in this union type
> definition ? Have read the stuff on union types but can't find anything
> related to 'round bracket args' there. Or maybe I have this all wrong ?
>
> 3) Why can't I reverse the structure of the union type ?
>
> type Msg = NewGif | MorePlease (Result Http.Error String)
>
> gives me a compiler error. But not clear why, as the NewGif and the
> MorePlease messages seem to be doing the same thing -> making an HTTP call.
>
> Elm looks great. Thanks in advance for anyone's help
>
> Justin
>
> --
> 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: Whither Rationals?

[Nick H]

Nope, I didn't do any infix operators. I work a lot the vector types in
elm-community/linear-algebra, so I am quite used to prefix functions like
"add". It's more verbose, but I don't find that too much of a bother.

On Sat, Nov 26, 2016 at 2:52 PM, John Watson <john.wat...@gmx.co.uk> wrote:

> Hi, Nick,
>
> I'd be very interested to see that if you have managed to carry over all
> the infix operators from *Basics*.  I tried something like this myself in
> a fork of imeckler/ratio, but found that (for example) Basics.(+) would
> interfere with Ratio.(+).  In the end I used operators like (|+|), (+|) and
> (|+) for the cases where you're a) adding two rationals, (b) adding an int
> to a rational or (c) adding a rational to an int.  I found it relatively
> unobtrusive but I seem to get the feeling that this sort of thing is
> becoming frowned upon.  I have hesitated to publish it.
>
> On Saturday, 26 November 2016 20:57:50 UTC, Nick H wrote:
>>
>> I have a module that implements most of the math functions from *Basics*
>> for rational numbers. Happy to publish it.
>>
>> For interop with ints, there is
>>
>> int : Int -> Rational
>>
>> Then converting back you have the normal round/floor/ceiling as well as
>> toFloat. Is that unobtrusive enough?
>>
>>
>> On Sat, Nov 26, 2016 at 9:44 AM, John Watson <john@gmx.co.uk> wrote:
>>
>>> Nothing too complex.  I do stuff with music notation, which has the
>>> concept of half note, quarter note etc.  One thing I've been toying with is
>>> porting the Haskell School of Music
>>> <http://haskell.cs.yale.edu/wp-content/uploads/2015/03/HSoM.pdf> /
>>> Euterpea <https://github.com/Euterpea/Euterpea> to Elm. I just prefer
>>> to model things with the right abstraction.
>>>
>>>
>>> On Saturday, 26 November 2016 15:44:28 UTC, Max Goldstein wrote:
>>>>
>>>> What problem are you trying to solve that you can't do with Floats?
>>>
>>> --
>>> 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] About output file size

[Nick H]

Luiz, what sort of load times are you looking at?

On Sat, Nov 26, 2016 at 1:27 PM, Nick H <falling.maso...@gmail.com> wrote:

> I would 100% recommend Elm for small projects!
>
> The core platform takes up a certain size, but the code you write on top
> of that is not going to add much more.
>
> On Sun, Nov 20, 2016 at 8:06 AM, Luiz Bills <luizpbi...@gmail.com> wrote:
>
>> Can I output a js file more optimized? A simple hello world outputs 175K
>> (67K minified)...
>> Is not recommeded use Elm for small projects?
>>
>> --
>> 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] About output file size

[Nick H]

I would 100% recommend Elm for small projects!

The core platform takes up a certain size, but the code you write on top of
that is not going to add much more.

On Sun, Nov 20, 2016 at 8:06 AM, Luiz Bills  wrote:

> Can I output a js file more optimized? A simple hello world outputs 175K
> (67K minified)...
> Is not recommeded use Elm for small projects?
>
> --
> 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] The Elm Architecture and Html.beginnerProgram

[Nick H]

What are you trying to figure out?

If you are looking for the implementation of Html.beginnerProgram, you can
look in the elm-stuff/packages directory. Or you can compile your program
and read the output JavaScript to see what is "really" going on. But I
don't think either of those things are going to be very helpful.

On Sat, Nov 26, 2016 at 12:59 PM, Brent Brinkley 
wrote:

> Where can I find the code that show specifically what's happening with the
> information that's passed into Html.beginnerProgram { model = model, view =
> view, update = update } ??
>
> --
> 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: Whither Rationals?

[Nick H]

There is also willnwhite/bigratio
<http://package.elm-lang.org/packages/willnwhite/bigratio/1.2.0/BigRatio>
(also not update to 0.18 yet) that uses big integers... might be preferable
for avoiding "resolution" problems when numerators and denominators get to
big.

On Sat, Nov 26, 2016 at 12:57 PM, Nick H <falling.maso...@gmail.com> wrote:

> I have a module that implements most of the math functions from *Basics*
> for rational numbers. Happy to publish it.
>
> For interop with ints, there is
>
> int : Int -> Rational
>
> Then converting back you have the normal round/floor/ceiling as well as
> toFloat. Is that unobtrusive enough?
>
>
> On Sat, Nov 26, 2016 at 9:44 AM, John Watson <john.wat...@gmx.co.uk>
> wrote:
>
>> Nothing too complex.  I do stuff with music notation, which has the
>> concept of half note, quarter note etc.  One thing I've been toying with is
>> porting the Haskell School of Music
>> <http://haskell.cs.yale.edu/wp-content/uploads/2015/03/HSoM.pdf> /
>> Euterpea <https://github.com/Euterpea/Euterpea> to Elm. I just prefer to
>> model things with the right abstraction.
>>
>>
>> On Saturday, 26 November 2016 15:44:28 UTC, Max Goldstein wrote:
>>>
>>> What problem are you trying to solve that you can't do with Floats?
>>
>> --
>> 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: Whither Rationals?

[Nick H]

I have a module that implements most of the math functions from *Basics*
for rational numbers. Happy to publish it.

For interop with ints, there is

int : Int -> Rational

Then converting back you have the normal round/floor/ceiling as well as
toFloat. Is that unobtrusive enough?


On Sat, Nov 26, 2016 at 9:44 AM, John Watson  wrote:

> Nothing too complex.  I do stuff with music notation, which has the
> concept of half note, quarter note etc.  One thing I've been toying with is
> porting the Haskell School of Music
>  /
> Euterpea  to Elm. I just prefer to
> model things with the right abstraction.
>
>
> On Saturday, 26 November 2016 15:44:28 UTC, Max Goldstein wrote:
>>
>> What problem are you trying to solve that you can't do with Floats?
>
> --
> 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] What Elm needs to move forward

[Nick H]

I found out about the 0.18 release and elm-conf EU via Twitter. Also lots
of announcements there about live coding sessions, local meetups, etc.

I can try to echo some of that stuff here if the organizers don't do it,
but I am only on Twitter sporadically. But there is a wealth of community
chatter on there!!

Also, I just sent a request to Elm Weekly  to
post their newsletter here on the mailing list. Because everybody should
know about it!

On Thu, Nov 24, 2016 at 6:42 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Thursday, November 24, 2016 at 2:38:07 PM UTC, Rupert Smith wrote:
>>
>> On Thursday, November 24, 2016 at 8:54:33 AM UTC, Zachary Kessin wrote:
>>>
>>> I wish I could go to Elm-conf eu, but right now I don't have the budget
>>> to travel.
>>>
>>
>> Paris 8/9 June 2017 - https://elmeurope.org/ - Is this the Elm-conf EU
>> we are talking about?
>>
>> It says:
>>
>> CFP rules
>> Elm Europe 2017
>>
>> Only english, we'll announce the result of the CFP when it's done (it
>> seems that it'll be december 8th)
>>
>
> I think something Elm needs to help move it forward might be a better
> approach to galvanising the community. I did not hear of this Elm-conf EU
> until now. Perhaps I live in a cave or something, but I searched this
> mailing list and also found no mention of it.
>
> Also, the recent release of Elm 0.18, it was discussed on the elm-dev
> list, but no announcement was made here.
>
> I think we could try and get a few volunteers to act as 'community
> secretaries' or something like that, and get a bit better at making
> community announcements.
>
> Anyway, the EU conference looks possible for me, I shall submit a CFP for
> my work on Elm + Polymer.
>
> --
> 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] Rename Just to Something, as the counterpart to Nothing?

[Nick H]

OK, here are the suggestions so far:

type Maybe a = ...

Nothing | Just a
Nothing | Something a
None | Some a
NoValue | Some a
Nothing | Some a
Nothing | The a
Nothing | A a
Nothing | Thing a
NoThing | Thing a
Nothing | Have a
Nothing | Got a
Null | NotNull a
No | Yes a
Empty | Full a

(I just added that last one.)


On Tue, Nov 22, 2016 at 12:46 PM, David Andrews  wrote:

> I don't think it really works for this, but the natural definition for
> Maybe would seem to be
>
> Maybe a = Yes a | No
>
> On Nov 22, 2016 11:30 AM, "Will White"  wrote:
>
>> I see.
>>
>> We’re happy using the ungrammatical Ok a for Results, so why not Thing a
>> for Maybes?
>>
>> On 22 Nov 2016, at 13:06, 'Andrew Radford' via Elm Discuss <
>> elm-discuss@googlegroups.com> wrote:
>>
>> I think his point was if it was a Maybe List Int, then you would have
>>
>> 'A items'
>>
>> It still seems English is not up to this task :) We should probably just
>> make up a new word, start using it day to day, then have it included in the
>> OED. If it can be done for 'selfie
>> ', then we could do
>> it for 
>>
>> On Tuesday, 22 November 2016 10:35:48 UTC, Will White wrote:
>>>
>>> type Maybe thing = A thing | Nothing
>>>
>>> So with List.head list I’d get A 2 or Nothing.
>>>
>>> On 22 Nov 2016, at 10:20, Oliver Searle-Barnes 
>>> wrote:
>>>
>>> The problem with Some is that it should be A/An/Some depending on the
>>> subject. I'm starting to come round to Thing vs Nothing. While the grammer
>>> isn't spot on the semantics are very clear.
>>>
>>>
>>> On Tuesday, 22 November 2016 11:06:10 UTC+1, Will White wrote:

 weapon = Just sword doesn’t make sense for Maybe. It implies “just
 sword, out of all the weapons”. Just *would*make sense in a Just
 weapon | All (List weapon) type, where weapon could also be All [ sword,
 mace, nunchuk ].

 I think we all agree that Nothing totally nails its concept (better
 than null for the uninitiated). I'm just looking for a word that implies
 its alternative is Nothing, e.g. Thing, Something. If it’s grammatically
 correct, that’s a bonus, but I think eliminating things which hinder
 understanding is more important.

 On 22 Nov 2016, at 00:24, joseph ni  wrote:

 I came to Elm not knowing about the Maybe type.
 The hardest thing for me to grasp was the use case and being able to
 map : (a -> b) -> Maybe a -> Maybe b. And knowing when to use a Maybe
 (rarely) vs when to use a union type or refactor the code so it doesn't
 need the Maybe type.

 If I was to qualitatively estimate the amount of time spent learning
 about Maybe. I'd say it took me a moment to understand `Maybe a = Just a |
 Nothing` and a couple of months to get comfortable enough with the Maybe
 type now to understand where it's needed in my app.

 So I'd tend to lean with Joey, the wording works for me and changing it
 would feel arbitrary and break the current grammatical 'symmetry' as in
 weapon = Just sword
 vs
 weapon = Something sword

 On Tuesday, 22 November 2016 08:19:21 UTC+11, Oliver Searle-Barnes
 wrote:
>
> I have to admit I did find `Just` very confusing when I first
> encountered it, as mentioned earlier in this thread it implies some kind 
> of
> limitation which doesn't match the semantics of Maybe at all. That said, 
> it
> was one of those little oddities that very quickly become second nature,
> just wanted to point out that it is a slight bump in the road for 
> newcomers.
>
>
> On Monday, 21 November 2016 18:34:05 UTC+1, Noah Hall wrote:
>>
>> Has anyone actually encountered anyone being confused by the names? I
>>
>> haven't. I think this a solution to a problem that doesn't exist.
>>
>> On Mon, Nov 21, 2016 at 6:15 PM, Will White 
>> wrote:
>> > I think that’s because you already know what Just means. I don’t
>> think it’s
>> > arbitrary though from an accessibility point of view. Some or None
>> is easier
>> > for newcomers to understand than Just or Nothing, especially as
>> Some isn’t
>> > misleading the way Just is, as Andrew described well.
>> >
>> > On 21 Nov 2016, at 17:05, Joey Eremondi 
>> wrote:
>> >
>> > Honestly, these choices seem pretty arbitrary. Everyone has a
>> preference. ML
>> > uses Some/None, Haskell uses Just/Nothing. Some people find
>> Something
>> > intuitive, some don't.
>> >
>> > Given that the choices is (mostly) arbitrary, it seems best to
>> stick with
>> > the status quo.
>> >
>> > On Mon, Nov 21, 2016 at 7:47 AM, 'Andrew Radford' via Elm Discuss
>> >  wrote:
>> >>
>> >> Probably 

Re: [elm-discuss] Re: Passing properties as arguments to messages?

[Nick H]

>
> You might look at lenses (e.g. elm-monocle) to see one approach that might
> appeal to you.


This is pretty cool. I've often made setter functions for my records,
wrapping around Elm's regular update syntax. I didn't realize that it's
part of a larger class of patterns.

On Tue, Nov 22, 2016 at 7:13 AM, Austin Bingham 
wrote:

> You might look at lenses (e.g. elm-monocle) to see one approach that might
> appeal to you. Lenses are apparently frowned upon by some, but I think they
> capture the essence of what you're asking.
>
> On Tue, Nov 22, 2016 at 4:04 PM Wouter In t Velt 
> wrote:
>
>> Op dinsdag 22 november 2016 15:55:25 UTC+1 schreef Rex van der Spuy:
>>
>> But, can anyone explain why Elm doesn't let us do this?
>>
>>
>> My impression is that it has to do with the enforced strong typing and
>> type safety of elm.
>>
>> A record is intended for key-value type info where each value could be of
>> a different type.
>> And elm's greatness requires that elm always knows the type it is working
>> on.
>> Dynamic typing for records (which javascript does allow for objects)
>> would break this guarantee.
>>
>> So with a record, you get the flexibility that each field could be
>> whatever type, but you lose the dynamicness (is that even a word?) of the
>> keys.
>> With Dict, it is the other way around. You can get a value by supplying a
>> dynamic key, but all values in the Dict must be of the same type.
>>
>> --
>> 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] Proposed addition for Task package

[Nick H]



On Mon, Nov 21, 2016 at 7:04 PM, Charlie Koster  wrote:

> I'm a fan of the changes to Task.perform in Elm 0.18. However, I'm still
> finding that I'm writing a lot of boilerplate in some situations. For
> example, there are several instances when I want to send a msg which has no
> payload.
>
> Task.perform (\_ -> GoToLoginPage) (Task.succeed Nothing)
>
> I do this any time I am navigating to a different page, submitting a form,
> cancelling a form, kicking off any asynchronous request (logging in,
> CRUDing any data), and maybe one or two other special cases.
>
> I don't see any reason why not have a function in Task that takes a msg
> and returns a Cmd msg.
>
> sendMsg : msg -> Cmd msg
>
> Which could be used like this
>
> Task.sendMsg GoToLoginPage
> Task.sendMsg GoToOneOfTenOtherPages
> Task.sendMsg IsFetchingData
> Task.sendMsg IsUpdatingData
> Task.sendMsg IsCreatingData
> Task.sendMsg IsDeletingData
> Task.sendMsg CancelCreate
> Task.sendMsg CancelDelete
> Task.sendMsg LogoutSucceed
> ...
>
> Any thoughts on this proposed addition? Does anyone else find themselves
> writing a lot of boilerplate with Task.perform?
>
> --
> 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: ANN: update-clock for fixed-time-step game loops

[Nick H]

You wouldn't be so sure of what? I am not sure which of my statements you
are responding to.

Network synchronization is a separate (and much more complicated) problem.
This library won't help with that.

On Mon, Nov 21, 2016 at 11:40 AM, Gaëtan André <gaetan.an...@gmail.com>
wrote:

> I wouldn't be so sure. For example, in networking games where one might
> need to keep clocks synced.
>
> Le dimanche 20 novembre 2016 21:08:37 UTC+1, Nick H adn écrit :
>>
>> The purpose of the Clock is to relate the passage of time in the "real"
>> world to the passage of time in the simulated world. So the Clock is
>> fundamentally something that exists outside of the simulation... there is
>> no need for the simulation to know about it.
>>
>> Having said that, I feel more confident that the Clock doesn't need to
>> keep track of the total elapsed time. A lot of the time, that number won't
>> be needed. And if it is, the simulation can easily keep track of that
>> number itself, given the period.
>>
>>
>>
>> On Sun, Nov 20, 2016 at 1:40 AM, Gaëtan André <gaetan...@gmail.com>
>> wrote:
>>
>>> Passing Clock.period would be indeed more useful in the example's use
>>> case.
>>>
>>> Could we imagine update functions where the total elapsed time is needed?
>>>
>>> Wouldn't it be more flexible to pass the Clock object?
>>>
>>> Le samedi 19 novembre 2016 18:59:02 UTC+1, Nick H a écrit :
>>>>
>>>> Great questions.
>>>>
>>>> I am wondering why you don't pass Clock.period to the update method and
>>>>> use the global delta instead
>>>>
>>>>
>>>> Reasons why period doesn't get passed directly to the update function:
>>>>
>>>> 1. The function would need 5 arguments, and that is too many.
>>>>
>>>> 2. The period is unlikely to change. The Clock needs a period, so we
>>>> may as well set the period on the clock once, and then not worry about it.
>>>>
>>>> (The same could be said of the physicsUpdate function... we're unlikely
>>>> to ever pass a different function to Clock.update. So why isn't that
>>>> attached to the Clock record too? Because then Clock's type definition
>>>> would need a parameter. Parametrized types are fine. But in this case, I
>>>> thought it was better to add complexity to the function rather than the
>>>> type.)
>>>>
>>>> is this counter really useful for a physical update? Wouldn't we need
>>>>> more the real time (Clock.time*Clock.period)?
>>>>>
>>>>
>>>> You're absolutely right.
>>>>
>>>> Actually, I think more useful than either Clock.time or
>>>> (Clock.time*Clock.period) might be to just pass Clock.period. That way, we
>>>> wouldn't need that global delta value any more. What do you think about
>>>> that?
>>>>
>>>> Thanks for taking a look!
>>>> ~Nick
>>>>
>>>> On Sat, Nov 19, 2016 at 6:01 AM, Gaëtan André <gaetan...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Nick,
>>>>>
>>>>> great effort.
>>>>>
>>>>> I have been looking for your code and example and I am wondering why
>>>>> you don't pass Clock.period to the update method and use the global delta
>>>>> instead. You also pass Clock.time a step counter, but this is not used in
>>>>> the example, is this counter really useful for a physical update? Wouldn't
>>>>> we need more the real time (Clock.time*Clock.period)?
>>>>>
>>>>> Le mercredi 16 novembre 2016 22:42:37 UTC+1, Nick H a écrit :
>>>>>>
>>>>>> Sorry about that. Thanks for taking proper credit!
>>>>>>
>>>>>> On Wed, Nov 16, 2016 at 9:23 AM, Rex van der Spuy <dandy...@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Wow, that's absolutely brilliant!!!
>>>>>>> (My username was `d13` by the way - so that was me!)
>>>>>>> Congratulations!!!
>>>>>>>
>>>>>>> --
>>>>>>> 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...@googleg

Re: [elm-discuss] Re: Open discussion about optimization of code potentially triggered very often (mousemove) ?

[Nick H]

That actually sounds like it works pretty well. Even though you are getting
multiple triggers, you are still preventing an enormous volume of mousemove
updates. (I am assuming the time until reactivation is relatively long).

The only thing that I would add is a filter on MoveMsg updates... if
`active` is already set to False, ignore the MoveMsg update entirely. That
way you guarantee you aren't triggering multiple calls to Reactivate.


On Sun, Nov 20, 2016 at 1:24 AM, Matthieu Pizenberg <
matthieu.pizenb...@gmail.com> wrote:

> I have been trying something that I think could be shared.
>
> Basically I tried to see if it was possible to throttle commands by
> controlling the event attributes in the view that generate those commands.
> Well, turns out, not really ^^. The idea was the following:
>
> * In the model, have an attribute `active : Boolean` initialized at True
> (meaning that the event will trigger).
> * In the `MoveMsg` case of update function, set `active` to False and
> create a command that will reactivate it later in some time.
> * In the `Reactivate` case of update, reset `active` to True.
> * In the view, use `div [on "mousemove" ...] [...]` if active else `div []
> [...]`
>
> This almost work (so it doesn't ^^). Since mouse events can be triggered
> more often than the rendering of the view, multiple mousemove events can be
> triggered before the `[on "mousmove" ...]` is removed.
> In practice the longer the functon in your mousemove update, the higher
> are the chance that I got these multiple trigger before deactivation of the
> listener.
>
> --
> 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: ANN: update-clock for fixed-time-step game loops

[Nick H]

The purpose of the Clock is to relate the passage of time in the "real"
world to the passage of time in the simulated world. So the Clock is
fundamentally something that exists outside of the simulation... there is
no need for the simulation to know about it.

Having said that, I feel more confident that the Clock doesn't need to keep
track of the total elapsed time. A lot of the time, that number won't be
needed. And if it is, the simulation can easily keep track of that number
itself, given the period.



On Sun, Nov 20, 2016 at 1:40 AM, Gaëtan André <gaetan.an...@gmail.com>
wrote:

> Passing Clock.period would be indeed more useful in the example's use case.
>
> Could we imagine update functions where the total elapsed time is needed?
>
> Wouldn't it be more flexible to pass the Clock object?
>
> Le samedi 19 novembre 2016 18:59:02 UTC+1, Nick H a écrit :
>>
>> Great questions.
>>
>> I am wondering why you don't pass Clock.period to the update method and
>>> use the global delta instead
>>
>>
>> Reasons why period doesn't get passed directly to the update function:
>>
>> 1. The function would need 5 arguments, and that is too many.
>>
>> 2. The period is unlikely to change. The Clock needs a period, so we may
>> as well set the period on the clock once, and then not worry about it.
>>
>> (The same could be said of the physicsUpdate function... we're unlikely
>> to ever pass a different function to Clock.update. So why isn't that
>> attached to the Clock record too? Because then Clock's type definition
>> would need a parameter. Parametrized types are fine. But in this case, I
>> thought it was better to add complexity to the function rather than the
>> type.)
>>
>> is this counter really useful for a physical update? Wouldn't we need
>>> more the real time (Clock.time*Clock.period)?
>>>
>>
>> You're absolutely right.
>>
>> Actually, I think more useful than either Clock.time or
>> (Clock.time*Clock.period) might be to just pass Clock.period. That way, we
>> wouldn't need that global delta value any more. What do you think about
>> that?
>>
>> Thanks for taking a look!
>> ~Nick
>>
>> On Sat, Nov 19, 2016 at 6:01 AM, Gaëtan André <gaetan...@gmail.com>
>> wrote:
>>
>>> Hi Nick,
>>>
>>> great effort.
>>>
>>> I have been looking for your code and example and I am wondering why you
>>> don't pass Clock.period to the update method and use the global delta
>>> instead. You also pass Clock.time a step counter, but this is not used in
>>> the example, is this counter really useful for a physical update? Wouldn't
>>> we need more the real time (Clock.time*Clock.period)?
>>>
>>> Le mercredi 16 novembre 2016 22:42:37 UTC+1, Nick H a écrit :
>>>>
>>>> Sorry about that. Thanks for taking proper credit!
>>>>
>>>> On Wed, Nov 16, 2016 at 9:23 AM, Rex van der Spuy <dandy...@gmail.com>
>>>> wrote:
>>>>
>>>>> Wow, that's absolutely brilliant!!!
>>>>> (My username was `d13` by the way - so that was me!)
>>>>> Congratulations!!!
>>>>>
>>>>> --
>>>>> 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] Proposed addition to Result in elm-lang/core

[Nick H]

This function is called unpack

in elm-community/result-extra

On Sat, Nov 19, 2016 at 12:58 PM, Charlie Koster 
wrote:

> Just this morning I upgraded a 3500 line Elm 0.17 project to Elm 0.18. I
> wrote down my experience that I will share at a later date but I wanted to
> share a suggestion.
>
> My app makes a handful of Http requests. For example I have a user model
> and Msgs for when the user logs in or out.
>
> type alias Model =
> { username : String
> , fullName : String
> , password : String
> , email : String
> }
>
> type Msg =
> | Login
> | LoginSucceed Model
> | LoginFail Http.Error
> | Logout
> | LogoutSucceed
> | LogoutFail Http.Error
>
> A typical 0.18 Http requests looks like this
>
> performLogin : Model -> Cmd Msg
> performLogin user =
> let
> request =
> Http.request
> { method = "POST"
> , headers = []
> , url = "http://mydomain/login;
> , body = Http.jsonBody (userEncoder user)
> , expect = Http.expectJson userDecoder
> , timeout = Nothing
> , withCredentials = False
> }
> in
> Http.send
> (\result ->
> case result of
> Ok user ->
> LoginSucceed user
>
> Err err ->
> LoginFail err
> )
> request
>
> The `case result of` part in the Http.send argument is a lot of
> boilerplate that I don't like seeing copy/pasted in all of my Http Cmds.
>
> Additionally, in most cases my success Msg takes a payload which is the
> model that was decoded from the response and my fail Msg takes the Result's
> Http.Error.
>
> I have since created a helper function that looks like this
>
> resultToMsg : (x -> b) -> (a -> b) -> Result x a -> b
> resultToMsg errMsg okMsg result =
> case result of
> Ok a ->
> okMsg a
>
> Err err ->
> errMsg err
>
>
> With that helper function my Http Cmds now look like this
>
> performLogin : Model -> Cmd Msg
> performLogin user =
> let
> request =
> Http.request
> { method = "POST"
> , headers = []
> , url = "http://mydomain/login;
> , body = Http.jsonBody (userEncoder user)
> , expect = Http.expectJson userDecoder
> , timeout = Nothing
> , withCredentials = False
> }
> in
> Http.send
> (resultToMsg LoginFail LoginSucceed)
> request
>
> Which results in 4 fewer lines of boilerplate (5 including the whitespace).
>
> I'm terrible at naming things but I propose adding a helper function to
> elm-lang/core Result with basically the implementation above but with a
> more appropriate name than resultToMsg.
>
> --
> 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: ANN: update-clock for fixed-time-step game loops

[Nick H]

Great questions.

I am wondering why you don't pass Clock.period to the update method and use
> the global delta instead


Reasons why period doesn't get passed directly to the update function:

1. The function would need 5 arguments, and that is too many.

2. The period is unlikely to change. The Clock needs a period, so we may as
well set the period on the clock once, and then not worry about it.

(The same could be said of the physicsUpdate function... we're unlikely to
ever pass a different function to Clock.update. So why isn't that attached
to the Clock record too? Because then Clock's type definition would need a
parameter. Parametrized types are fine. But in this case, I thought it was
better to add complexity to the function rather than the type.)

is this counter really useful for a physical update? Wouldn't we need more
> the real time (Clock.time*Clock.period)?
>

You're absolutely right.

Actually, I think more useful than either Clock.time or
(Clock.time*Clock.period) might be to just pass Clock.period. That way, we
wouldn't need that global delta value any more. What do you think about
that?

Thanks for taking a look!
~Nick

On Sat, Nov 19, 2016 at 6:01 AM, Gaëtan André <gaetan.an...@gmail.com>
wrote:

> Hi Nick,
>
> great effort.
>
> I have been looking for your code and example and I am wondering why you
> don't pass Clock.period to the update method and use the global delta
> instead. You also pass Clock.time a step counter, but this is not used in
> the example, is this counter really useful for a physical update? Wouldn't
> we need more the real time (Clock.time*Clock.period)?
>
> Le mercredi 16 novembre 2016 22:42:37 UTC+1, Nick H a écrit :
>>
>> Sorry about that. Thanks for taking proper credit!
>>
>> On Wed, Nov 16, 2016 at 9:23 AM, Rex van der Spuy <dandy...@gmail.com>
>> wrote:
>>
>>> Wow, that's absolutely brilliant!!!
>>> (My username was `d13` by the way - so that was me!)
>>> Congratulations!!!
>>>
>>> --
>>> 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] Elm Http regression with requests for binary resources

[Nick H]

I don't have a workaround. But it sound like it's worth opening a bug report
<https://github.com/elm-lang/http/issues>

On Fri, Nov 18, 2016 at 2:14 PM, John Watson <john.wat...@gmx.co.uk> wrote:

> You mean just set the Accept header on the request to audio/midi?  No,
> exactly the same problem, I'm afraid.
>
> On Friday, 18 November 2016 17:22:59 UTC, Nick H wrote:
>>
>> Does anything different happen if you use a MIDI mimetype, like
>> "audio/midi"?
>>
>> On Fri, Nov 18, 2016 at 5:33 AM, John Watson <john@gmx.co.uk> wrote:
>>
>>> I have a small MIDI
>>> <https://github.com/newlandsvalley/elm-comidi/blob/master/test/midi/chordsample.midi>
>>> file.  With Elm 0.17 (evancz/elm-http) I had been able to use the
>>> 'overrideMimeType hack'  to tunnel the file through HTTP as if it were
>>> text.  Here's a gist
>>> <https://gist.github.com/newlandsvalley/9cb76e88d2b2c6108b3338fffd9e39dd>.
>>> This hack no longer works
>>> <https://gist.github.com/newlandsvalley/945d278e0570254285f77d0e863e8059>
>>> in Elm 0.18 (where I have followed suggestions from elm-dev on slack simply
>>> to use an appropriate Accept header).  What seems to happen is that
>>> characters and 8-bit numbers come across unscathed but binary values larger
>>> than 255 do not.  This is evident in the MIDI sample from byte 23 where the
>>> decoded result differs from the 0.17 version.
>>>
>>> Can anybody suggest an alternative workaround?
>>>
>>> --
>>> 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] Can't install native package using elm-github-install

[Nick H]

What if you just removed the port declarations from your package? That's
only a few lines of code, and nothing else seems to depend on them (except
a little Util function). The rest of your work could even be published to
the package manager.




On Fri, Nov 18, 2016 at 4:18 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Friday, November 18, 2016 at 11:17:23 AM UTC, Peter Damoc wrote:
>>
>> There are two approaches to interacting with JS:
>> 1. ports
>> 2. Native
>>
>> modules with ports cannot be packaged/published and are designed to be
>> used ONLY in the final product
>> modules with Native code can be packaged/published but they have to be
>> whitelisted.
>> Their use is discouraged outside of the web-platform that the official
>> elm-lang org is implementing.
>>
>> elm-github-install is designed for the brave rebels who want to
>> collaborate on non-whitelisted Native modules.
>>
>> To my knowledge, port modules were never designed to be shared.
>>
>
> I understand and support the reasons for the above. Ok, so when it says it
> can be used to share native modules it does not mean ports.
>
> I found using a port to enable global communication with the Auth module
> from anywhere in my application (any time you get a 401 or 403 you invoke
> 'unauthed') to be quite convenient. Perhaps I might find a better solution
> to this using out messages, or perhaps Elm will eventually develop some
> sort of pub/sub messaging mechanism that I could use instead.
>
> I'm only wanting to share this code accross my own projects - i don't
> think it is really usable by others in its current state.
>
> I think I will put all the code I want to share in its own folder, and
> share that accross projects as a git submodule. Not the ideal solution but
> better than the alternative of cut and paste coding.
>
> --
> 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 Http regression with requests for binary resources

[Nick H]

Does anything different happen if you use a MIDI mimetype, like
"audio/midi"?

On Fri, Nov 18, 2016 at 5:33 AM, John Watson  wrote:

> I have a small MIDI
> 
> file.  With Elm 0.17 (evancz/elm-http) I had been able to use the
> 'overrideMimeType hack'  to tunnel the file through HTTP as if it were
> text.  Here's a gist
> .
> This hack no longer works
> 
> in Elm 0.18 (where I have followed suggestions from elm-dev on slack simply
> to use an appropriate Accept header).  What seems to happen is that
> characters and 8-bit numbers come across unscathed but binary values larger
> than 255 do not.  This is evident in the MIDI sample from byte 23 where the
> decoded result differs from the 0.17 version.
>
> Can anybody suggest an alternative workaround?
>
> --
> 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] dependency problem with upgrading to 0.18

[Nick H]

I am looking at the github page for that project, and it's elm-package.json

says something different:

"dependencies": {
"elm-lang/core": "4.0.0 <= v < 5.0.0"
},
"elm-version": "0.17.0 <= v < 0.18.0"

I don't know why this is different from what you are seeing.

On Thu, Nov 17, 2016 at 9:32 PM, Martin DeMello 
wrote:

> elm-update ran successfully, but elm-make fails with
>
> $ elm-make
> Problem in dependency tortus/elm-array-2d 2.0.1
>
> The elm-package.json constraints of 'tortus/elm-array-2d' are probably
> letting too much stuff through. Definitely open an issue on the relevant
> github
> repo to get this fixed and save other people from this pain.
>
> However, I checked tortus/elm-array-2d out independently and it built fine
> against 0.18; its elm-package.json looks fine too (and is pretty minimal).
>
> "dependencies": {
> "elm-lang/core": "5.0.0 <= v < 6.0.0"
> },
> "elm-version": "0.18.0 <= v < 0.19.0"
>
> Any idea how to debug this? The error message is pretty opaque and none of
> the google hits for when this arose in earlier version bumps were helpful.
>
> martin
>
> --
> 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: ANN: update-clock for fixed-time-step game loops

[Nick H]

Sorry about that. Thanks for taking proper credit!

On Wed, Nov 16, 2016 at 9:23 AM, Rex van der Spuy 
wrote:

> Wow, that's absolutely brilliant!!!
> (My username was `d13` by the way - so that was me!)
> Congratulations!!!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[elm-discuss] ANN: update-clock for fixed-time-step game loops

[Nick H]

On the advice of counsel (thanks Overmind), I moved this to a new thread.

So a long time ago, d13 shared this article
 on elm-discuss. It
explains how to update your model at fixed intervals, even when the updates
are driven by, say, a subscription to AnimationFrame.diffs.

This is an important and useful pattern if you are doing physics-related
animation, because it keeps your simulation deterministic/reproducible *and*
keeps the speed independent of the frame rate.

After implementing the pattern a few times in different projects, I decided
to extract it into a library
.

It's small, but it makes my life a little easier. Hopefully it will yours
too :-)

And if you have feedback on the API, I'd love to hear it!

~Nick

-- 
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: Effects.tick vs Time.fps

[Nick H]

On second thought, maybe it was not the best idea to resurrect a thread
whose title refers to two functions that no longer exist...

On Tue, Nov 15, 2016 at 1:09 PM, Nick H <falling.maso...@gmail.com> wrote:

> Thread... resurrected!
>
> Just wanted to mention that I took the game loop pattern and wrapped it
> up in a library
> <http://package.elm-lang.org/packages/nphollon/update-clock/1.0.2>. If
> anyone has feedback on the API, I would love to hear it. I went with
> something that made sense to me, but... well, you can draw any line you
> want through just one data point :-)
>
>
> On Thu, Feb 25, 2016 at 4:38 PM, d13 <dandylio...@gmail.com> wrote:
>
>> That's brilliant, thanks so much for sharing your code!!
>>
>> --
>> 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: Why Range syntax got removed in favor of List.range

[Nick H]

>
> What do you think about my suggestion in previous reply ? replacing
> List.range with List.(..) operator ?


Forgive me if somebody has already pointed this out, but it is very easy to
write such a function yourself.

(..) : Int -> Int -> List Int
> (..) a b = List.range a b
>

If this is something that people are interested in, I think it's worth
adding to elm-community/list-extra


On Mon, Nov 14, 2016 at 1:29 PM, أحمد حبنكة  wrote:

> What do you think about my suggestion in previous reply ? replacing
> List.range with List.(..) operator ?
>
>
> بتاريخ الاثنين، 14 نوفمبر، 2016 2:43:49 ص UTC+2، كتب Max Goldstein:
>>
>> Sometimes it's useful to pass arguments to List.range and have it be
>> empty when a > b.
>>
>> Perhaps there should be *List.rangeWithStep 5 1 -1* to solve your
>> problem.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Effects.tick vs Time.fps

[Nick H]

Thread... resurrected!

Just wanted to mention that I took the game loop pattern and wrapped it up
in a library
. If
anyone has feedback on the API, I would love to hear it. I went with
something that made sense to me, but... well, you can draw any line you
want through just one data point :-)


On Thu, Feb 25, 2016 at 4:38 PM, d13  wrote:

> That's brilliant, thanks so much for sharing your code!!
>
> --
> 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] What do you think about Eve?

[Nick H]

Also, the flappy bird example doesn't render properly in Firefox, at least
for me.

On Tue, Nov 15, 2016 at 11:27 AM, Nick H <falling.maso...@gmail.com> wrote:

> Embedding the code in its documentation is a very interesting idea. I can
> see it being very useful for tutorials & libraries. (The examples were
> pleasant to read through.) But generally I try to avoid comments in favor
> of making the code self-documenting. Comments are a liability -- it's easy
> for them to get out of sync with the code, and the compiler cannot stop
> them from lying to the user.
>
> So this literate programming approach can reduce the maintenance cost of
> documentation where documentation is needed. But I worry that if so much
> emphasis is placed on the documentation, maybe there is less incentive to
> make the programming language itself readable.
>
> This is just a general thought. I don't mean to criticize Eve's
> readability in particular. Lord knows we get enough people throwing stones
> at Elm because they can't understand it after just a few minutes :-P
>
> Thanks for sharing this. I'll be interested to see where it goes.
>
> On Mon, Nov 14, 2016 at 3:21 PM, Erkal Selman <erkalsel...@gmail.com>
> wrote:
>
>> I wonder, what the elm community thinks about Eve: http://witheve.com/ ?
>> Here is the syntax reference: https://witheve.git
>> hub.io/assets/docs/SyntaxReference.pdf
>>
>> I think that this language/architecture is worth to look at.
>> It has many similarities with elm.
>> But it is more like logic programming. (Is this the logic programming of
>> the future?)
>>
>> I was following this project from far and I had the impression that he
>> (Chris Granger) was doing some kind of excel.
>> But now I see that they can do flappy bird in eve:
>> http://play.witheve.com/#/examples/flappy.eve
>> That is exciting!
>>
>> Is there something similar to Eve?
>> It really looks like something new.
>>
>> My main question:
>> What do you think, are advantages and disadvantages of Eve, if you
>> compare it with 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.
>>
>
>

-- 
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] What do you think about Eve?

[Nick H]

Embedding the code in its documentation is a very interesting idea. I can
see it being very useful for tutorials & libraries. (The examples were
pleasant to read through.) But generally I try to avoid comments in favor
of making the code self-documenting. Comments are a liability -- it's easy
for them to get out of sync with the code, and the compiler cannot stop
them from lying to the user.

So this literate programming approach can reduce the maintenance cost of
documentation where documentation is needed. But I worry that if so much
emphasis is placed on the documentation, maybe there is less incentive to
make the programming language itself readable.

This is just a general thought. I don't mean to criticize Eve's readability
in particular. Lord knows we get enough people throwing stones at Elm
because they can't understand it after just a few minutes :-P

Thanks for sharing this. I'll be interested to see where it goes.

On Mon, Nov 14, 2016 at 3:21 PM, Erkal Selman  wrote:

> I wonder, what the elm community thinks about Eve: http://witheve.com/ ?
> Here is the syntax reference: https://witheve.github.io/assets/docs/
> SyntaxReference.pdf
>
> I think that this language/architecture is worth to look at.
> It has many similarities with elm.
> But it is more like logic programming. (Is this the logic programming of
> the future?)
>
> I was following this project from far and I had the impression that he
> (Chris Granger) was doing some kind of excel.
> But now I see that they can do flappy bird in eve:
> http://play.witheve.com/#/examples/flappy.eve
> That is exciting!
>
> Is there something similar to Eve?
> It really looks like something new.
>
> My main question:
> What do you think, are advantages and disadvantages of Eve, if you compare
> it with 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.
>

-- 
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] Help for article review for SPA applications in Elm 0.18

[Nick H]

I wonder if you could run the example on gh-pages? That way the links will
work (instead of linking to localhost).

I've not ever used the navigation & url-parser packages, so some of this
was new to me. I like the way the program develops incrementally. Thanks
for sharing!

On Tue, Nov 15, 2016 at 7:21 AM, Adrián Ribao  wrote:

> Hi!
>
> I've written a post related how to do SPAs using elm 0.18. It starts from
> scratch, following the process I took while I was creating mine.
>
> I'm new in Elm and functional languages so I'd love to get your feedback.
> Also, I'm not a native English speaker so the text could have typos or
> incorrect grammar. Any help is welcome.
>
> This is the post: https://medium.com/@adrian_ribao/how-to-create-a-spa-
> application-in-elm-0-18-from-scratch-68d25e0631f6
>
> It's also my first post on medium, I think you can make annotations even
> though it's in a draft state.
>
> Thank you!
>
> Adrián
>
> --
> 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: Why Range syntax got removed in favor of List.range

[Nick H]

It was indeed:
https://groups.google.com/forum/#!topic/elm-discuss/ehtYLofp3TE

Responses ranged from "I'd rather get rid of it" to "I like it, but I
wouldn't complain if it went away." There was also a lovely tangent about
Hoogle.

Nobody was worried at that time that changing the syntax would drive away
our existing user base. Maybe they were blinded by the fact that it's not
that important.

On Tue, Nov 15, 2016 at 7:30 AM, Robin Heggelund Hansen <
skinney...@gmail.com> wrote:

> I seem to remember that the discussion to keep or remove range syntax was
> done here on the mailing list, and a lot of people had no hard feelings
> about it going away. This was very much a community decision.
>
>
> tirsdag 15. november 2016 16.19.54 UTC+1 skrev Andrew Radford følgende:
>>
>> I don't think flippantly dismissing anyone who abandons Elm as having a
>> tenuous connection is fair.  A lot of existing users, especially long time
>> users who when they started, may have done so because of the 'niceties'
>> like this, and they are now being slowly eroded. Maybe you could say they
>> are now better off going to purescript/websharper/whatever, but they are
>> also the guys actually using Elm to get real stuff done, and  often act as
>> evangelists /'recruiters' to bring more newcomers to Elm in the first
>> place. Simplifying Elm to attract the JS hordes may be a good way to grow
>> the user base, but it will come at the expense of some of these guys
>> leaving, which is a bit sad.
>>
>> As usual, it's a tricky (but hopefully correct) BDFL decision for the
>> good of the language ecosystem and usage, but not a clear slam-dunk for the
>> language itself according to a lot of people.
>>
>> On Tuesday, 15 November 2016 13:47:43 UTC, Max Goldstein wrote:
>>>
>>> If someone was so tenuously commuted to Elm that this syntax removal
>>> drives them away, oh 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.
>

-- 
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] port Maybe field behavior

[Nick H]

I think this would be a reasonable change. The maybe decoder

in Json.Decode already works this way.

On Thu, Nov 10, 2016 at 2:35 PM, Kasey Speakman 
wrote:

> So something that I just tripped over...
>
> If you're bringing a JSON object in through a port, and the elm type def
> has:
>
> *type alias aFoo =*
> *{ someFoo : Maybe String }*
>
> This JSON comes over properly:
>
> *{ someFoo: null }*
>
> But this JSON throws an error:
>
> *{ } // field omitted*
>
> If this data is from a JS library using an API, many default to omitting
> null fields in their output. Reasoning being, why carry extra stuff extra
> across the wire?
>
> Most serializers that I have used default to omitting null values from the
> serialized output.
>
> Seems to me that both null and undefined should translate to
> Maybe.Nothing when coming across a port.
>
> Anybody else run into this?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Animation not very smooth.

[Nick H]

Glad you were able to find a solution!

Elm WebGL support is primitive and unofficial. If you run into performance
issues, the culprit is probably the elm-webgl package and not the
underlying language/platform.

On Sun, Nov 6, 2016 at 4:56 AM, Gaëtan André <gaetan.an...@gmail.com> wrote:

> OK I solved my problem.
>
> Culling foodElements (little green circles) to the screen led to less
> webgl calls which solved the smoothness problem.
>
> Webgl api calls are costly. Maybe a a way to reduce the number of calls in
> my case could have been to use a geometry shader to instantiate multiple
> food elements. Anyway culling at application level works fine.
>
> Thanks for your help.
>
>
> Le samedi 5 novembre 2016 11:27:52 UTC+1, Gaëtan André a écrit :
>>
>> viewGrid was reworked as you suggested (cf. gist) but the the problem is
>> still the same.
>>
>> Sorry I had not share the cpu profiles from Chrome the first time, I do
>> it now. As you can see, the problem is that sometimes, a loop call takes a
>> lot longer than others to compute (because of gc it seems).
>>
>> On Chrome it is basically annoying but still playable, on Firefox it is
>> not playable.
>>
>> Thanks,
>>
>> Le jeudi 3 novembre 2016 02:33:35 UTC+1, Nick H a écrit :
>>>
>>> I am guessing your viewGrid function is slowing your code down. This
>>> function is creating a new mesh and passing it to the GPU on every
>>> animation frame.
>>>
>>> The solution is to make sure your WebGL.Drawable (line 465, where it
>>> says "GL.Lines gridPoints") is a constant. So extract that into its own
>>> top-level declaration, as you have done with "mesh."
>>>
>>> On Wed, Nov 2, 2016 at 1:30 PM, Gaëtan André <gaetan...@gmail.com>
>>> wrote:
>>>
>>>> Hello everybody,
>>>>
>>>> I am working on cloning Agar.io (https://agar.io/) using functionnal
>>>> languages.
>>>> Everything was going well except that my cell movements are not very
>>>> smooth.
>>>> I first blamed the network connection, but after hacking a standalone
>>>> front-end it seems like Elm might have something to do with it.
>>>>
>>>> From were I am, I don't know where to go to improve fluidity.
>>>>
>>>> I am subscribing to AnimationFrame.diffs to give the pace of the render
>>>> loop.
>>>>
>>>> Here is a gist of my code:
>>>> https://gist.github.com/rvlander/0b956d5d8d0a70f37f6206cb6f9af367
>>>>
>>>> Thanks,
>>>>
>>>> --
>>>> 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] Animation not very smooth.

[Nick H]

I am guessing your viewGrid function is slowing your code down. This
function is creating a new mesh and passing it to the GPU on every
animation frame.

The solution is to make sure your WebGL.Drawable (line 465, where it says
"GL.Lines gridPoints") is a constant. So extract that into its own
top-level declaration, as you have done with "mesh."

On Wed, Nov 2, 2016 at 1:30 PM, Gaëtan André  wrote:

> Hello everybody,
>
> I am working on cloning Agar.io (https://agar.io/) using functionnal
> languages.
> Everything was going well except that my cell movements are not very
> smooth.
> I first blamed the network connection, but after hacking a standalone
> front-end it seems like Elm might have something to do with it.
>
> From were I am, I don't know where to go to improve fluidity.
>
> I am subscribing to AnimationFrame.diffs to give the pace of the render
> loop.
>
> Here is a gist of my code:
> https://gist.github.com/rvlander/0b956d5d8d0a70f37f6206cb6f9af367
>
> Thanks,
>
> --
> 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: zip function in the standard library

[Nick H]

It's not the *standard* library, but this function and a ton of other List
stuff is available in elm-community/list-extra




On Tue, Oct 25, 2016 at 11:07 AM,  wrote:

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

-- 
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 <skinn...@gmail.com>
>>>> 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] 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] Re: Metalinguistic abstractions over databases

[Nick H]

>
> My issue is in fact related to mutually recursive types, it's just that my
> types are truly infinite. According to the linked doc about recursive types:
> "Somewhere in that cycle, you need to define an actual type to end the
> infinite expansion." Which mine does not.


That's just what I was trying to say.  Self-recursive or mutually
recursive, the solution is the same... replace a type alias with a type
definition.

Good luck!

On Sun, Oct 23, 2016 at 7:58 PM, John Kelly <jdrkell...@gmail.com> wrote:

> To my knowledge, the recursive type that you specified *will* compile.
> See here
> <https://github.com/elm-lang/elm-compiler/blob/master/hints/recursive-alias.md#mutually-recursive-type-aliases>
> .
>
> My issue is in fact related to mutually recursive types, it's just that my
> types are truly infinite. According to the linked doc about recursive types:
> "Somewhere in that cycle, you need to define an actual type to end the
> infinite expansion." Which mine does not.
>
> And to address your comment in regards to: "But still, I think you might
> be able to salvage the API if you wrap the records in union type
> constructors." This is the idea I will be exploring next, thank you for the
> recommendation.
>
>
>
> On Sunday, October 23, 2016 at 6:19:38 PM UTC-7, Nick H wrote:
>>
>> I guess you weren't explicitly defining type aliases for those records.
>> But still, I think you might be able to salvage the API if you wrap the
>> records in union type constructors.
>>
>> On Sun, Oct 23, 2016 at 6:10 PM, Nick H <falling...@gmail.com> wrote:
>>
>>> If you are trying to make a recursive type definition, you need to use
>>> union types.
>>>
>>> E.G. This is not OK:
>>>
>>> type alias Session = { speaker : Speaker }
>>> type alias Speaker = { sessions : List Session }
>>>
>>> But this will compile.
>>>
>>> type Session = Session { speaker : Speaker }
>>> type Speaker = Speaker { sessions : List Session }
>>>
>>> Think of a type alias as a kind of search-and-replace. A recursive type
>>> alias leads to a never-ending search-and-replace process.
>>>
>>>
>>>
>>> On Sun, Oct 23, 2016 at 5:17 PM, John Kelly <jdrke...@gmail.com> 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.
>>>>
>>>> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote:
>>>>>
>>>>> Just to follow up on the limitations in my library I spoke about --
>>>>> namely, not being able to represent the relationships *in *the
>>>>> resource definition. I spent a bit of time drafting up some potential api
>>>>> changes that would make it possible: here
>>>>> <https://gist.github.com/john-kelly/8ac5aa5d5e38bd148b70e10b0c44408c>
>>>>> .
>>>>>
>>>>> Handling the recursive nature of relationships was influenced by
>>>>> Json.Decode.Extra.lazy
>>>>> <http://package.elm-lang.org/packages/circuithub/elm-json-extra/latest/Json-Decode-Extra#lazy>
>>>>>
>>>>> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote:
>>>>>>
>>>>>> Great Question!
>>>>>>
>>>>>> You can checkout an example here
>>>>>> <https://gist.github.com/john-kelly/00424de66be03d9bbb07795b11c39a48>

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

[Nick H]

I guess you weren't explicitly defining type aliases for those records. But
still, I think you might be able to salvage the API if you wrap the records
in union type constructors.

On Sun, Oct 23, 2016 at 6:10 PM, Nick H <falling.maso...@gmail.com> wrote:

> If you are trying to make a recursive type definition, you need to use
> union types.
>
> E.G. This is not OK:
>
> type alias Session = { speaker : Speaker }
> type alias Speaker = { sessions : List Session }
>
> But this will compile.
>
> type Session = Session { speaker : Speaker }
> type Speaker = Speaker { sessions : List Session }
>
> Think of a type alias as a kind of search-and-replace. A recursive type
> alias leads to a never-ending search-and-replace process.
>
>
>
> On Sun, Oct 23, 2016 at 5:17 PM, John Kelly <jdrkell...@gmail.com> 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.
>>
>> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote:
>>>
>>> Just to follow up on the limitations in my library I spoke about --
>>> namely, not being able to represent the relationships *in *the resource
>>> definition. I spent a bit of time drafting up some potential api changes
>>> that would make it possible: here
>>> <https://gist.github.com/john-kelly/8ac5aa5d5e38bd148b70e10b0c44408c>.
>>>
>>> Handling the recursive nature of relationships was influenced by
>>> Json.Decode.Extra.lazy
>>> <http://package.elm-lang.org/packages/circuithub/elm-json-extra/latest/Json-Decode-Extra#lazy>
>>>
>>> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote:
>>>>
>>>> Great Question!
>>>>
>>>> You can checkout an example here
>>>> <https://gist.github.com/john-kelly/00424de66be03d9bbb07795b11c39a48>.
>>>> It builds off of the example presented in the docs.
>>>>
>>>> Currently, the library does not support representing relationships in
>>>> the Resource definition, however, the library *does *support
>>>> representing the relationships in the queries (see example). I'm not yet
>>>> sure the best way / whether it will be possible to represent the
>>>> relationships in the Resource definition. Would love to chat if you have
>>>> any ideas!
>>>>
>>>>
>>>>
>>>> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote:
>>>>>
>>>>> Hi John,
>>>>>
>>>>> The project you linked to looks great.
>>>>> How do you deal with references? (entities referencing other entities)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly <jdrke...@gmail.com>
>>>>> 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.
>>>>>>
>>>>>> --
>>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> There is NO FATE, we are the creators.
>>>>> blog: http://damoc.ro/
>>>>>
>>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

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

[Nick H]

If you are trying to make a recursive type definition, you need to use
union types.

E.G. This is not OK:

type alias Session = { speaker : Speaker }
type alias Speaker = { sessions : List Session }

But this will compile.

type Session = Session { speaker : Speaker }
type Speaker = Speaker { sessions : List Session }

Think of a type alias as a kind of search-and-replace. A recursive type
alias leads to a never-ending search-and-replace process.



On Sun, Oct 23, 2016 at 5:17 PM, 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.
>
> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote:
>>
>> Just to follow up on the limitations in my library I spoke about --
>> namely, not being able to represent the relationships *in *the resource
>> definition. I spent a bit of time drafting up some potential api changes
>> that would make it possible: here
>> .
>>
>> Handling the recursive nature of relationships was influenced by
>> Json.Decode.Extra.lazy
>> 
>>
>> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote:
>>>
>>> Great Question!
>>>
>>> You can checkout an example here
>>> .
>>> It builds off of the example presented in the docs.
>>>
>>> Currently, the library does not support representing relationships in
>>> the Resource definition, however, the library *does *support
>>> representing the relationships in the queries (see example). I'm not yet
>>> sure the best way / whether it will be possible to represent the
>>> relationships in the Resource definition. Would love to chat if you have
>>> any ideas!
>>>
>>>
>>>
>>> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote:

 Hi John,

 The project you linked to looks great.
 How do you deal with references? (entities referencing other entities)



 On Thu, Oct 20, 2016 at 9:19 PM, 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.
>
> --
> 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.
>



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

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

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

Re: [elm-discuss] Looking for subcomponent example to learn from

[Nick H]

Hmm, I haven't used that library, so I won't be of much help.

On Sun, Oct 23, 2016 at 11:57 AM, Brian Marick <mar...@roundingpegs.com>
wrote:

>
> On Oct 22, 2016, at 7:56 PM, Nick H <falling.maso...@gmail.com> wrote:
>
> Which of these elements can fire events? Is the text at the bottom the
> only place where the user can interact?
>
> If so, then the graphical elements up top can just be functions that take
> whatever data is needed to draw them.
>
>
>
> All of them. The two graphical events are animated using
> elm-style-animation, and some of the animated effects generate `Cmd Msg`.
> For example, if the bag runs out of fluid, it generates a message that will
> cause the droplets to stop falling.
>
> --
> 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] Looking for subcomponent example to learn from

[Nick H]

Which of these elements can fire events? Is the text at the bottom the only
place where the user can interact?

If so, then the graphical elements up top can just be functions that take
whatever data is needed to draw them.

ivDrip : IvData -> Html a

clock : Time -> Html a



On Sat, Oct 22, 2016 at 3:43 PM, Brian Marick  wrote:

> My app currently has three logically/visually distinct components:
>
>
> The IV drip apparatus (upper left) is something that will be used in more
> than one page. I’ve been trying to find a way to make it a component that I
> can reuse, and I’ve been having a good deal of trouble (mostly, I’m
> embarrassed to confess, due to the type checker slapping me down). I’d much
> appreciate pointers to projects I can mine for ideas, patterns, templates.
>
> --
> 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] How to model a transient state?

[Nick H]

What if you added a third value to the ReadState type?

type ReadState = Read | Unread | Marked

Then your filtered view will show both Unread and Marked. When the user
refreshes, you can map all the Marked items to Read.

On Thu, Oct 20, 2016 at 12:43 AM, Jacky See  wrote:

> My current approach is to have a `readStateToBe` which contains the
> pending update state.
> and 'flush update' (write `readStateToBe` to `readState`) on appropriate
> update branch (e.g. switching filter).
>
> --
> 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] How to write function that updates arbitrary element of a record

[Nick H]

This kind of problem (access to arbitrary elements) is usually better
solved by a Dict than a record. In this case, you could try something like:

type NumberText = FloatText String | IntText String

type alias Model = Dict Key NumberText

type Msg = UpdateField Key String

update : Msg -> Model -> Model
update msg model =
case msg of
UpdateField key string ->
updateIfValid key string model

updateIfValid : Key -> String -> Model -> Model
updateIfValid key newString model =
case Dict.get key model of
Nothing ->
model

Just (IntText _) ->
if isValidIntString newString then
Dict.insert key (IntText newString) model
else
model

Just (FloatText _) ->
if isValidIntString newString then
Dict.insert key (FloatText newString) model
else
model

There is probably a clever way of removing the duplication in
updateIfValid. But the important thing is, this is not going to grow larger
the more fields that get added!

On Wed, Oct 19, 2016 at 8:18 AM, Brian Marick  wrote:

> I see I left out a required argument from what I want, which leads me to
> this:
>
>
> update : Msg -> Model -> Model
> update msg model =
>   case msg of
> ChangedDripText string ->
>   updateWhen model isValidFloatString dripText string
> ChangedHoursText string ->
>   updateWhen model isValidIntString simulationHoursText string
> ChangedMinutesText string ->
>   updateWhen model isValidIntString simulationMinutesText string
>
> dripText model val =
>   { model | dripText = val }
> simulationHoursText model val =
>   { model | simulationHoursText = val }
> simulationMinutesText model val =
>   { model | simulationMinutesText = val }
>
> updateWhen : Model -> (String -> Bool) -> (Model -> String -> Model)
> -> String -> Model
> updateWhen model pred updater candidate =
>   if pred candidate then
> updater model candidate
>   else
> model
>
>
>
> … which is OK, but doesn’t take me to my happy place.
>
> --
> 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] why no more primes on 0.18 ?

[Nick H]

Oh no, sorry for being confusing. You are 100% correct. That was a reaction
to myself having made such a silly mistake :-)

On Wed, Oct 19, 2016 at 5:04 AM, Janis Voigtländer <
janis.voigtlaen...@gmail.com> wrote:

> Nick, can you elaborate on why you think that my statement that foo
> `function` bar corresponds to bar |> function foo rather than foo |>
> function bar is wrong?
> ​
>
> 2016-10-19 9:55 GMT+02:00 Nick H <falling.maso...@gmail.com>:
>
>> N
>>
>> On Wed, Oct 19, 2016 at 12:34 AM, Janis Voigtländer <
>> janis.voigtlaen...@gmail.com> wrote:
>>
>>>
>>> 2016-10-19 9:27 GMT+02:00 Nick H <falling.maso...@gmail.com>:
>>>
>>>> The only situation where backticks are useful is when you are doing a
>>>> single function call, and "foo `function` bar" is easier to read than 
>>>> "function
>>>> foo bar". I haven't seen this crop up too many times. But if it does, "foo
>>>> |> function bar" is just as good.
>>>>
>>>
>>>
>>> Except, "foo |> function bar" would be wrong. It would have to be "bar
>>> |> function foo". :-)
>>>
>>> --
>>> 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.
>

-- 
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] why no more primes on 0.18 ?

[Nick H]

N

On Wed, Oct 19, 2016 at 12:34 AM, Janis Voigtländer <
janis.voigtlaen...@gmail.com> wrote:

>
> 2016-10-19 9:27 GMT+02:00 Nick H <falling.maso...@gmail.com>:
>
>> The only situation where backticks are useful is when you are doing a
>> single function call, and "foo `function` bar" is easier to read than 
>> "function
>> foo bar". I haven't seen this crop up too many times. But if it does, "foo
>> |> function bar" is just as good.
>>
>
>
> Except, "foo |> function bar" would be wrong. It would have to be "bar |>
> function foo". :-)
>
> --
> 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] why no more primes on 0.18 ?

[Nick H]

Re: primes. Totally agree with Peter. One prime is kinda nice for a
temporary variable, but beyond that... you can add a short word to your
variable name, and then you won't have to do any counting!

Re: backticks.

Evan's explanation from elm-dev:

The backtick syntax is neat, but ultimately, it is redundant. In practice,
> it is recommended against in every case, with the one exception of andThen.


My take on this: Backticks are not needed because they are redundant with
the forward pipe operator.

The only situation where backticks are useful is when you are doing a
single function call, and "foo `function` bar" is easier to read than "function
foo bar". I haven't seen this crop up too many times. But if it does, "foo
|> function bar" is just as good.

If you are chaining together multiple function calls, backticks are a
disaster. The preferred way of writing functions in Elm is to put the
argument being "modified" last. That makes it easy to chain together
function with pipes. For example:

map : (a -> b) -> Maybe a -> Maybe b
something |> map multiplyByThree |> map toString |> map translateToSpanish

Functions that are designed this way can't be chained using backticks. On
the other hand, if you design a function to work with backticks, it is not
going to chain correctly with any of the other functions.

andThen : Maybe a -> (a -> Maybe b) -> Maybe b
something |> map multiplyByThree |> flip andThen actFlippantly

Because they are so rarely needed, better to remove backticks completely
and not have to worry about another `andThen` style API coming along!



On Tue, Oct 18, 2016 at 6:28 PM, mbr  wrote:

> just learned that primes and backticks won't be on elm 0.18.
>
> What are the reason for their removal?
>
> I will miss the primes quite a bit. Am I the only one here that feels this
> way ?
>
> For instance, I would have to write headerModel___ and headerModel__
> instead of headerModel''' and headerModel''
> In the prime case I count the 'while on the underscore case I will
> compare its length.
>
> at the end of the day, I will just skip the underscore and use number like
> headerModel03 and headerModel02.
>
> And my case for backticks, I understand it will make the andThen API
> easier, but why completely remove it from the language ?
>
> I guess my main question is, What is the motivation for their removal ?
>
> --
> 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] Offtopic Choo Framework

[Nick H]

What do you find hard about learning Elm? We want Elm to be friendly to
beginners. It would be helpful to hear about your experience!

On Mon, Oct 17, 2016 at 9:08 AM, António Ramos  wrote:

> Hello guys just trying to learm Elm but its not easy.
> I just found this js framework
>
> https://github.com/yoshuawuyts/choo
>
> i has the same concept as TEA
>
> subscriptions , model, update and messages
>
> Maybe i just learn it too, because i just feel that going back to
> angular/react/vue is giving up in good and simple  ideas from ELM
>
>
> Regards
> António
>
> --
> 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] Updating an image in the view.

[Nick H]

The URL can be changed dynamically, but if it doesn't change, you don't
have to worry about the program re-generating the img element 30 times a
second... that sort of thing gets optimized by the Virtual DOM.

On Mon, Sep 26, 2016 at 8:50 PM, Nick H <falling.maso...@gmail.com> wrote:

> You can use a src
> <http://package.elm-lang.org/packages/elm-lang/html/1.1.0/Html-Attributes#src>
> attribute, just like in plain ol' HTML.
>
> img [ src "http://imagesrc.jpg; ] []
>
>
>
>
> On Mon, Sep 26, 2016 at 4:47 PM, Redvers Davies <r...@infect.me> wrote:
>
>> I'd be happy to use an img element but I'm not sure how to get the image
>> data into that img element.
>>
>> On Monday, September 26, 2016 at 7:18:33 PM UTC-4, Nick H wrote:
>>>
>>> If all you are doing is loading an image from a URL, why don't you use
>>> an img
>>> <http://package.elm-lang.org/packages/elm-lang/html/1.1.0/Html#img>
>>> element? Canvas sounds like overkill.
>>>
>>> On Sun, Sep 25, 2016 at 7:16 PM, Redvers Davies <r...@infect.me> wrote:
>>>
>>>>
>>>> I'm still too early in elm to know the correct question to ask so in
>>>> the interests of avoiding the XY problem I'm just going to describe my
>>>> end-goal and ask for the best approach to achieve it.
>>>>
>>>> I have (what I think is) an interesting use-case where I want to model
>>>> on a webpage a physical device.  The device itself is effectively a
>>>> graphical dumb-terminal which just renders to its small screen the image
>>>> that it's been sent over the network.
>>>>
>>>> What I'm hoping to get elm to do is to have, I guess, an image (or
>>>> canvas) in my view which, on receiving image data via a websocket would
>>>> then cause the view to then render that specific image in the same location
>>>> (ie, DOM object).
>>>>
>>>> I've looked at Canvas and it appears I can do it if I pass a URL via
>>>> websocket but that would initiate a separate query for the img data (via
>>>> Graphics.Element image).  As the hardware is capable of 30fps I don't
>>>> really want to trigger 30 requests per second in addition to the websocket
>>>> per simulation.  Maybe it's possible to use Data URIs but I've not really
>>>> been successful with that either.
>>>>
>>>> I know it's not the most efficient way of 'making a UI', but it's
>>>> purpose isn't performance - it's purpose is to model the functionality of
>>>> the hardware interface as closely as possible,
>>>>
>>>> Any pointers in the right direction appreciated.
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Red
>>>>
>>>> --
>>>> 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] Updating an image in the view.

[Nick H]

You can use a src
<http://package.elm-lang.org/packages/elm-lang/html/1.1.0/Html-Attributes#src>
attribute, just like in plain ol' HTML.

img [ src "http://imagesrc.jpg; ] []




On Mon, Sep 26, 2016 at 4:47 PM, Redvers Davies <r...@infect.me> wrote:

> I'd be happy to use an img element but I'm not sure how to get the image
> data into that img element.
>
> On Monday, September 26, 2016 at 7:18:33 PM UTC-4, Nick H wrote:
>>
>> If all you are doing is loading an image from a URL, why don't you use an
>> img <http://package.elm-lang.org/packages/elm-lang/html/1.1.0/Html#img>
>> element? Canvas sounds like overkill.
>>
>> On Sun, Sep 25, 2016 at 7:16 PM, Redvers Davies <r...@infect.me> wrote:
>>
>>>
>>> I'm still too early in elm to know the correct question to ask so in the
>>> interests of avoiding the XY problem I'm just going to describe my end-goal
>>> and ask for the best approach to achieve it.
>>>
>>> I have (what I think is) an interesting use-case where I want to model
>>> on a webpage a physical device.  The device itself is effectively a
>>> graphical dumb-terminal which just renders to its small screen the image
>>> that it's been sent over the network.
>>>
>>> What I'm hoping to get elm to do is to have, I guess, an image (or
>>> canvas) in my view which, on receiving image data via a websocket would
>>> then cause the view to then render that specific image in the same location
>>> (ie, DOM object).
>>>
>>> I've looked at Canvas and it appears I can do it if I pass a URL via
>>> websocket but that would initiate a separate query for the img data (via
>>> Graphics.Element image).  As the hardware is capable of 30fps I don't
>>> really want to trigger 30 requests per second in addition to the websocket
>>> per simulation.  Maybe it's possible to use Data URIs but I've not really
>>> been successful with that either.
>>>
>>> I know it's not the most efficient way of 'making a UI', but it's
>>> purpose isn't performance - it's purpose is to model the functionality of
>>> the hardware interface as closely as possible,
>>>
>>> Any pointers in the right direction appreciated.
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Red
>>>
>>> --
>>> 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] Updating an image in the view.

[Nick H]

If all you are doing is loading an image from a URL, why don't you use an
img 
element? Canvas sounds like overkill.

On Sun, Sep 25, 2016 at 7:16 PM, Redvers Davies  wrote:

>
> I'm still too early in elm to know the correct question to ask so in the
> interests of avoiding the XY problem I'm just going to describe my end-goal
> and ask for the best approach to achieve it.
>
> I have (what I think is) an interesting use-case where I want to model on
> a webpage a physical device.  The device itself is effectively a graphical
> dumb-terminal which just renders to its small screen the image that it's
> been sent over the network.
>
> What I'm hoping to get elm to do is to have, I guess, an image (or canvas)
> in my view which, on receiving image data via a websocket would then cause
> the view to then render that specific image in the same location (ie, DOM
> object).
>
> I've looked at Canvas and it appears I can do it if I pass a URL via
> websocket but that would initiate a separate query for the img data (via
> Graphics.Element image).  As the hardware is capable of 30fps I don't
> really want to trigger 30 requests per second in addition to the websocket
> per simulation.  Maybe it's possible to use Data URIs but I've not really
> been successful with that either.
>
> I know it's not the most efficient way of 'making a UI', but it's purpose
> isn't performance - it's purpose is to model the functionality of the
> hardware interface as closely as possible,
>
> Any pointers in the right direction appreciated.
>
> Thanks,
>
>
>
> Red
>
> --
> 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: pattern matching on a field within a record

[Nick H]

Re: your initial post... you could rewrite the code as

case Maybe.map .cell c of
  Just (Letter s) ->
s
  _ ->
""

Don't know if that's any easier to read, though.

Regarding null_square: If you want to make sure that null_square is passed
by reference, you can define it as a top-level value. (That said, the
record is so small, I doubt it would make a noticeable performance
difference, unless you're planning on making a gazillion of them.)


On Sat, Sep 24, 2016 at 1:44 PM, Martin DeMello 
wrote:

> Don't think that will work because c is of type Maybe Square, not Maybe
> Cell.
>
> One further question - if I define
>
> let null_square = { cell = Empty, num = 0 }
>
> let get_square maybe_square =
>   case maybe_cell of
> Nothing: null_square
> Just s : s
>
> let get_letter maybe_square =
>   case maybe_square of
> { Letter s } -> s
> _ -> ""
>
> would that be introducing an inefficient creation of a null_square every
> time I call get_letter or is it just a cheap reference?
>
> martin
>
> On Fri, Sep 23, 2016 at 12:04 PM, Simon  wrote:
>
>> This should work
>>
>>  case c of
>> Just (Letter s) ->
>>   s
>> _ -> ""
>>
>>
>>
>> On Friday, 23 September 2016 03:50:19 UTC+2, Martin DeMello wrote:
>>>
>>> If I have the following code:
>>>
>>> type Cell = Empty | Letter String
>>>
>>> type alias Square =
>>>   { cell : Cell
>>>   , num : Int
>>>   }
>>>
>>> and c : Maybe Square,
>>>
>>> can I do the following in a single match?
>>>
>>>   case c of
>>> Just { cell } ->
>>>   case cell of
>>> Letter s -> s
>>> _ -> ""
>>> _ -> ""
>>>
>>> that is, i conceptually want
>>>
>>>   case c of
>>> Just { cell = Letter s } -> s
>>> _ -> ""
>>>
>>> martin
>>>
>> --
>> 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.