[elm-discuss] Should parsing code be integrated into Elm using port, managed effects, or native modules?

[Wil C]

I currently have a js library that will parse code and return either the 
html (render) or the AST (abstract syntax tree). The AST action per node is 
modifiable. I'd like use it in the following way:

For a single node type in the AST, I want to process it (rather than just 
rendering it to Html)
For every other node type, I want it to render Html, which the library does 
by default.

I'm curious about how to do the integration with Elm here. Should I use 
ports, managed effect module (like Time module), or a native module (like 
Http module)?

The guide discourages managed effects. If that's the solution here, I'm 
open to doing it.

Writing native modules seem like reaching into private interfaces and will 
cause me trouble down the line when new versions of elm come out. But in 
all the Html and Markdown modules I've seen, it just uses Native modules, 
presumably to avoid pitfall #2 below.

Hence, I think I need to use Ports. The easy part is sending a String of 
code into the port for parsing. I see two pitfalls with this approach:

   1. When I get back the single node type in the AST, I'd need to pass it 
   back to Elm as a JSON, and write a decoder to parse it. That seems like a 
   lot of work (Decoders take me a long time to write).
   2. For AST nodes rendered as Html, if I don't pass them back into Elm, I 
   assume that Elm wouldn't be able to do shadow dom diffing on it for 
   rendering. If I do pass them back into Elm, I'd have to write an Elm 
   Decoder from JSON into Html Msg, and that seems like a lot of work.

So what's the best way to tackle this? Is parsing a side effect? Would it 
make sense if this was a managed effect?

Wil

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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 inherited from Haskell, like a lot of other stuff. Doubt
>> if there
>> >> was any other thought put into it if I'm honest.
>> >>
>> >> On Monday

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

[Austin Bingham]

This article really opened my eyes to the possibilities of lenses and their
interaction with the Return monad:
https://toast.al/posts/2016-10-20-optical-swordplay-with-components.html

Definitely worth a read.

On Tue, Nov 22, 2016 at 8:17 PM Nick H  wrote:

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

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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?

[David Andrews]

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 inherited from Haskell, like a lot of other stuff. Doubt
> if there
> >> was any other thought put into it if I'm honest.
> >>
> >> On Monday, 21 November 2016 14:46:40 UTC, Will White wrote:
> >>>
> >>> Sorry, meant to say “I guess he’s already considered and rejected
> them”.
> >>>
> >>> On 21 Nov 2016, at 14:21, Will White  wrote:
> >>>
> >>> I prefer Some or None, for understanding. Though, unless Evan
> didn’t know
> >>> about them, I guess we’d already have them.
> >>>
> >>> On 20 Nov 2016, at 23:41, Robin Heggelund Hansen <
> skinn...@gmail.com>
> >>> wrote:
> >>>
> >>> How about 'Some' and 'No

Re: [elm-discuss] Re: Unpublishing a package

[Martin DeMello]

It's not a question of being antisocial or uncivilised; it's that it is
really hard to say "I just want to patch this for 0.18 and continue using
it in my project" without having globally visible effects. It is
unreasonable to expect someone to wait for the package maintainer to do the
update and have the only real recourse be to pester them until they do.
Local repos would fix that once and for all; the automated safeguard could
be that you cannot publish a package to global if it depends on a local
repo.

martin

On Tue, Nov 22, 2016 at 3:12 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> What about the issue of people forking and re-publishing packages (and
> ignoring the tests), because they are too impatient/anti-social to go about
> things in more civilized manner? Do there need to be stricter controls for
> getting stuff into the repo? Do we need or can we manage some kind of
> cummunity oversight? Or is this unnecessary at this stage and its not
> really such an issue?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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 experience - proposal for additions to List and Random core libraries

[Janis Voigtländer]

Have you seen what is written at the following location?

https://github.com/elm-lang/core/blob/master/CONTRIBUTING.md#adding-new-functions


> Am 22.11.2016 um 17:21 schrieb Martin Cerny :
> 
> Hi all,
> I am currently about 3 side projects (small games) deep in Elm and the 
> experience has been overally very good. I however encountered a few simple 
> things I missed in the core libraries, so I would like to ask, if there is a 
> reason to not have them there. If not, I'll be happy to file a pull request 
> with them :-) 
> 
> So here they are, in order of decreasing importance (IMHO)
> 
> 1) List.get : Int -> List a -> Maybe a
>  Just a way to get the nth element of a linked list in O(n) time. (the 
> signature mimics that of Array.get). I know this exists in 
> http://package.elm-lang.org/packages/circuithub/elm-list-extra/3.10.0/List-Extra
>  but seems important enough to have it in the core.
> 
> 2) Random.constant : a -> Generator a
> A generator that is not really a generator, but returns a fixed value. This 
> is useful for composing generators with Random.map and Random.andThen or for 
> the base case of recursive generators. An example use case is if I want to 
> pick a value that is zero 50% percent of the time and 1-5 otherwise (happened 
> in my game a few times)
> This one is already present in 
> http://package.elm-lang.org/packages/mgold/elm-random-pcg/latest/Random-Pcg 
> which, according to https://github.com/elm-lang/core/issues/724 should 
> replace the core Random in the future, but why not add it now :-)
> 
> generateValue : Bool -> Generator Float
> generateValue isZero =
>   if isZero then Random.constant 0 else Random.float 1 5
> 
> 
> Random.bool |> Random.andThen generateValue
> 
> it also lets you write things like (which is probably not a very common use 
> case, but came in handy for me):
> 
> listOfGeneratorsToGeneratorOfList : List (Random.Generator a) -> 
> Random.Generator (List a)
> listOfGeneratorsToGeneratorOfList listOfGenerators =
> case listOfGenerators of
> head :: tail ->
> Random.andThen
> (listOfGeneratorsToGeneratorOfList tail)
> (\list -> Random.map (\x -> x :: list) head)
> 
> [] ->
> Random.constant []
> 
> currently, you can declare constant generator like this, but it seems stupid 
> and wasteful:
> 
> constant : a -> Random.Generator a
> constant value =
> Random.map (\_ -> value) Random.bool
> 
> 3) Random.permutation : List a -> Generator (List a)
> This would simply pick a permutation of the original list at random. Might 
> make sense to write this in javascript via converstion to array, as the O(n) 
> algorithm (Knuth shuffle) for this does not seem to translate well into pure 
> functional world...  I currently do not see a purely functional 
> implementation that is not O(n^2), but I'll be happy to be proven wrong :-)
> 
> I understand that it is important to keep the core library slim (especially 
> until dead code elimination is brought to Elm), so which of those you think 
> should make the cut?
> 
> Looking forward to your ideas
> Martin Černý
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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 experience - proposal for additions to List and Random core libraries

[Max Goldstein]

I think List.get has been avoided since it seems imperative, and requires 
the use of Maybes. If you expect an item to be there, use a different data 
structure, or use an Array which has better time complexity.

I agree completely on Random.constant.

Random.permutation is available in random-extra 

 
as shuffle. It takes O(n log n) time because it converts it to an array 
first. But it's certainly possible the author of the function -- me -- made 
a mistake.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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: 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.

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

[Rex van der Spuy]

Thanks so much for explaining that.

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

Re: [elm-discuss] Elm experience - proposal for additions to List and Random core libraries

[Martin Cerny]

And I thought I have found and read all the relevant documents before 
posting :-) 

Thanks, that makes total sense.
Martin

On Tuesday, 22 November 2016 17:33:45 UTC+1, Janis Voigtländer wrote:
>
> Particularly the last two paragraphs. 
>
> Am 22.11.2016 um 17:32 schrieb Janis Voigtländer  >:
>
> Have you seen what is written at the following location?
>
>
> https://github.com/elm-lang/core/blob/master/CONTRIBUTING.md#adding-new-functions
>  
> 
>
>
> Am 22.11.2016 um 17:21 schrieb Martin Cerny  >:
>
> Hi all,
> I am currently about 3 side projects (small games) deep in Elm and the 
> experience has been overally very good. I however encountered a few simple 
> things I missed in the core libraries, so I would like to ask, if there is 
> a reason to not have them there. If not, I'll be happy to file a pull 
> request with them :-) 
>
> So here they are, in order of decreasing importance (IMHO)
>
> 1) List.get : Int -> List a -> Maybe a
>  Just a way to get the nth element of a linked list in O(n) time. (the 
> signature mimics that of Array.get). I know this exists in 
> http://package.elm-lang.org/packages/circuithub/elm-list-extra/3.10.0/List-Extra
>  
> but seems important enough to have it in the core.
>
> 2) Random.constant : a -> Generator a
> A generator that is not really a generator, but returns a fixed value. 
> This is useful for composing generators with Random.map and Random.andThen 
> or for the base case of recursive generators. An example use case is if I 
> want to pick a value that is zero 50% percent of the time and 1-5 otherwise 
> (happened in my game a few times)
> This one is already present in 
> http://package.elm-lang.org/packages/mgold/elm-random-pcg/latest/Random-Pcg 
> which, according to https://github.com/elm-lang/core/issues/724 should 
> replace the core Random in the future, but why not add it now :-)
>
> generateValue : Bool -> Generator Float
> generateValue isZero =
>   if isZero then Random.constant 0 else Random.float 1 5
>
>
> Random.bool |> Random.andThen generateValue
>
> it also lets you write things like (which is probably not a very common 
> use case, but came in handy for me):
>
> listOfGeneratorsToGeneratorOfList : List (Random.Generator a) -> 
> Random.Generator (List a)
> listOfGeneratorsToGeneratorOfList listOfGenerators =
> case listOfGenerators of
> head :: tail ->
> Random.andThen
> (listOfGeneratorsToGeneratorOfList tail)
> (\list -> Random.map (\x -> x :: list) head)
>
> [] ->
> Random.constant []
>
> currently, you can declare constant generator like this, but it seems 
> stupid and wasteful:
>
> constant : a -> Random.Generator a
> constant value =
> Random.map (\_ -> value) Random.bool
>
> 3) Random.permutation : List a -> Generator (List a)
> This would simply pick a permutation of the original list at random. Might 
> make sense to write this in javascript via converstion to array, as the 
> O(n) algorithm (Knuth shuffle) for this does not seem to translate well 
> into pure functional world...  I currently do not see a purely functional 
> implementation that is not O(n^2), but I'll be happy to be proven wrong :-)
>
> I understand that it is important to keep the core library slim 
> (especially until dead code elimination is brought to Elm), so which of 
> those you think should make the cut?
>
> Looking forward to your ideas
> Martin Černý
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

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

Re: [elm-discuss] Elm experience - proposal for additions to List and Random core libraries

[Janis Voigtländer]

Particularly the last two paragraphs. 

> Am 22.11.2016 um 17:32 schrieb Janis Voigtländer 
> :
> 
> Have you seen what is written at the following location?
> 
> https://github.com/elm-lang/core/blob/master/CONTRIBUTING.md#adding-new-functions
> 
> 
>> Am 22.11.2016 um 17:21 schrieb Martin Cerny :
>> 
>> Hi all,
>> I am currently about 3 side projects (small games) deep in Elm and the 
>> experience has been overally very good. I however encountered a few simple 
>> things I missed in the core libraries, so I would like to ask, if there is a 
>> reason to not have them there. If not, I'll be happy to file a pull request 
>> with them :-) 
>> 
>> So here they are, in order of decreasing importance (IMHO)
>> 
>> 1) List.get : Int -> List a -> Maybe a
>>  Just a way to get the nth element of a linked list in O(n) time. (the 
>> signature mimics that of Array.get). I know this exists in 
>> http://package.elm-lang.org/packages/circuithub/elm-list-extra/3.10.0/List-Extra
>>  but seems important enough to have it in the core.
>> 
>> 2) Random.constant : a -> Generator a
>> A generator that is not really a generator, but returns a fixed value. This 
>> is useful for composing generators with Random.map and Random.andThen or for 
>> the base case of recursive generators. An example use case is if I want to 
>> pick a value that is zero 50% percent of the time and 1-5 otherwise 
>> (happened in my game a few times)
>> This one is already present in 
>> http://package.elm-lang.org/packages/mgold/elm-random-pcg/latest/Random-Pcg 
>> which, according to https://github.com/elm-lang/core/issues/724 should 
>> replace the core Random in the future, but why not add it now :-)
>> 
>> generateValue : Bool -> Generator Float
>> generateValue isZero =
>>   if isZero then Random.constant 0 else Random.float 1 5
>> 
>> 
>> Random.bool |> Random.andThen generateValue
>> 
>> it also lets you write things like (which is probably not a very common use 
>> case, but came in handy for me):
>> 
>> listOfGeneratorsToGeneratorOfList : List (Random.Generator a) -> 
>> Random.Generator (List a)
>> listOfGeneratorsToGeneratorOfList listOfGenerators =
>> case listOfGenerators of
>> head :: tail ->
>> Random.andThen
>> (listOfGeneratorsToGeneratorOfList tail)
>> (\list -> Random.map (\x -> x :: list) head)
>> 
>> [] ->
>> Random.constant []
>> 
>> currently, you can declare constant generator like this, but it seems stupid 
>> and wasteful:
>> 
>> constant : a -> Random.Generator a
>> constant value =
>> Random.map (\_ -> value) Random.bool
>> 
>> 3) Random.permutation : List a -> Generator (List a)
>> This would simply pick a permutation of the original list at random. Might 
>> make sense to write this in javascript via converstion to array, as the O(n) 
>> algorithm (Knuth shuffle) for this does not seem to translate well into pure 
>> functional world...  I currently do not see a purely functional 
>> implementation that is not O(n^2), but I'll be happy to be proven wrong :-)
>> 
>> I understand that it is important to keep the core library slim (especially 
>> until dead code elimination is brought to Elm), so which of those you think 
>> should make the cut?
>> 
>> Looking forward to your ideas
>> Martin Černý
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and 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?

[Will White]

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 
>  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 opsb.co.uk 
>> > 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 wouldmake 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 gmail.com 
>>> > 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 inherited from Haskell, like a lot of other stuff. Doubt if 
>>> >> there 
>>> >> was any other thought put into it if I'm honest. 
>>> >> 
>>> >> On Monday, 21 November 2016 14:46:40 UTC, Will White wrote: 
>>> >>> 
>>> >>> Sorry, meant to say “I guess he’s already considered and rejected 
>>> >>> them”. 
>>> >>> 
>>> >>> On 21 Nov 2016, at 14:21, Will White > wrote: 
>>> >>> 
>>> >>> I prefer Some or None, for understanding. Though, unless Evan didn’t 
>>> >>> know 
>>> >>> about them, I guess we’d already have them. 
>>> >>> 
>>> >>> On 20 Nov 2016, at 23:41, Robin Heggelund Hansen >> >>> <>> 
>>> >>> wrote: 
>>> >>> 
>>> >>> How about 'Some' and 'None'? 
>>> >>> Those are not longer to type than what we have today, and they should 
>>> >>> solve your initial confusion. 
>>> >>> 
>>> >>> søndag 20. november 2016 18.16.26 UTC+1 skrev Will White følg

[elm-discuss] Elm experience - proposal for additions to List and Random core libraries

[Martin Cerny]

Hi all,
I am currently about 3 side projects (small games) deep in Elm and the 
experience has been overally very good. I however encountered a few simple 
things I missed in the core libraries, so I would like to ask, if there is 
a reason to not have them there. If not, I'll be happy to file a pull 
request with them :-) 

So here they are, in order of decreasing importance (IMHO)

1) List.get : Int -> List a -> Maybe a
 Just a way to get the nth element of a linked list in O(n) time. (the 
signature mimics that of Array.get). I know this exists in 
http://package.elm-lang.org/packages/circuithub/elm-list-extra/3.10.0/List-Extra
 
but seems important enough to have it in the core.

2) Random.constant : a -> Generator a
A generator that is not really a generator, but returns a fixed value. This 
is useful for composing generators with Random.map and Random.andThen or 
for the base case of recursive generators. An example use case is if I want 
to pick a value that is zero 50% percent of the time and 1-5 otherwise 
(happened in my game a few times)
This one is already present in 
http://package.elm-lang.org/packages/mgold/elm-random-pcg/latest/Random-Pcg 
which, according to https://github.com/elm-lang/core/issues/724 should 
replace the core Random in the future, but why not add it now :-)

generateValue : Bool -> Generator Float
generateValue isZero =
  if isZero then Random.constant 0 else Random.float 1 5


Random.bool |> Random.andThen generateValue

it also lets you write things like (which is probably not a very common use 
case, but came in handy for me):

listOfGeneratorsToGeneratorOfList : List (Random.Generator a) -> 
Random.Generator (List a)
listOfGeneratorsToGeneratorOfList listOfGenerators =
case listOfGenerators of
head :: tail ->
Random.andThen
(listOfGeneratorsToGeneratorOfList tail)
(\list -> Random.map (\x -> x :: list) head)

[] ->
Random.constant []

currently, you can declare constant generator like this, but it seems 
stupid and wasteful:

constant : a -> Random.Generator a
constant value =
Random.map (\_ -> value) Random.bool

3) Random.permutation : List a -> Generator (List a)
This would simply pick a permutation of the original list at random. Might 
make sense to write this in javascript via converstion to array, as the 
O(n) algorithm (Knuth shuffle) for this does not seem to translate well 
into pure functional world...  I currently do not see a purely functional 
implementation that is not O(n^2), but I'll be happy to be proven wrong :-)

I understand that it is important to keep the core library slim (especially 
until dead code elimination is brought to Elm), so which of those you think 
should make the cut?

Looking forward to your ideas
Martin Černý

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

[elm-discuss] Re: Tell me how to teach Web Apps

[Juan Soto]

I'd stick to JavaScript. It'll help them get jobs, it's what they'll use at 
work, and will equip them the best for doing their own projects 
(particularly Node). A semester is a lot shorter than you think, but you 
can mention Elm at the end if you want.

I honestly see no benefit of teaching it in Elm or TypeScript aside from 
personal preference.

On Monday, November 21, 2016 at 6:23:56 PM UTC-5, Robert Muller wrote:
>
> I'm teaching a full-semester course on Web Apps this spring. It's my first 
> time through so I have a lot to learn. I'm a long-time functional 
> programmer (mostly ML: SML & OCaml). If I wasn't worried about my students 
> getting jobs and internships the choice would be obvious: I'd teach Elm! 
> But the students are taking the course to get jobs and internships and I 
> have to respect that so I'm looking for advice.
> A couple of former students in industry tell me that I definitely need to 
> cover back-end issues. So I'm considering teaching the front 3/4 of the 
> course using Node.js + React.js and then integrating Elm in the advanced 
> topics part during the last 1/4 might be reasonable.
>
> But maybe not. Please tell share your thoughts with me!
>
> Bob Muller
> Boston College
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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 Javascript to start Elm app be attached per page?

[OvermindDL1]

Awesome, you should post that in the elm section of the ElixirForums too so 
both sides can see it!  :-)


On Monday, November 21, 2016 at 5:52:59 PM UTC-7, Brian Marick wrote:
>
> I figured out how to make it work, thanks to your help. Because there are 
> some fiddly bits, I wrote up a blog post that points to a frozen branch 
> that might help others. It’s here:
>
> http://blog.roundingpegs.com/phoenix-elm-and-multiple-single-page-apps/
>
>
> On Nov 21, 2016, at 11:43 AM, OvermindDL1  > wrote:
>
> A few things (as I do use elm with phoenix):
>
> 1. Make sure the script tag is loaded before you load a page specific call 
> like require or so (my script sends a 'js-loaded' event when done that my 
> pages can listen to if it is not already sent, a simple function in the 
> head can simplify that to a single call).
> 2. I like to pack all my elm apps into a single file (which is then 
> stuffed inside app.js and minimized and such).  My individual pages just 
> call `require("web/static/elm.js").whateverApp.embed(blah);`, thus the 
> individual pages determine what they call, not a lot of checks in the 
> javascript.  :-)
>
>
> On Sunday, November 20, 2016 at 4:31:15 PM UTC-7, Brian Marick wrote:
>>
>> Note: newbie to Javascript and frontend in general. 
>>
>> TL/DR: I would like to see an example of the Best Way to (1) have N urls 
>> invoke N single-page Elm apps, and (2) pass each of them url-specific flags 
>> (to be received by  `Html.App.programWithFlags`). 
>>
>> - 
>>
>> The Elixir/Phoenix book [1] suggests having a single “app.js” file, 
>> compiled by Brunch. Part of the code compiled into that single file 
>> contains specific tests of the form “Am I on the page where behavior X is 
>> appropriate? If so, run this (page-specific) code to cause behavior X.” 
>> Given that my code for X is written in Elm, the source for the Brunch 
>> compilation contains code like this: 
>>
>> import Elm from './critter4us' 
>>
>> const ivDiv = document.querySelector('#iv-target'); 
>> if (ivDiv) { 
>> Elm.IV.embed(ivDiv); 
>> } 
>>
>> const animalsDiv = document.querySelector('#animals-target'); 
>> if (animalsDiv) { 
>>  Elm.Animals.embed(animalsDiv, { 
>> authToken: window.auth_token, 
>> }); 
>> } 
>>
>> // etc. 
>>
>> Note that the arguments are passed to Elm by cramming them into global 
>> variables before the “app.js” file is loaded. That is: 
>>
>> window.auth_token = "<%= assigns[:auth_token] %>" 
>> "> 
>>
>> --- 
>>
>> I can imagine having a whole sequence of such `if` tests in the master 
>> javascript file, one for each Elm-enabled page. But that seems really 
>> convoluted. It seems it would be better for each page to request a single 
>> library (app.js, loaded from cache), then have a snippet of code that 
>> launches the Elm app. 
>>
>> That is, following: 
>>
>> "> 
>>
>> would be a page-specific: 
>>
>>  
>>   Elm.Animals.embed("#animals-target", { 
>>   authToken: “fe9c6177-02df-4510-88fd-4c1bbe023d16", 
>>   …} 
>>  
>>
>> (Note: no need to cram values into `window`.) 
>>
>> But I can’t make that work. Can someone point me to examples? 
>>
>>
>> ——— 
>>
>> [1] https://pragprog.com/book/phoenix/programming-phoenix
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

[elm-discuss] Re: Tell me how to teach Web Apps

[OvermindDL1]

I teach languages but not web programming specifically.  I'd might 
recommend Elixir as a good back-end server software to program in.  It is 
easily one of the language that are the most fun to program in, although it 
is not statically typed, it is fully functional.  I happen to use Elixir on 
the back-end and Elm on the front-end for my big server right now.


On Monday, November 21, 2016 at 4:23:56 PM UTC-7, Robert Muller wrote:
>
> I'm teaching a full-semester course on Web Apps this spring. It's my first 
> time through so I have a lot to learn. I'm a long-time functional 
> programmer (mostly ML: SML & OCaml). If I wasn't worried about my students 
> getting jobs and internships the choice would be obvious: I'd teach Elm! 
> But the students are taking the course to get jobs and internships and I 
> have to respect that so I'm looking for advice.
> A couple of former students in industry tell me that I definitely need to 
> cover back-end issues. So I'm considering teaching the front 3/4 of the 
> course using Node.js + React.js and then integrating Elm in the advanced 
> topics part during the last 1/4 might be reasonable.
>
> But maybe not. Please tell share your thoughts with me!
>
> Bob Muller
> Boston College
>

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

[elm-discuss] Re: highlight.js and elm code

[OvermindDL1]

As I recall highlightjs is heavily based on regex, which makes parsing a 
lot of things interesting and people have to handle the odd edge cases like 
that, which it probably is not.  I use highlightjs as well and it is 
painful on about every language...

On Monday, November 21, 2016 at 4:17:08 PM UTC-7, Brian Marick wrote:
>
> I recently installed highlight.js (http://highlightjs.readthedocs.io) on 
> my blog. It’s supposed to understand Elm code, but the results are not 
> appealing:
>
>
> Given the same thing happens with Haskell code, I suspect I’m doing 
> something wrong. Any advice or experience? 
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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: Passing properties as arguments to messages?

[Austin Bingham]

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.

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

[Wouter In t Velt]

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.

Re: [elm-discuss] Proposed addition for Task package

[Charlie Koster]

>
> The log then shows that between the DoStuff message and the DoMore 
> message, a Tick message comes in.
>

Well, that's troubling and undermines my assumption. That's for looking 
into this.

For those skimming through this post, *race conditions are possible when 
doing something like `*Task.perform (\_ -> GoToLoginPage) (Task.succeed 
Nothing)`

The fact that we do not agree on this, makes it an interesting discussion 
> here.

Where do others stand on 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.

Re: [elm-discuss] Can't install native package using elm-github-install

['Rupert Smith' via Elm Discuss]

On Tuesday, November 22, 2016 at 4:59:22 AM UTC, Gusztáv Szikszai wrote:
>
> I think you are looking for something like this: 
> https://github.com/gdotdesign/elm-ui/blob/master/source/Ui/Helpers/Emitter.elm
>  
> It's a pure Elm pub / sub effects module (and possibly the most minimal 
> example of an effect module).
>

I hope this ok by you, but I extracted your Emitter and put it up as its 
own minimal module here:

https://github.com/rupertlssmith/elmq

I took a version a few iterations behind your HEAD, as I currently need 
0.17 and also to not include your Native.File stuff to make it standalone.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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

[Wouter In t Velt]

For those interested: here is the example I refered to:
import Html exposing (..)
import Html.Events exposing (onClick)
import Time exposing (Time, second)
import Task

main =
  Html.program
{ init = init
, view = view
, update = update
, subscriptions = subscriptions
}

-- MODEL
type alias Model = { msgs : List String, timerOn : Bool }

init : (Model, Cmd Msg)
init =
  { msgs = []
  , timerOn = True
  } ! []

-- UPDATE
type Msg
  = Tick Time | DoStuff | DoMore


update : Msg -> Model -> (Model, Cmd Msg)
update msg model =
  case msg of
Tick newTime ->
  { msgs = toString msg :: model.msgs
  , timerOn = True
  } ! []
  
DoStuff ->
  { model | msgs = toString msg :: model.msgs }
  ! [ send DoMore ]
  
DoMore ->
  { model | msgs = toString msg :: model.msgs, timerOn = False } ! []
  
  
send : msg -> Cmd msg
send msg =
  Task.succeed msg
  |> Task.perform identity


-- SUBSCRIPTIONS
subscriptions : Model -> Sub Msg
subscriptions model =
  if model.timerOn then
Time.every 10 Tick
  else
Sub.none

-- VIEW
view : Model -> Html Msg
view model =
  div []
[ button [ onClick DoStuff ] [ text "click" ] 
, ul []
  <| List.map itemView model.msgs
]

itemView : String -> Html Msg
itemView string =
  li [] [ text string ]


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

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

[Rex van der Spuy]

Thanks for all your replies everyone!!
I'm glad to have confirmation that this really is impossible and it's not 
just me.

I think for now I'm just going to leave it as is.
It's nice and simple and I understand it :)

But, can anyone explain why Elm doesn't let us do 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.

Re: [elm-discuss] Proposed addition for Task package

[Wouter In t Velt]

Op dinsdag 22 november 2016 14:49:47 UTC+1 schreef Charlie Koster:
>
> My assumption is a race condition here wouldn't be possible since calling 
> `sendMsg MyMsg` is a synchronous action
>

I have tried it out in elm-lang.org/try, which suggests that it is 
asynchronous, in a simple setup
- button that sends a DoStuff message
- in update, the DoStuff branch outputs DoMore
- update also logs all messages
- the setup also contains a basic subscription to Time, with a Tick every 
10ms

The log then shows that between the DoStuff message and the DoMore message, 
a Tick message comes in.
This is an extreme example, I admit, but with subscriptions to server 
messages, mouseovers etc, there is no telling when messages come in.
So my takeaway was: if you want something done synchronously, handle it 
inside a single update cycle.

If the community agrees that using Cmd Msg as you suggest is a valid 
pattern with valid use cases, then the (simple) helper would be a useful 
addition to a Task (or Platform? or Platform.cmd) package.

The fact that we do not agree on this, makes it an interesting discussion 
here.
Where do others stand on 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.

Re: [elm-discuss] Rename Just to Something, as the counterpart to Nothing?

[Robin Heggelund Hansen]

'A itemList' ;-)

tirsdag 22. november 2016 14.06.17 UTC+1 skrev Andrew Radford følgende:
>
> 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 inherited from Haskell, like a lot of other stuff. Doubt 
> if there 
> >> was any other thought put into it if I'm honest. 
> >> 
> >> On Monday, 21 November 2016 14:46:40 UTC, Will White wrote: 
> >>> 
> >>> Sorry, meant to say “I guess he’s already considered and rejected 
> them”. 
> >>> 
> >>> On 21 Nov 2016, at 14:21, Will White  wrote: 
> >>> 
> >>> I prefer Some or None, for understanding. Though, unless Evan 
> didn’t know 
> >>> about them, I guess we’d already have them. 
> >>> 
> >>> On 20 Nov 2016, at 23:41, Robin Heggelund Hansen <
> skinn...@gmail.com> 
> >>> wrote: 
> >>> 
> >>> How about 'Some' and 'None'? 
> >>> Those are not longer to type than what we have today, and they 
> should 
> >>> solve your initial confusion. 
> >>> 
> >>> søndag 20. november 2016 18.16.26 UTC

Re: [elm-discuss] Proposed addition for Task package

[Charlie Koster]

> but I have seen terrible bugs being introduced by improper use, caused by 
> Cmd messages being created based on model state A, and because of race 
> conditions (e.g. fetch results coming in in the meantime)
>

My assumption is a race condition here wouldn't be possible since calling 
`sendMsg MyMsg` is a synchronous action and therefore would pipe through 
the Elm runtime and back into the update function immediately 
(synchronously). That's assuming that the Elm runtime doesn't do any 
setTimeouts behind the scenes that would allow for another Msg to be sent 
to the update function before MyMsg, thus making it asynchronous.

I agree that it's possible to misuse something like the above proposal, but 
I don't feel that should prevent it from going into core Task or core Cmd. 
Synchronously sending a Msg is a valid use case that Elm core could handle, 
and it does, but with less boilerplate.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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

[Wouter In t Velt]

Op dinsdag 22 november 2016 13:47:55 UTC+1 schreef Charlie Koster:
>
> I respectfully disagree. Depending on the application, this either may not 
> be possible or would be a terrible code smell. I honestly think the above 
> suggestion would be worse than chaining another Cmd msg. Sending another 
> Cmd msg is clean and follows the Elm architecture.
>
I agree it depends on the application. Sometimes `Cmd msg` would be better, 
sometimes it would be worse. `Cmd msg` follows the Elm architecture, but I 
have seen terrible bugs being introduced by improper use, caused by Cmd 
messages being created based on model state A, and because of race 
conditions (e.g. fetch results coming in in the meantime), the call that 
the elm runtime made to the update function was with model state B. (when 
using Cmd, there is NO guarantee about the state of the model that the 
runtime will pass to the update function).

When I was beginning to learn Elm, this function was not around, and it 
forced me to learn more about TEA, Tasks, runtime etcetera.
Which in hindsight was IMHO a good thing.

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

[elm-discuss] Re: Status of Elm drag-and-drop with html elements

[Simon]

Is DragNDrop still something that needs ot be implemented with Mouse. There 
seems to be so much support for dragging built into Html directly that we 
ought to be able to do things more directly in Em by now I would have 
thought?

On Wednesday, 7 September 2016 20:19:25 UTC+2, Ivan Uemlianin wrote:
>
> Dear James
>
> Thanks, that is very helpful.  Thanks both.
>
> Before today I had the impression it might not be possible at all.
>
> From both of your help, I'll try and put together (& publish) something 
> that is just bare Elm, with a html  where you can draggingly re-order 
> the s.  
>
> Best wishes
>
> Ivan
>
>
> On Wednesday, September 7, 2016 at 6:04:58 PM UTC+1, James Wilson wrote:
>>
>> Ivan alas you need the server to get as far as being able to see the DnD 
>> in practise! it's a stack/haskell thing so if you happen to be using stack 
>> it's quite straight forward (scripts/run-server.sh should do 
>> most/everything). for the client, an npm install and then npm run build 
>> should be enough to build and put it into the place run-server expects. 
>> I'll make proper instructions at some point but the App isn't quite there 
>> yet :)
>>
>> failing getting things going, looking at the code should give a fair 
>> idea. I'm basically putting elements wherever I need to to capture the 
>> relevant events (what did I click on to start a drag? what is my current 
>> drag above/below/between if anything?). a little css (dnd.scss) makes sure 
>> the drag helper elements are in the right place. the list of html my 
>> Dnd.view expects has each item paired with a unique ID String so that my 
>> drag thing can use these IDs to track where the drag currently is between 
>> and inform the outside world. It also exposes a few functions that the 
>> outside world can use to query the current Dnd model to find out about 
>> things. I use this in Main.elm to decide when and where to render an 
>> overlay and what should be in the overlay.
>>
>> It's a little rough still but seems to work really reliably so far; I was 
>> looking for a solution that didnt break if you went a bit nuts throwing the 
>> mouse around etc! It's also 100% Elm which I'm pleased with. There are def 
>> things that Elm makes difficult that I had to work around, for instance 
>> finding exactly where in the item I clicked would be nice, but it's also 
>> hard (impossible?) in Elm if the element has children, as the mousedown 
>> event target isn't always the element you care about etc.
>>
>> Anyway, hope it helps :)
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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?

['Andrew Radford' via Elm Discuss]

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 inherited from Haskell, like a lot of other stuff. Doubt if 
 there 
 >> was any other thought put into it if I'm honest. 
 >> 
 >> On Monday, 21 November 2016 14:46:40 UTC, Will White wrote: 
 >>> 
 >>> Sorry, meant to say “I guess he’s already considered and rejected 
 them”. 
 >>> 
 >>> On 21 Nov 2016, at 14:21, Will White  wrote: 
 >>> 
 >>> I prefer Some or None, for understanding. Though, unless Evan 
 didn’t know 
 >>> about them, I guess we’d already have them. 
 >>> 
 >>> On 20 Nov 2016, at 23:41, Robin Heggelund Hansen <
 skinn...@gmail.com> 
 >>> wrote: 
 >>> 
 >>> How about 'Some' and 'None'? 
 >>> Those are not longer to type than what we have today, and they 
 should 
 >>> solve your initial confusion. 
 >>> 
 >>> søndag 20. november 2016 18.16.26 UTC+1 skrev Will White følgende: 
  
  I'm talking about Maybe.Just, of course. Just has always seemed 
 strange 
  to me, as if it's hinting that it's something other than just the 
  counterpart to Nothing. 

Re: [elm-discuss] Proposed addition for Task package

[Charlie Koster]

>
> One reason is what Evan says at 
> https://github.com/elm-lang/core/blob/master/CONTRIBUTING.md#adding-new-functions:
>  
> new functions are not so quickly expected to go into core, instead to be 
> accumulated in *-extra packages first.
>
I didn't realize that was the case. Thanks for the info.

it is better to do a recursive call to the `update` function, or better 
> yet: call the function that your command would call
>

I respectfully disagree. Depending on the application, this either may not 
be possible or would be a terrible code smell. I honestly think the above 
suggestion would be worse than chaining another Cmd msg. Sending another 
Cmd msg is clean and follows the Elm architecture.

Another case that wouldn't work out so well for is the init function. The 
init function returns a (model, Cmd msg). I think it'd be much cleaner for 
the init function to call sendMsg (or equivalent) instead of the init 
function calling either my update function or the function that would be 
called for that msg.

> ​
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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: Passing properties as arguments to messages?

[Wouter In t Velt]

PS: the function definition should not be capitalized, but should be called 
"animateProperty" of course

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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: Passing properties as arguments to messages?

[Wouter In t Velt]

There is a way to make it work, but it will be a lot more verbose/ ugly/ 
overengineered. Your signature would need to look something like this:

AnimateProperty : Model -> (Model -> Style) -> (Style -> Model -> Model) -> 
Msg -> (Model, Msg)
AnimateProperty = model funcToExtractStyle funcToUpdateStyle animMsg =
  ...

-- call this as follows
(newModel, newCmd) = 
  animateProperty 
model 
(.answerTextStyle)
(\newStyle a -> { a | answerTextStyle = newStyle } )

And it will only work if all your properties are of the same type.
And if they are all of the same type, you would be better off to put all 
your styles in a `Dict`, which would make the `AnimateProperty` a lot 
cleaner.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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: Current date (sorry for starting it again)

[Tim Bezhashvyly]

Yay, it works. Thank you for teaching me this pattern Thomas!

On Tuesday, November 22, 2016 at 12:22:01 PM UTC+1, Thomas Coopman wrote:
>
> If you have a function: compare : Date -> Foo -> Bool
> you can then do: compareWithDate = compare date
> and in your filter use compareWithDate:
>
> compare : Date -> Foo -> Bool
> compare .
>
> filterFoos : List Foo -> Date -> List Foo
> filterFoos foos date =
>let
>  compareWithDate = compare date
>in
>  List.filter compareWithDate foos
>
>
> On Tue, 22 Nov 2016 at 08:26 Tim Bezhashvyly  > wrote:
>
>> Sorry, I'm still not sure how to pass a received date or model to 
>> comparison function.
>>
>>
>> On Tuesday, November 22, 2016 at 3:41:07 AM UTC+1, Max Goldstein wrote:
>>>
>>> You can partially apply the comparison function to the current date 
>>> before passing it to List.filter. The trick is that you have to get the 
>>> current date through a command, and either run the filter when the command 
>>> comes back, or keep the current date in the 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...@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: Unpublishing a package

[Peter Damoc]

On Tue, Nov 22, 2016 at 1:12 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> What about the issue of people forking and re-publishing packages (and
> ignoring the tests), because they are too impatient/anti-social to go about
> things in more civilized manner? Do there need to be stricter controls for
> getting stuff into the repo? Do we need or can we manage some kind of
> cummunity oversight? Or is this unnecessary at this stage and its not
> really such an issue?
>
>
There is a goldilocks space between the creative stifling tyranny of too
many restrictions and the chaos of no restrictions.

There are already about 300 packages and we could benefit from
- a little bit of organization (tags/categories)  that could facilitate
discovery and
- a little bit of community validation to sift the very useful stuff from
one-off experiments or angry forks.




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

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

Re: [elm-discuss] Re: Current date (sorry for starting it again)

[Thomas Coopman]

If you have a function: compare : Date -> Foo -> Bool
you can then do: compareWithDate = compare date
and in your filter use compareWithDate:

compare : Date -> Foo -> Bool
compare .

filterFoos : List Foo -> Date -> List Foo
filterFoos foos date =
   let
 compareWithDate = compare date
   in
 List.filter compareWithDate foos


On Tue, 22 Nov 2016 at 08:26 Tim Bezhashvyly 
wrote:

> Sorry, I'm still not sure how to pass a received date or model to
> comparison function.
>
>
> On Tuesday, November 22, 2016 at 3:41:07 AM UTC+1, Max Goldstein wrote:
>
> You can partially apply the comparison function to the current date before
> passing it to List.filter. The trick is that you have to get the current
> date through a command, and either run the filter when the command comes
> back, or keep the current date in the 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] Re: Passing properties as arguments to messages?

[Thomas Coopman]

You can also extract getting the model property in a separate function, so
that you don't have to duplicate it completely.

On Mon, 21 Nov 2016 at 23:59 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Monday, November 21, 2016 at 6:27:40 PM UTC, Rex van der Spuy wrote:
>
> Is it possible to pass model properties as message arguments and use those
> arguments to construct a new model?
>
>
> Could use a Dict instead of properties?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[elm-discuss] Re: Unpublishing a package

['Rupert Smith' via Elm Discuss]

What about the issue of people forking and re-publishing packages (and 
ignoring the tests), because they are too impatient/anti-social to go about 
things in more civilized manner? Do there need to be stricter controls for 
getting stuff into the repo? Do we need or can we manage some kind of 
cummunity oversight? Or is this unnecessary at this stage and its not 
really such an issue?

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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] Unpublishing a package

[Zachary Kessin]

I think the case that Richard Mentioned is a key one to keep in mind.
Having an unpublish could cause real problems. I like the idea of a "Hide"
where it will no longer show up in the search and maybe have a place for a
pointer to a different repo so if you go to the elm-check which is no
longer supported it will point you to elm-test or the like.

Zach
ᐧ

On Tue, Nov 22, 2016 at 10:42 AM, Michel Rijnders  wrote:

>
> On Tuesday, November 22, 2016 at 12:33:40 AM UTC+1, Richard Feldman wrote:
>>
>> There is no unpublish feature, and it's important that there never be one
>> . :)
>>
>
> That's too simplistic, you can also break lots of projects by publishing a
> version of a package with a serious bug. And what if it's a security bug
> that somehow exposes sensitive information? In such a case unpublishing
> makes sense.
>
>
>> If you want to deprecate a package, I recommend publishing a new major
>> release that removes everything and replaces the README with an explanation
>> of how the package is gone now (and perhaps what to use instead).
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

Re: [elm-discuss] Can't install native package using elm-github-install

['Rupert Smith' via Elm Discuss]

On Tuesday, November 22, 2016 at 10:32:22 AM UTC, Gusztáv Szikszai wrote:
>
> Yes, that is perfect for my use case, thanks. This should be added to the 
>> official packages?
>>
>  
> This kind of messaging is not encouraged (sending things around the 
> program), so It probably will not be added to the official packages.
>

It would have 2 uses:

* Alternative to 'out messages', which seem to require a lot of boiler 
plate. This is much simpler and more convenient to use.
* For inter-process communication.

I think the Process model is still in development. At least according to 
the notes Evan left in the docs it says it needs some time to evolve into 
the right shape so not to be too hasty in trying to push him into a 
particular direction for it (or words to that effect).

That said, this would seem too useful to ignore.
 

>
> That is, I provide the name of the channel and it returns a send/listen 
>> pair that operate on type 'a'. Or perhaps it is just:
>>
>> send : String -> a -> Cmd msg
>> listen : String -> (a -> msg) -> Sub msg
>>
>> Is there some reason this cannot be done?
>>
>
> I tried to implement that with pure Elm but the way effect managers works 
> prevents that.
> It can be done with some native functions, but it's dangerous because 
> prevents type checking (it directly feeds the given messages back into the 
> program).
>

That is what I was trying to get at with my constructor for the send/listen 
pair; trying to make sure that they work with the same type. Encoding as 
json is only a minor inconvenienve, it doesn't put me off using 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.

Re: [elm-discuss] Proposed addition for Task package

[Wouter In t Velt]

My 2c:  I kind of like it that there is NOT such a function in the core.
Because it *prevents me from grabbing it when I really shouldn't*.

Especially if the `Cmd` has no side effects, it is better to do a recursive 
call to the `update` function, or better yet: call the function that your 
command would call, if it had been passed to the elm runtime.

Many of the names of the messages in the example suggest that creating a 
`Cmd msg` is not the best solution.

The only exception I can think of where it is useful is using 
`Process.sleep` to force a timeout.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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?

[Will White]

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 wouldmake 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 gmail.com 
>> > 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 inherited from Haskell, like a lot of other stuff. Doubt if 
>> >> there 
>> >> was any other thought put into it if I'm honest. 
>> >> 
>> >> On Monday, 21 November 2016 14:46:40 UTC, Will White wrote: 
>> >>> 
>> >>> Sorry, meant to say “I guess he’s already considered and rejected them”. 
>> >>> 
>> >>> On 21 Nov 2016, at 14:21, Will White > wrote: 
>> >>> 
>> >>> I prefer Some or None, for understanding. Though, unless Evan didn’t 
>> >>> know 
>> >>> about them, I guess we’d already have them. 
>> >>> 
>> >>> On 20 Nov 2016, at 23:41, Robin Heggelund Hansen > 
>> >>> wrote: 
>> >>> 
>> >>> How about 'Some' and 'None'? 
>> >>> Those are not longer to type than what we have today, and they should 
>> >>> solve your initial confusion. 
>> >>> 
>> >>> søndag 20. november 2016 18.16.26 UTC+1 skrev Will White følgende: 
>>  
>>  I'm talking about Maybe.Just, of course. Just has always seemed strange 
>>  to me, as if it's hinting that it's something other than just the 
>>  counterpart to Nothing. I don't know the reasons behind its naming, but 
>>  I 
>>  think I would prefer Something, as in "something or nothing". What do 
>>  you 
>>  think? 
>> >>> 
>> >>> 
>> >>> -- 
>> >>> You received this message because you are subscribed to a topic in the 
>> >>> Google Groups "Elm Discuss" group. 
>> >>> To unsubscribe from this topic, visit 
>> >>> https://groups.google.com/d/topic/elm-discuss/EHnuE_gGFuo/unsubscribe 
>> >>> . 
>> >>> To unsubscribe from this group and

[elm-discuss] Tag new releases in the elm platform repo

[futtetennista]

I recently contributed to the docker-elm repo 
 and in order to build an image for a 
given elm version the BuildFromSourceFile.hs file is needed 
. 
I think it'd be nicer, more explicit and less error-prone to be able to 
write something like:
 
https://github.com/elm-lang/elm-platform/blob/0.18/installers/BuildFromSource.hs

instead of using the commit sha but right now new releases are not tagged 
(the last tag is 0.15) so this is not possible. Would it be possible to add 
tagging as a mandatory step in the release process in the elm-platform 
repo? I don't see any reason why this would hurt.

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.

Re: [elm-discuss] Can't install native package using elm-github-install

[Gusztáv Szikszai]

>
> Yes, that is perfect for my use case, thanks. This should be added to the 
> official packages?
>
 
This kind of messaging is not encouraged (sending things around the 
program), so It probably will not be added to the official packages.

That is, I provide the name of the channel and it returns a send/listen 
> pair that operate on type 'a'. Or perhaps it is just:
>
> send : String -> a -> Cmd msg
> listen : String -> (a -> msg) -> Sub msg
>
> Is there some reason this cannot be done?
>

I tried to implement that with pure Elm but the way effect managers works 
prevents that.
It can be done with some native functions, but it's dangerous because 
prevents type checking (it directly feeds the given messages back into the 
program).


On Tuesday, November 22, 2016 at 11:17:05 AM UTC+1, Rupert Smith wrote:
>
> On Tuesday, November 22, 2016 at 4:59:22 AM UTC, Gusztáv Szikszai wrote:
>>
>> I think you are looking for something like this: 
>> https://github.com/gdotdesign/elm-ui/blob/master/source/Ui/Helpers/Emitter.elm
>>  
>> It's a pure Elm pub / sub effects module (and possibly the most minimal 
>> example of an effect module).
>>
>
> Yes, that is perfect for my use case, thanks. This should be added to the 
> official packages?
>
> I was wondering, would it be possible to make a send/listen pair where the 
> type of the item being transmitted is variable? For example, the 
> send/listen pair for a Json Value is:
>
> send : String -> Value -> Cmd msg
> listen : String -> (Value -> msg) -> Sub msg
>
> But given there is no native code at all, why translate to json? It seems 
> unnecessary. Instead I want a constructor for the send/listen pair:
>
> mailbox : String -> (a -> Cmd msg, (a -> msg) -> Sub msg)
>
> That is, I provide the name of the channel and it returns a send/listen 
> pair that operate on type 'a'. Or perhaps it is just:
>
> send : String -> a -> Cmd msg
> listen : String -> (a -> msg) -> Sub msg
>
> Is there some reason this cannot be done?
>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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?

[Oliver Searle-Barnes]

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 inherited from Haskell, like a lot of other stuff. Doubt if 
>>> there 
>>> >> was any other thought put into it if I'm honest. 
>>> >> 
>>> >> On Monday, 21 November 2016 14:46:40 UTC, Will White wrote: 
>>> >>> 
>>> >>> Sorry, meant to say “I guess he’s already considered and rejected 
>>> them”. 
>>> >>> 
>>> >>> On 21 Nov 2016, at 14:21, Will White  wrote: 
>>> >>> 
>>> >>> I prefer Some or None, for understanding. Though, unless Evan didn’t 
>>> know 
>>> >>> about them, I guess we’d already have them. 
>>> >>> 
>>> >>> On 20 Nov 2016, at 23:41, Robin Heggelund Hansen  
>>>
>>> >>> wrote: 
>>> >>> 
>>> >>> How about 'Some' and 'None'? 
>>> >>> Those are not longer to type than what we have today, and they 
>>> should 
>>> >>> solve your initial confusion. 
>>> >>> 
>>> >>> søndag 20. november 2016 18.16.26 UTC+1 skrev Will White følgende: 
>>>  
>>>  I'm talking about Maybe.Just, of course. Just has always seemed 
>>> strange 
>>>  to me, as if it's hinting that it's something other than just the 
>>>  counterpart to Nothing. I don't know the reasons behind its naming, 
>>> but I 
>>>  think I would prefer Something, as in "something or nothing". What 
>>> do you 
>>>  think? 
>>> >>> 
>>> >>> 
>>> >>> -- 
>>> >>> You received this message because you are subscribed to a topic in 
>>> the 
>>> >>> Google Groups "Elm Discuss" group. 
>>> >>> To unsubscribe from this topic, visit 
>>> >>> 
>>> https://groups.google.com/d/topic/elm-discuss/EHnuE_gGFuo/unsubscribe. 
>>> >>> To unsubscribe from this group and all its topics, send an email to 
>>> >>> elm-discuss...@googlegroups.com. 
>>> >>> For more options, visit https://groups.google.com/d/optout. 
>>> >>> 
>>> >>> 
>>> >>> 
>>> >> 
>>> >> -- 
>>> >> You r

Re: [elm-discuss] Can't install native package using elm-github-install

['Rupert Smith' via Elm Discuss]

On Tuesday, November 22, 2016 at 4:59:22 AM UTC, Gusztáv Szikszai wrote:
>
> I think you are looking for something like this: 
> https://github.com/gdotdesign/elm-ui/blob/master/source/Ui/Helpers/Emitter.elm
>  
> It's a pure Elm pub / sub effects module (and possibly the most minimal 
> example of an effect module).
>

Yes, that is perfect for my use case, thanks. This should be added to the 
official packages?

I was wondering, would it be possible to make a send/listen pair where the 
type of the item being transmitted is variable? For example, the 
send/listen pair for a Json Value is:

send : String -> Value -> Cmd msg
listen : String -> (Value -> msg) -> Sub msg

But given there is no native code at all, why translate to json? It seems 
unnecessary. Instead I want a constructor for the send/listen pair:

mailbox : String -> (a -> Cmd msg, (a -> msg) -> Sub msg)

That is, I provide the name of the channel and it returns a send/listen 
pair that operate on type 'a'. Or perhaps it is just:

send : String -> a -> Cmd msg
listen : String -> (a -> msg) -> Sub msg

Is there some reason this cannot be done?

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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?

[Will White]

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 inherited from Haskell, like a lot of other stuff. Doubt if there 
> >> was any other thought put into it if I'm honest. 
> >> 
> >> On Monday, 21 November 2016 14:46:40 UTC, Will White wrote: 
> >>> 
> >>> Sorry, meant to say “I guess he’s already considered and rejected them”. 
> >>> 
> >>> On 21 Nov 2016, at 14:21, Will White > wrote: 
> >>> 
> >>> I prefer Some or None, for understanding. Though, unless Evan didn’t know 
> >>> about them, I guess we’d already have them. 
> >>> 
> >>> On 20 Nov 2016, at 23:41, Robin Heggelund Hansen > 
> >>> wrote: 
> >>> 
> >>> How about 'Some' and 'None'? 
> >>> Those are not longer to type than what we have today, and they should 
> >>> solve your initial confusion. 
> >>> 
> >>> søndag 20. november 2016 18.16.26 UTC+1 skrev Will White følgende: 
>  
>  I'm talking about Maybe.Just, of course. Just has always seemed strange 
>  to me, as if it's hinting that it's something other than just the 
>  counterpart to Nothing. I don't know the reasons behind its naming, but 
>  I 
>  think I would prefer Something, as in "something or nothing". What do 
>  you 
>  think? 
> >>> 
> >>> 
> >>> -- 
> >>> You received this message because you are subscribed to a topic in the 
> >>> Google Groups "Elm Discuss" group. 
> >>> To unsubscribe from this topic, visit 
> >>> https://groups.google.com/d/topic/elm-discuss/EHnuE_gGFuo/unsubscribe 
> >>> . 
> >>> To unsubscribe from this group and all its topics, 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 
> >> . 
> > 
> 

Re: [elm-discuss] Proposed addition for Task package

[Janis Voigtländer]

2016-11-22 4:04 GMT+01:00 Charlie Koster :

I don't see any reason why not have a function in Task that takes a msg and
> returns a Cmd msg.

One reason is what Evan says at
https://github.com/elm-lang/core/blob/master/CONTRIBUTING.md#adding-new-functions:
new functions are not so quickly expected to go into core, instead to be
accumulated in *-extra packages first.

The function you want exists in such a package:
http://package.elm-lang.org/packages/shmookey/cmd-extra/1.0.0/Cmd-Extra#message.
So maybe the best action at the moment is to get that package updated for
Elm 0.18.
​

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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] Unpublishing a package

[Peter Damoc]

On Tue, Nov 22, 2016 at 10:42 AM, Michel Rijnders  wrote:

> That's too simplistic, you can also break lots of projects by publishing a
> version of a package with a serious bug. And what if it's a security bug
> that somehow exposes sensitive information? In such a case unpublishing
> makes sense.
>

These kind of concerns can be mitigated by upgrade policies and security
audits. I think they are orthogonal to publishing.
It would be, however, very very nice to add more defenses as time goes by.

The world is a nasty place and tragedy can strike at any moment, sometime
it pays to be extra careful.



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

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

Re: [elm-discuss] Unpublishing a package

[Michel Rijnders]

On Tuesday, November 22, 2016 at 12:33:40 AM UTC+1, Richard Feldman wrote:
>
> There is no unpublish feature, and it's important that there never be one 
> . :)
>

That's too simplistic, you can also break lots of projects by publishing a 
version of a package with a serious bug. And what if it's a security bug 
that somehow exposes sensitive information? In such a case unpublishing 
makes sense.


> If you want to deprecate a package, I recommend publishing a new major 
> release that removes everything and replaces the README with an explanation 
> of how the package is gone now (and perhaps what to use instead).
>

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