Re: [elm-discuss] Re: [Suggestion] Type values and simplifying the language still

[Janis Voigtländer]

Max, apparently you didn’t understand what Maxime’s proposal is *at all*.

For example, he didn’t propose anything that would change the existence of
this type:

type Direction = Up | Down | Left | Right

​

2017-01-15 23:47 GMT+01:00 Max Goldstein :

> First, I appreciate that this proposal is being made in the spirit of Elm:
> seeking to simplify the language, with reference to existing usage (red
> sentence in the first post), and trying to solve an existing problem
> (serialization of union types). It's clear that Maxime wants to learn and
> improve the language. Thank you.
>
> So let's look at how union types are used, what jobs they are hired to do,
> if you will. You've noticed in core that union types with one tag are used
> to hide things. Sometimes that's as an opaque type: there is one tag that's
> not exposed, and is pattern-matched easily, and the data the tag holds can
> change even in a patch release (example here
> ).
> Core also contains a rare pattern of, say *type Task x a = Task* where
> the *Task* value defined is not actually used anywhere because it's
> actually a native implementation. Serializing arbitrary union types will
> have to account for this case.
>
> A more realistic use of union types is as a finite set of labels, even if
> these labels don't carry any information along with them. For example:
>
> type Direction = Up | Down | Left | Right
>
> From this we derive pattern matches with static
> (compile-time) exhaustiveness checking, which is a huge improvement in
> reliability and refactorability over "stringly typed" conventions (instead
> of strongly typed, get it?) that you'll see in JavaScript and the like.
> Replacing the Direction type with a record including a string removes this
> huge improvement.
>
> Adding data to these tags allows for the classic use case of data that
> only makes sense in certain contexts. I remember working with a C++
> graphics library where certain fields of structs were only defined if an
> enum was set to a particular value. But this isn't really a separate use
> case from labels without data, since you can freely mix within a type. The 
> RemoteData
> type
> does
> this to great effect.
>
> More theoretically, union types and records are not the same; they are
> actually duals. Union types are referred to as "sum types" and records (and
> tuples) are "product types". Here's the reasoning: consider two types, *a*
> and *b*. Let's denote the number of values of type *a* as |a|, and
> similarly |b|. If we construct the sum type *Result a b* then there are
> |a| values for the Err case and |b| values for the Ok case. So |Result a b|
> = |a| + |b|, hence sum types. For the pair (a, b) we can pick any *a* and
> any *b* so |(a,b)| = |a|*|b|, hence produce types.
>
> If you want to produce (create) a value of sum type, such as *Result a b*,
> you can pick either case to work with. But when you consume (inspect) a
> value of that type, you must be prepared to handle all cases. For product
> types it is reversed: to produce a value of type (a,b) you must have both
> an *a* and a *b*, but when you consume such a value, you can pick out the
> one you want.
>
> So, while I appreciate the gesture, I don't think this will work.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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] [Suggestion] Type values and simplifying the language still

[Janis Voigtländer]

> - the 5% seems to be why we can't serialize values automatically


I'm sure this is wrong. It's possible to improve the compiler such that
ADTs are automatically serializable. It just hasn't been done yet. Wanting
this feature is no justification for changing the language. It is
justification for improving the compiler.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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] [Suggestion] Type values and simplifying the language still

[Janis Voigtländer]

>
> yeah, it should be Bar << (,,) (there are no compile errors in the mail
> client).
>


No, that's still not type correct.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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] [Suggestion] Type values and simplifying the language still

[Janis Voigtländer]

Your example is not even type correct. And even if it were, I don't see how it 
would contradict my point. The constructor wouldn't be partially applicable. 
You would have to define a separate function for that. Bad for reuse and 
refactorability. 


> Am 15.01.2017 um 17:15 schrieb Maxime Dantec :
> 
> Not really, take this example :
> 
> type Foo = Bar ( Int, Bool, (String, Foo) )
> 
> foo : Int -> Bool -> (String, Foo) -> Foo
> foo = Foo << (,,)
> 
> And again, it seems to be the exception to have multiple values.
> 
>> On Sunday, January 15, 2017 at 5:09:46 PM UTC+1, Janis Voigtländer wrote:
>> This would take away the possibility of partially applying the constructors 
>> like Bar. Not a good idea. There's a reason these have curried types. 
>> 
>> 
>>> Am 15.01.2017 um 17:03 schrieb Maxime Dantec :
>>> 
>>> Not really, sorry I assumed that everybody knew how elm compile values but 
>>> it was very presumptuous. Currently, all type values in Elm are converted 
>>> in Javascript values in the { ctor, _0, _1... _n } shape. For example, 
>>> Nothing becomes { ctor: "Nothing" } and (Just 10) becomes { ctor : "Just", 
>>> _0: 10 }. The {type, value} part, would change that to : Nothing becomes { 
>>> type: "Nothing" } and (Just 10) becomes { type : "Just", value: 10 }.
>>> 
>>> The { ctor, _0, _1... _n } shape is, I assume, why we can't automatically 
>>> send type values though ports. The rationale is: if it's really the reason, 
>>> since we barely use more than one value in type values, why not facilitate 
>>> port usage instead of larger type values. Does it makes sense at all?
>>> 
>>> In other words, currently you can do that:
>>> 
>>> type Foo = Foo | Bar Int Bool (String, Foo)
>>> where: Bar : Int -> Bool -> (String, Foo) -> Foo
>>> that you use like this in elm: Bar 1 False ("fooBar", Foo)
>>> which compiles down to in js: { ctor: "Bar", _0: 10, _1: false, _2: { ctor: 
>>> "Tuple2", _0: "fooBar", _1: { ctor: "Foo"} } }
>>> 
>>> It would become impossible, because the type value Bar has 3 values.
>>> Instead, you would have to give only one value to the Bar constructor :
>>> 
>>> type Foo = Bar { id: Int, isSomething: Bool, foo: (String, Foo) }
>>> where: Bar : { id: Int, isSomething: Bool, foo: (String, Foo) } -> Foo
>>> that you would use like this: Bar { id = 0, isSomething = False, foo = 
>>> ("fooBar", Foo) }
>>> would compiles down to: { type: "Bar", value: { id: 0, isSomething: false, 
>>> foo: ["fooBar", { type: "Foo" }] } }
>>> 
>>> The record could be as well replaced by a Tuple ( Int, Bool, (String, Foo) )
>>> 
>>> I hope it's clearer enough?
>>> 
>>>> On Sunday, January 15, 2017 at 4:33:50 PM UTC+1, Duane Johnson wrote:
>>>> I'm trying to see if I understand your suggestion correctly.
>>>> 
>>>> So would an enumeration like this:
>>>> 
>>>> type Msg
>>>> = ClickedButton
>>>> | EnteredAge value
>>>> | EnteredHeight value
>>>> 
>>>> become...
>>>> 
>>>> type Msg = { action : String, value : String }
>>>> 
>>>> ?
>>>> 
>>>> I'm trying to figure out how you'd "authorize up to one value" in a 
>>>> situation like this, since the whole point of an enumeration is to allow 
>>>> multiple possibilities.
>>>> 
>>>> Duane
>>>> 
>>>>> On Sun, Jan 15, 2017 at 6:59 AM, Maxime Dantec  wrote:
>>>>> Hi folks,
>>>>> 
>>>>> The last 3 versions of elm were somewhat unusual for a young programing 
>>>>> language: features were removed and it has been simplified, to the point 
>>>>> that you can't remove anything else. Well, about that.
>>>>> 
>>>>> I believe that the last thing that could be simplified still are ADT. No 
>>>>> type value has more than one value in the core repository, with the 
>>>>> exception of Dict and Color. I have used a few types with more than one 
>>>>> value myself, but I hardly see the difference with a type value that has 
>>>>> 3 values and a type value that has a tuple3 as unique value, if you 
>>>>> except the const

Re: [elm-discuss] [Suggestion] Type values and simplifying the language still

[Janis Voigtländer]

This would take away the possibility of partially applying the constructors 
like Bar. Not a good idea. There's a reason these have curried types. 


> Am 15.01.2017 um 17:03 schrieb Maxime Dantec :
> 
> Not really, sorry I assumed that everybody knew how elm compile values but it 
> was very presumptuous. Currently, all type values in Elm are converted in 
> Javascript values in the { ctor, _0, _1... _n } shape. For example, Nothing 
> becomes { ctor: "Nothing" } and (Just 10) becomes { ctor : "Just", _0: 10 }. 
> The {type, value} part, would change that to : Nothing becomes { type: 
> "Nothing" } and (Just 10) becomes { type : "Just", value: 10 }.
> 
> The { ctor, _0, _1... _n } shape is, I assume, why we can't automatically 
> send type values though ports. The rationale is: if it's really the reason, 
> since we barely use more than one value in type values, why not facilitate 
> port usage instead of larger type values. Does it makes sense at all?
> 
> In other words, currently you can do that:
> 
> type Foo = Foo | Bar Int Bool (String, Foo)
> where: Bar : Int -> Bool -> (String, Foo) -> Foo
> that you use like this in elm: Bar 1 False ("fooBar", Foo)
> which compiles down to in js: { ctor: "Bar", _0: 10, _1: false, _2: { ctor: 
> "Tuple2", _0: "fooBar", _1: { ctor: "Foo"} } }
> 
> It would become impossible, because the type value Bar has 3 values.
> Instead, you would have to give only one value to the Bar constructor :
> 
> type Foo = Bar { id: Int, isSomething: Bool, foo: (String, Foo) }
> where: Bar : { id: Int, isSomething: Bool, foo: (String, Foo) } -> Foo
> that you would use like this: Bar { id = 0, isSomething = False, foo = 
> ("fooBar", Foo) }
> would compiles down to: { type: "Bar", value: { id: 0, isSomething: false, 
> foo: ["fooBar", { type: "Foo" }] } }
> 
> The record could be as well replaced by a Tuple ( Int, Bool, (String, Foo) )
> 
> I hope it's clearer enough?
> 
>> On Sunday, January 15, 2017 at 4:33:50 PM UTC+1, Duane Johnson wrote:
>> I'm trying to see if I understand your suggestion correctly.
>> 
>> So would an enumeration like this:
>> 
>> type Msg
>> = ClickedButton
>> | EnteredAge value
>> | EnteredHeight value
>> 
>> become...
>> 
>> type Msg = { action : String, value : String }
>> 
>> ?
>> 
>> I'm trying to figure out how you'd "authorize up to one value" in a 
>> situation like this, since the whole point of an enumeration is to allow 
>> multiple possibilities.
>> 
>> Duane
>> 
>>> On Sun, Jan 15, 2017 at 6:59 AM, Maxime Dantec  wrote:
>>> Hi folks,
>>> 
>>> The last 3 versions of elm were somewhat unusual for a young programing 
>>> language: features were removed and it has been simplified, to the point 
>>> that you can't remove anything else. Well, about that.
>>> 
>>> I believe that the last thing that could be simplified still are ADT. No 
>>> type value has more than one value in the core repository, with the 
>>> exception of Dict and Color. I have used a few types with more than one 
>>> value myself, but I hardly see the difference with a type value that has 3 
>>> values and a type value that has a tuple3 as unique value, if you except 
>>> the constructor signature. Does yourself make an intensive usage of this 
>>> feature?
>>> 
>>> So here is my suggestion: Why not authorize up to one value to type values? 
>>> If you need to bundle values, you can still use a tuple or a record. The 
>>> reasoning behind this, is to get rid of the _0, _1, _2 in the "native" part 
>>> of the type values. we could have {ctor:"Enum"} or {ctor:"TypeValue", 
>>> value: {...}}, and why not automatic serializer/deserializers in the ports 
>>> thanks to this too?
>>> 
>>> Everyone has an opinion, and it's very easy to make a suggestion while not 
>>> implementing it. I'm not pretending that this is a good idea, I humbly 
>>> think that it's worth mentioning given that it's in the scope of 
>>> simplifying the language. Please share you opinion :)
>>> 
>>> Cheers!
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [elm-discuss] Re: elm-graphics-app: An Elm Teaching Library (influenced in part by elm-playground)

[Janis Voigtländer]

As indicated in his email opening this thread, which contains a *link* to
graphicsvg , he already *has*
taken a look at that. :-)
​

2017-01-14 14:21 GMT+01:00 Rex van der Spuy :

> There's similar 0.17 package which you might want to take a look at:
>
> http://package.elm-lang.org/packages/MacCASOutreach/graphicsvg/latest
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

As pointed out earlier, it is not true for *Haskell's* let and where. 


> Am 04.01.2017 um 22:52 schrieb 'Andrew Radford' via Elm Discuss 
> :
> 
> Heh ok read it again I'll make it more programmer friendly: 
> 
> ( |> and <| ) and ( >> and << )
> 
> 
> They (each) have identical behavior in what they do, with a left/right 
> symmetry. (I guess you just confirmed it is the same for let/where, with a 
> top/bottom symmetry)
> 
> 
> On Wednesday, 4 January 2017 20:30:25 UTC, Joey Eremondi wrote:
>> 
>>> Kinda like how you currently have the freedom to chose between |> and <|, 
>>> >> and <<
>> 
>> They're not really the same thing: << is function composition, and <| is 
>> function application. There are cases where you can use either, but for each 
>> there are cases where only one will do the trick. 
>> 
>> Whereas, where vs. let are literally identical in what they do, they just 
>> look different.
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

But what if the branches are not calls to an external function like "munch", 
but are instead as originally envisioned arbitrary, in place, expressions, 
possibly using "b"/"c" several times? Then your latest solution does not apply 
since it loses sharing. (Of course one can always artificially introduce 
something like an explicit "munge"-function just for the purpose of 
guaranteeing sharing. But that might be undesirable from a readability 
standpoint.)

> Am 03.01.2017 um 17:39 schrieb Colin Woodbury :
> 
> @Janis, no, truth be told I didn't like it as I was writing it, but it also 
> didn't occur to me at the time to fire `where` down at the bottom like that. 
> Doing so would satisfy "intent first", but I'd say `let` and `where` here 
> would be tied in terms of "zig-zag annoyance", which is a natural outcome of 
> the pattern of needing a shared bound value across two guards.
> 
> The next evolution, avoiding the problem of nested `where`s entirely:
> 
> f tree =
>   case tree of
> Leaf x -> munge a (b x)
> Node s t -> munge a (c s t)
>   where
> a = ...
> b x = ...
> c s t = ...
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

Yes, and there is no need to only imagine it, since that already *is* a
legal use of Haskell-style where. But I have doubts about its readability,
with the adjacent where lines towards the bottom, where only indentation
determines what the scope of the respective definitions is. And since Colin
probably knows that that way of writing the example would have been legal
as well, his giving another version with where instead may indicate he also
considers these “adjacent wheres” undesirable in terms of
clarity/readability of the code.

In any case, even just the fact that let (with in) is a
two-keywords-construct makes it clearer for nested uses.
​

2017-01-03 10:43 GMT+01:00 David Andrews :

> You could also imagine a parsing of where, where the following would be
> the way to write this:
> f tree =
>   case tree of
> Leaf x ->
>   munge a b
>   where
> b = ...
> Node s t ->
>   munge a c
>   where
> c = ...
>   where
> a = ...
>
>
>
>
>
> On Tuesday, January 3, 2017 at 1:26:33 AM UTC-5, Janis Voigtländer wrote:
>>
>> And do you like that version? It seems to not have the advantages usually
>> claimed for "where" in this discussion. For example, you define "a" before
>> using it. What about "intent first" here? And in some sense, this
>> formulation now looks like a dual to the workaround Joey proposed with
>> "let" to please "where" proponents. Isn't it strange that "a" and "work"
>> look like they might be mutually recursive now, when they are actually not
>> and when the "let"-formulation made that explicitly visible?
>>
>> Am 02.01.2017 um 23:10 schrieb Colin Woodbury :
>>
>> @Janis, I suppose the `where` version of that formation would have to be:
>>
>> f tree = work
>>   where a = ...
>> work = case tree of
>>   Leaf x -> -- using a and b
>>
>> where b = ...
>>   Node s t -> -- using a c
>>
>> where c = ...
>>
>>
>> On Sunday, 1 January 2017 12:21:47 UTC-8, Janis Voigtländer wrote:
>>>
>>> Janis, the following compiles for me: …
>>>
>>> Right, where does not work for expressions, but for right-hand sides,
>>> of which pattern match branches are an instance.
>>>
>>> The next question would be, still under the assumption that a choice has
>>> to be made between where and let because both won’t be made available
>>> at the same time, how well “where-only” would work if in addition one
>>> wants to have a local binding that spans all pattern match branches, i.e.,
>>> something one would currently write in Elm like so:
>>>
>>> f tree =
>>>   let
>>> a = ... something ...
>>>   in
>>> case tree of
>>>   Leaf x -> let b = ... in ... using a and b ...
>>>   Node s t -> let c = ... in ... using a and c ...
>>>
>>> ​
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

And do you like that version? It seems to not have the advantages usually 
claimed for "where" in this discussion. For example, you define "a" before 
using it. What about "intent first" here? And in some sense, this formulation 
now looks like a dual to the workaround Joey proposed with "let" to please 
"where" proponents. Isn't it strange that "a" and "work" look like they might 
be mutually recursive now, when they are actually not and when the 
"let"-formulation made that explicitly visible?

> Am 02.01.2017 um 23:10 schrieb Colin Woodbury :
> 
> @Janis, I suppose the `where` version of that formation would have to be:
> 
> f tree = work
>   where a = ...
> work = case tree of
>   Leaf x -> -- using a and b  
> 
> where b = ...
>   Node s t -> -- using a c        
> 
> where c = ...
> 
> 
>> On Sunday, 1 January 2017 12:21:47 UTC-8, Janis Voigtländer wrote:
>> Janis, the following compiles for me: …
>> 
>> Right, where does not work for expressions, but for right-hand sides, of 
>> which pattern match branches are an instance.
>> 
>> The next question would be, still under the assumption that a choice has to 
>> be made between where and let because both won’t be made available at the 
>> same time, how well “where-only” would work if in addition one wants to have 
>> a local binding that spans all pattern match branches, i.e., something one 
>> would currently write in Elm like so:
>> 
>> f tree =
>>   let
>> a = ... something ...
>>   in
>> case tree of
>>   Leaf x -> let b = ... in ... using a and b ...
>>   Node s t -> let c = ... in ... using a and c ...
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

It’s how they are implemented in Haskell, and people asking for where in
Elm typically do so by saying “we want where like in Haskell”. One could
probably come up with new parsing rules that allow where to be used
anywhere in an expression, thus also for example for local bindings inside
a lambda-abstraction. But that would require new design work to make sure
everything fits together and the syntax remains unambigous and usable. That
probably presents an even bigger hurdle for acceptance into Elm than “just”
wanting to get Haskell-style where in.
​

2017-01-02 5:57 GMT+01:00 David Andrews :

> Is there something fundamental about `where` clauses which would prevent
> them from parsing as expressions, or is this an artifact of how they are
> implemented in Haskell?
>
> On Sun, Jan 1, 2017 at 9:21 PM Janis Voigtländer <
> janis.voigtlaen...@gmail.com> wrote:
>
>>
>>
>> Janis, the following compiles for me: …
>>
>>
>>
>> Right, where does not work for expressions, but for right-hand sides, of
>> which pattern match branches are an instance.
>>
>>
>> The next question would be, still under the assumption that a choice has
>> to be made between where and let because both won’t be made available at
>> the same time, how well “where-only” would work if in addition one wants
>> to have a local binding that spans all pattern match branches, i.e.,
>> something one would currently write in Elm like so:
>>
>>
>> f tree =
>>
>>   let
>>
>> a = ... something ...
>>
>>   in
>>
>> case tree of
>>
>>   Leaf x -> let b = ... in ... using a and b ...
>>
>>   Node s t -> let c = ... in ... using a and c ...
>>
>>
>>
>> ​
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>>
>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>>
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

Janis, the following compiles for me: …

Right, where does not work for expressions, but for right-hand sides, of
which pattern match branches are an instance.

The next question would be, still under the assumption that a choice has to
be made between where and let because both won’t be made available at the
same time, how well “where-only” would work if in addition one wants to
have a local binding that spans all pattern match branches, i.e., something
one would currently write in Elm like so:

f tree =
  let
a = ... something ...
  in
case tree of
  Leaf x -> let b = ... in ... using a and b ...
  Node s t -> let c = ... in ... using a and c ...

​

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

Ah, actually one more thought, I don’t remember whether it was considered
in the original discussion:

The situation of where vs. let is a bit different in Elm than in Haskell
via the point that Elm does not allow multiple equations for a function.
Concretely, in Haskell one can have:

f (Leaf x) = some expression
  where ... some local definitions involving x ...f (Node s t) = some
other expresion
  where ... some local definitions involving s and t ...

That’s easy to translate into an Elm form

f tree =
  case tree of
 Leaf x -> ...
 Node s t -> ...

if one may use let-bindings in the branches.

But if Elm only had where, and it would work like in Haskell, what would
you do? Because the following is not legal in Haskell:

f tree =
  case tree of
Leaf x -> some expression
  where ... some local definitions involving x ...
Node s t -> some other expression
  where ... some local definitions involving s and t ...

​

2016-12-31 23:46 GMT+01:00 Colin Woodbury :

> > it is counterproductive to not up front discuss the actual alternatives
>
> While I think `let` is always an anti-pattern, I don't think it needs to
> be removed if there is support for it. The "there must only be one way"
> argument is moot so long so long as the points raised above are left
> unaddressed. In general, I think that that philosophy remains an ideal
> detached from the reality of programming (and the mathematics behind it).
>
> > And I don’t think that lambda + let was refuted.
>
> I will have to dig back into those refactoring examples and see what was
> missed, if anything.
>
> > Make an experiment...
>
> Haha I suppose your 20 years beats my 5. That said, I'd never give up
> `where`, but also never do local binds in lambdas. I like the idea of that
> experiment, and will put it together tomorrow, posting the questions here
> beforehand to make sure they're fair. A google poll posted across IRC,
> Reddit, and Twitter ought to be representative. Can I trust that the
> results will be respected, at least within the scope of this debate? It's
> been made abundantly clear that Haskellers aren't the target audience for
> Elm.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

I am not myself convinced that “there must only be one way” is always a
useful philosophy. But I don’t get to decide about when it is followed in
the Elm design. The reality may simply be that there is no way to get both
let and where into Elm, that’s why I thought it “dangerous” to consider
where as an isolated matter, as if adding it without removing let was even
an option. (I can’t say whether it is an option.)

About this:

Can I trust that the results will be respected, at least within the scope
of this debate?

I can only speak for myself. Of course, having proposed the experiment, I
will not anymore claim that a majority of experienced Haskell programmers
would prefer abandoning where over abandoning let if the data says
otherwise. Whether that “admission” of mine would buy you anything in this
debate is another matter. I don’t speak for anyone than myself here anyway.
And it’s not like it is exactly my opinion that keeps you from getting where
in Elm. :-)
​

2016-12-31 23:46 GMT+01:00 Colin Woodbury :

> > it is counterproductive to not up front discuss the actual alternatives
>
> While I think `let` is always an anti-pattern, I don't think it needs to
> be removed if there is support for it. The "there must only be one way"
> argument is moot so long so long as the points raised above are left
> unaddressed. In general, I think that that philosophy remains an ideal
> detached from the reality of programming (and the mathematics behind it).
>
> > And I don’t think that lambda + let was refuted.
>
> I will have to dig back into those refactoring examples and see what was
> missed, if anything.
>
> > Make an experiment...
>
> Haha I suppose your 20 years beats my 5. That said, I'd never give up
> `where`, but also never do local binds in lambdas. I like the idea of that
> experiment, and will put it together tomorrow, posting the questions here
> beforehand to make sure they're fair. A google poll posted across IRC,
> Reddit, and Twitter ought to be representative. Can I trust that the
> results will be respected, at least within the scope of this debate? It's
> been made abundantly clear that Haskellers aren't the target audience for
> Elm.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

I don’t think it is possible to first decide about where and then “whether
let will be dropped”. I am fine with adding where. I am absolutely against
dropping let. So if first where is added, and only then the argument “but
we must not have two ways of doing almost the same thing” kicks in, then
you will want to discuss about dropping let, whereas I will start arguing
that if one must be dropped, then where is the one. :-)

If I am not alone in this, then it is counterproductive to not up front
discuss the actual alternatives “only let“, “only where“, “where and let“.

And I don’t think that lambda + let was refuted. It is fine to encourage as
a style guide that anonymous functions best do not have local bindings
inside. It is a different matter altogether to actually outlaw those two to
ever be used together. It seriously hampers the use/combination of
functional features. My comment in the earlier discussion that was mainly
on this point was this
.
That was written a long time ago, I don’t have the details of the code
present in mind anymore, so I can’t tell whether I feel 100% like I did
back then on that particular example. But I can suggest this:

Make an experiment asking experienced Haskell programmers what they would
chose if they had to give up one of where and let from their language. I
bet that (being aware giving up let would mean they can’t have local
definitions inside a lambda-expression anymore), the majority would chose
to give up where.

In case you want to start counting: Here is one experienced Haskell
programmer who would chose to give up where in that case. (I have been
programming Haskell for 20 years next summer.)
​

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

You frame the discussion as being about adding "where" or not adding
"where". But the actual discussion in the past was not so clearly such. It
seemed to be more about dropping "let" and replacing it with "where".

Also, in connection with the complications of "where" combined with
anonymous functions, you simply say "Don't". Thus, you are ignoring the
counter-point to that stance which I made in that earlier discussion, and
which was quoted by Max earlier today on the mailing list. Can you address
that? (It was about refactoring.)

Colin Woodbury  schrieb am Sa. 31. Dez. 2016 um 20:36:

> *On `where`*
>
> History: This debate is on-going since May 2014.
>
> The aggregate claim: `where` clauses are superior to `let-in` both
> technically
> and aesthetically. It was a mistake from the beginning to choose `let` over
> `where`. They should, at the very least, coexist.
>
> Below I've summarized arguments made both for and against adding `where` to
> Elm. A topic tagged with "For" means it argues in favour of adding `where`.
> "Against" means the opposite.
>
> *Technical Arguments*
>
> ***For: Intent First***
>
> Elm is FP, and therefore lends itself to declarative programming. The
> following is easier for devs to read, thus increasing code
> comprehensibility,
> thus reducing dev time, thus saving companies money:
>
> foo : (List A, Int)
>
> foo = (my ++ intent, goes - here)
>
>   where my = ...
>
> intent = ...
>
> goes = ...
>
> here = ...
>
>
> Post by Yashaka detailing why `where` is better for declarative
> programming:
> https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-207841658
>
> Downside-up breaks logical flow:
> https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-221263715
>
> There have also been multiple copy-cat issues opened on Github, detailing
> this as the primary reason to add `where`.
>
> ***For: Intent-to-return-type Distance***
>
> Minimizing the distance between your "intent" and your return type
> increases
> the ability to understand a function.
>
> foo : (List A, Int)
>
> foo = (my ++ intent, goes - here)
>
>   where ...
>
>
> Our eyes move very little when confirming the type of our intent. To
> contrast:
>
> foo : (List A, Int)
>
> foo =
>
>   let my = ...
>
>   intent = ...
>
>   goes = ...
>
>   here = ...
>
>   in (my ++ intent, goes - here)
>
>
> This causes the "zig-zag" reading as mentioned elsewhere.
>
> ***For: "let" goes against Elm's own style guide***
>
> `let` causes "dirtier" git diffs after changing a function:
> https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-269137011
>
> ***Against: `let` can be used in lambdas, `where` can't***
>
> Claim: `let` is more general than `where`.
> https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-103122010
>
> My thought: Never use `let` in a lambda. Combining local definitions and
> anonymous functions is always an anti-pattern. If your lambda gets to the
> point where you need bound names to simplify things, factor all of it out
> into a `where` below the function:
>
> -- | Haskell
> bar :: [a] -> b
>
> bar = foldl f someAccVal
>
>   where f acc x = ... -- complicated lambda
>
>
> A real example:
> https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-103349671
>
> ***Against: Use "let" more cleverly***
>
> From Joey Eremondi:
>
> > Use:
>  let
>ret = some_expresssion_with_p1_to_pk
>p1 = e1
>...
>pk = ek
>  in
>ret
>
> The idea being that you gain the advantage of declaring "intent first"
> using
> existing syntax. Yet this pattern could be called unidiomatic by Elm's own
> standards. Also, as mentioned by Oliver, you need to "zig-zag read" anyway
> to make sure `ret` was used correctly in the "in" section.
>
> *Philosophical Arguments*
>
> ***Against: `let` "resonates" with JS devs more***
>
> From Evan:
>
> > Is this something that registers at all for a JS programmer?
>
> From Max:
>
> > I think let-clauses are much more natural coming from imperative
> languages,
> > and Elm's target audience is JS devs, not Haskell devs.
>
> This argument has never been a strong one to me. You're already asking JS
> devs to learn an entirely new language with radically different syntax and
> concepts. Yet "let" is supposed to make them feel at home somehow? No, if
> they're already learning new syntax and a new paradigm, it is not a stretch
> to ask them to get used to "intent first".
>
> It doesn't matter what is intuitive to imperative programmers. Elm is not
> imperative. If Evan didn't think FP was the superior paradigm, he wouldn't
> have written an FP language, or used Haskell to write it.
>
> ***Against: There should be only one way to do things in Elm***
>
> From Max:
>
> > Elm's philosophy has been "there's only one way to do it" ...
>
> This is brought up often in these discussions and in the Elm guide. It's a
> well-intentioned idea, but I don't think it matches the reality of
> programming. Particularly, ple

Re: [elm-discuss] What is this? type Decoder a = Decoder

[Janis Voigtländer]

Ignore it. It’s an internal detail, “cheating” the Elm type system inside
the core library, because the Decoder type is actually implemented in
JavaScript. That strange definition inside Elm is just a placeholder to
prevent the compiler from complaining.
​

2016-12-30 0:17 GMT+01:00 Adrian Ribao :

> Hi,
>
> I'm reading the source code of Json/Decode.elm and I find this code:
>
>  type Decoder a = Decoder
>
> I've been working with elm for a few days now and I don't know what this
> does exactly. I guess is a recursive union type, but I don't understand how
> it works or why is useful.
>
> Thanks,
>
> Adrián
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Period(.) in repository field of elm-package.json generates erroneous code

[Janis Voigtländer]

I'm sure there is an issue already open about this in one of the Elm Github 
repositories. So yes, you are not the first to hit this. Please check and read 
there, also for status and possible work arounds. 

> Am 17.12.2016 um 14:52 schrieb fxmy wang :
> 
> Hello guys, so when I was following some tutorial and decide to build some 
> github pages with elm.
> 
> So I updated elm-package.json file like this
> 
> "repository": "https://github.com/someguy/someguy.github.io.git";
> elm-make didn’t complain a thing. But as soon as I load the page in browser I 
> get js error:
> Uncaught SyntaxError: Unexpected token .
> and the corresponding code :
> 
> var _someguy$someguy.github.io$BlogFxmy_Main$subscriptions = function (model) 
> {
> return _elm_lang$core$Platform_Sub$none;
> };
> As long as I remove those periods away everything works fine.
> 
> https://github.com/someguy/someguygithubio.git
> Just wondering/in case anyone has been bit by this =)
> And any possibility to work around this?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

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

[Janis Voigtländer]

>
> Having the behavior you expect? So if you write List.foldl (++) "" ["a",
> "b", "c"], you *expect* to get "cba"?
>

Yes, if I looked at the type of List.foldl first (or still had it in mind).
Which is exactly what my statement about "expected" was conditioned by. Not
more, not less.

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

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

[Janis Voigtländer]

Well, both in terms of "described" and "expected", all it takes is to have a 
look at the function's type. I personally often don't care much about prose in 
function documentation. For this specific function, take a look at the type 
(the placement of "a"s and "b"s) and that together with the "l" mnemonic from 
the function's name describes pretty much exactly how list elements will be 
combined. Or am I overlooking right now another way in which a function of that 
polymorphic type could process a list from left to right while producing some 
output? 

And likewise, seeing that function signature and knowing that the function is 
not the/a right-fold, there is only exactly one behavior I would expect from 
it, and it's the one it indeed has. :-)

(Of course, if the function had the implementation you want it to have, it 
would also have a different type, and that type would be equally descriptive 
for that other implementation's behavior, and would also raise exactly the 
correct expectations for that implementation.)

> Am 15.12.2016 um 23:13 schrieb Kasey Speakman :
> 
> It's not only a matter of preference, but getting the result that you expect 
> from the statement. Whether you look at visual expansion or the way the 
> operation is defined most other places, I'm not sure how it could be 
> considered working as described much less working as expected. Maybe it is 
> working as intended, but that's not a criteria I'm basing my statements on.
> 
> On Thursday, December 15, 2016 at 3:04:31 PM UTC-6, Janis Voigtländer wrote:
>> 
>>> The two examples you provide, the first is left-to-right on both input and 
>>> output. The other (Elm's) is not. Right fold is right-to-left on both input 
>>> and output. The lack of symmetry between the two operations only reinforces 
>>> the issue.
>> 
>> I don't disagree with your preference for symmetry. I just pointed out that 
>> if one considers processing order on the input (only), there is no basis to 
>> say that Elm's foldl is wrong or not left-to-right. That one should consider 
>> both input and output order/nesting when pondering the name of this function 
>> seems not to have been a principle of the maker of that decision.
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

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

[Janis Voigtländer]

>
> The two examples you provide, the first is left-to-right on *both* input
> and output. The other (Elm's) is not. Right fold is right-to-left on
> *both* input and output. The lack of symmetry between the two operations
> only reinforces the issue.
>

I don't disagree with your preference for symmetry. I just pointed out that
if one considers processing order on the input (only), there is no basis to
say that Elm's foldl is wrong or not left-to-right. That one should
consider both input and output order/nesting when pondering the name of
this function seems not to have been a principle of the maker of that
decision.

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

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

[Janis Voigtländer]

I would like to point out that: I’m sure neither of us is too stupid to
know what the other means. :-)

And I don’t think there is no basis to discuss these aspects. In fact, here
is a possible explanation of why this all seems so fuzzy: One could
distinguish between “from left to right in terms of the input” and “from
left to right in the output”. Then:

   - ((0 - 1) - 2) - 3 processes elements from left to right in terms of
   the input and happens to produce an expression that is nested from left to
   right in the output
   - 3 - (2 - (1 - 0)) processes elements from left to right in terms of
   the input and happens to produce an expression that is nested from right to
   left in the output

The distinction you make between “head to tail” and “left to right” (as if
you would be fine with the current Elm behavior of foldl aka foldLeftToRight
if it were simply called foldHeadToTail instead) is not one I can relate to.
​

2016-12-15 20:31 GMT+01:00 Kasey Speakman :

> foldl doesn't say it folds head to tail (which would be accurate). It says
> it folds from the left ("to the right" is understood... where else are you
> going to go from the left?).
>
> I'm not going to quibble over what "left" is, nor what processing
> something from the left to right means. If that's not understood between
> us, then we don't have enough basis to discuss that aspect.
>
> But I would like to point out that: the fact that it is a source of
> confusion only brings to the surface the imprecision of its name.
>
> On Thursday, December 15, 2016 at 1:05:14 PM UTC-6, Janis Voigtländer
> wrote:
>>
>> And I do get the mathematically wrong answer on foldl when using
>>> mathematically non-associative operations (like subtraction). That's
>>> provided we agree on the definition of which side of the list is the "left"
>>> side.
>>
>> Well, still not quite for me. I’m sure we both agree what the “left” side
>> of the list is. And still I don’t think there is an argument to make that
>> hence Elm’ foldl‘s answer is mathematically wrong. The fact that we
>> agree what the left side of the list is does not mean that foldl (-) 0
>> [1,2,3] needs to evaluate to ((0 - 1) - 2) -3. It can evaluate to 3 - (2
>> - (1 - 0)) without us disagreeing what is “left”. In other words,
>> “leftiness” is not at issue here. Both ((0 - 1) - 2) -3 and 3 - (2 - (1
>> - 0)) do work “from the left”. They combine elements in the order in
>> which they appear in the list *from left to right*. One could argue that
>> the real thing at issue here is not what “left” means, but what “folding”
>> means. You take it to mean to literally replace :: by (-) and you are
>> only willing to argue about how the result is bracketed. But one can take
>> “folding” to simply mean that stuff gets accumulated via an operator, and
>> “left folding” then means that more-left-sitting elements get accumulated
>> earlier. And Elm’s foldl is perfectly mathematically correct according
>> to this meaning.
>>
>> Of course, that’s back to a point I made already the other day. There’s
>> nothing “mathematically wrong” about Elm’s foldl unless one postulates
>> “mathematically correct” to mean “ foldl needs to be the specific
>> operation it is in Haskell etc.” But that’s not a mathematical argument.
>> ​
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Janis Voigtländer]

And I do get the mathematically wrong answer on foldl when using
> mathematically non-associative operations (like subtraction). That's
> provided we agree on the definition of which side of the list is the "left"
> side.

Well, still not quite for me. I’m sure we both agree what the “left” side
of the list is. And still I don’t think there is an argument to make that
hence Elm’ foldl‘s answer is mathematically wrong. The fact that we agree
what the left side of the list is does not mean that foldl (-) 0 [1,2,3]
needs to evaluate to ((0 - 1) - 2) -3. It can evaluate to 3 - (2 - (1 - 0))
without us disagreeing what is “left”. In other words, “leftiness” is not
at issue here. Both ((0 - 1) - 2) -3 and 3 - (2 - (1 - 0)) do work “from
the left”. They combine elements in the order in which they appear in the
list *from left to right*. One could argue that the real thing at issue
here is not what “left” means, but what “folding” means. You take it to
mean to literally replace :: by (-) and you are only willing to argue about
how the result is bracketed. But one can take “folding” to simply mean that
stuff gets accumulated via an operator, and “left folding” then means that
more-left-sitting elements get accumulated earlier. And Elm’s foldl is
perfectly mathematically correct according to this meaning.

Of course, that’s back to a point I made already the other day. There’s
nothing “mathematically wrong” about Elm’s foldl unless one postulates
“mathematically correct” to mean “ foldl needs to be the specific operation
it is in Haskell etc.” But that’s not a mathematical argument.
​

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

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

[Janis Voigtländer]

I do know how foldl is in other languages. And that it is different in
those other languages than it is in Elm. And I even agree that it would be
better that foldl in Elm is as in other languages (or Haskell,
specifically). I think I even argued for this on this mailing list in the
past.

But all this is not what my message to you was about. I pointed out that
you have no argument for this position that is of the form “… because of
mathematics”. All the argument you (or I) have is that other languages do
something different and that it would be nicer if Elm behaved like those,
also because what those do is easier to explain/visualize. You didn’t seem
to acknowledge that this is the only argument you have, before. Your latest
message suggests you now do see that this is the only argument you have.
(It’s a fine argument. But it’s only this one, not a stronger mathematical
argument as you previously tried to make exist.)
​

2016-12-15 16:27 GMT+01:00 Kasey Speakman :

> I read the associativity article. You should examine this wikipedia
> article on fold
> <https://en.wikipedia.org/wiki/Fold_(higher-order_function)>.
>
> OCaml, F#, Haskell, Scala, Clojure, Elixir, etc. all have left folds as
> described in this article. Elm does not. I included a quote from it below.
>
> "The folding of the list [1,2,3,4,5] with the addition operator would
> result in 15, the sum of the elements of the list [1,2,3,4,5]. To a rough
> approximation, one can think of this fold as replacing the commas in the
> list with the + operation, giving 1 + 2 + 3 + 4 + 5."
>
> Elm would generate 5 + 4 + 3 + 2 + 1. Since + is associative it does not
> matter. But using -, Elm's result would be incorrect.
>
> So when you go from Elm on the front end to  language here> on the back end, Elm's current foldl syntax lays something
> on the floor for you to trip over.
>
> On Saturday, December 10, 2016 at 12:44:30 AM UTC-6, Janis Voigtländer
> wrote:
>>
>> Kasey, you keep talking as if there were a mathematical, semantic concept
>> of “left-associativity” (and the same for “right-associativity”). But there
>> isn’t. Or can you give a definition?
>>
>> A definition of the mathematical, semantic concept of “associativity” is:
>> “An operator is associative if applying that operator to a and b (in
>> that order) and then applying it to the result of that and c (in that
>> order) evaluates to the same result as applying it to a and to the
>> result of applying it to b and c (in those orders).” No corresponding
>> concept of “left-associativity” exists.
>>
>> Reaching for something like “left-associativity means that a op b op c
>> should be read as (a op b) op c“ means that you are talking of a parsing
>> convention, not a mathematical property of the operator.
>>
>> And all that is relevant because you are trying to make an argument about
>> the behavior of some function being “mathematically wrong”, and basing that
>> on something like “because it does not respect left-associativity”, which
>> is moot given that there is no semantic property that you could state and
>> see violated.
>>
>> Similarly, you make a statement about “current foldl does not fold from
>> the left”, but haven’t defined semantically what it means to “fold from the
>> left”. One such definition could be “folding from the left means that the
>> left-most element is first combined with the second-left-most element
>> before any other elements are used”. In that sense, current foldl *is*
>> folding from the left. If you want to say that it is not, you have to
>> provide an alternative definition of the concept of “folding from the
>> left”. Can you? Can you tell us what it is?
>>
>> Aside: About the concepts of associativity, you may want to compare
>> https://en.wikipedia.org/wiki/Operator_associativity and
>> https://en.wikipedia.org/wiki/Associative_property, and to consider the
>> explicit pointer from the former to the latter as regards “the mathematical
>> concept of associativity”, as well as taking note of the fact that the
>> latter page does not mention anything like “left-associativity” and
>> “right-associativity” (because, I repeat, those do not exist as
>> mathematical, semantical-as-opposed-to-syntactical concepts).
>> ​
>>
>> 2016-12-10 6:43 GMT+01:00 Kasey Speakman :
>>
>>> Minor term correction. String concatenation isn't left-associative (duh
>>> on my part). It's just not commutative (the order can't be swapped and
>>> still get the same answer, unlike addition/multi).
>>>
>>> On Friday, December 9, 2016 at 11:15:04 PM UTC-6, Kasey Speakman wrote:
>&g

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

[Janis Voigtländer]

Okay, so I think that your implementation strategy is viable and addresses
the use cases that the earlier tick batching trick addressed. One could do
this as you propose with tasks, handling the “what about chained
continuations?” concern (that I had brought up) by deferring any andThened
tasks that are not Task.succeeds to later, not even attempting to include
their result messages into the current “epoch”.

I wonder how predictable this implementation would be for a user of
animations/ticks. They would have to keep a model in mind of what happens
when. The situation with non-chainable tick effects is conceptually
simpler. Or, to put it differently, maybe the actual use cases for tick
effects are all such that one only wants to “trigger something in the next
epoch directly”, and giving the user the ability to andThen on a tick may
tempt them into bad structuring of their code? Constraints in an API can be
very valuable, so if there are certain effects (ticks and possibly others)
for which better user code will result from taking the ability of
andThen-chaining
away from the user, then that would be justification for having a
separation between Task and Cmd (independently of the question of whether
andThen *can* be given some involved semantics on those effects). But I’m
not making a strong statement on that being the case here. And in any case,
you could reply that such a separation, taking andThen away from the user
for certain effects, could be put on top of an only-Tasks implementation
via a wrapper type that exposes only some of the Task operations; so it
would not require making both Task and Cmd primitive types. And you would
probably be right.
​

2016-12-13 1:54 GMT+01:00 Mark Hamburg :

> More "implementation" notes for this theoretical discussion. If you
> dropped off earlier, you can stay dropped off and leave it to Janis and me.
> If you are following along, here's another little tweak:
>
> I just looked at the implementation of tasks and saw that they make very
> heavy use of andThen. They probably don't need to be implemented this
> way, but they are. So, I would simplify the logic I present above and and
> get rid of the deferred queue. When an animation frame occurs, it enqueues
> all of the active tasks for the tick and then runs the execution queue
> until it is empty before actually invoking the view function. The moment
> something triggers code that does not resolve immediately, it ceases to be
> an issue ahead of the view rendering, but until that happens we chew
> through everything that is outstanding. This could be a bit more work
> before doing the animation rendering, but it's simpler code and simpler to
> explain.
>
> Mark
>
> On Mon, Dec 12, 2016 at 6:03 AM, Mark Hamburg 
> wrote:
>
>> Ah. Sorry. My misunderstanding. I went looking for the Effects.tick
>> replacement in 0.17+ and only found AnimationFrame.
>>
>> Mark
>>
>> On Sun, Dec 11, 2016 at 10:32 PM Janis Voigtländer <
>> janis.voigtlaen...@gmail.com> wrote:
>>
>>> Mark, wow, a lot of material. I’m not able to digest all of it right
>>> now. But something quick I want to say, because I have the impression that
>>> there is a misunderstanding about the current state of tick batching
>>> support.
>>>
>>>
>>> This:
>>>
>>>
>>>
>>>
>>> Since I wasn’t proposing to get rid of subscriptions and since this
>>> functionality is covered through subscriptions, my proposal arguably
>>> doesn’t cause a problem.
>>>
>>>
>>>
>>>
>>> baffles me. I’m not sure what you mean by “this functionality is covered
>>> through subscriptions”. Tick batching wasn’t covered through signals (the
>>> closest predecessors of subscriptions), and isn’t covered through
>>> subscriptions (or at all!) right now.
>>>
>>>
>>> Specifically and relatedly, concerning this:
>>>
>>>
>>>
>>>
>>> The special behavior for tick wasn’t particularly documented for the
>>> 0.16 Effects module and isn’t really documented for the 0.17+
>>> AnimationFrame module.
>>>
>>>
>>>
>>>
>>> I should clarify that the tick batching trick as existed in the 0.16
>>> Effects module is *not implemented* for Elm 0.17+. Apparently since
>>> gamey stuff is not anymore in Elm’s focus, Evan didn’t bring the “first
>>> ever effect manager” over to the new world when effect managers as such
>>> became a thing.
>>>
>>>
>>> (Did I indicate previously that tick batching as existed before is a
>>> thing currently in core or other 0.17/0.18 packages? I don’t thin

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

[Janis Voigtländer]

ueing new task executions.
>
> So, how could this work in a task-based scenario? I'm going to speak of
> tasks initiating and resolving to distinguish between when they have code
> invoked v when they deliver values.
>
> When a tick task initiates, it adds itself to the set of tick task
> executions for the current tick epoch.
>
> When we receive an animation frame call, we do the following:
>
>1. We grab the contents of the tick epoch set and reset the set to
>empty
>2. For each of the tick executions in the tick epoch set grabbed in
>(1), we resolve the execution using the current time. This means running
>down the network of tasks chained onto the executions. For cases where we
>map the result or error to a new result or error, we do so and keep working
>down the chain. For cases where we map the result or error to a new task,
>we queue that task for execution.
>3. We execute the view function.
>
> In this way, we deliver all of the updates that are simply dependent on
> the tick event or a mapping thereof while initiating any further
> computations that were waiting for the tick event.
>
> The other piece of concern is how task queueing works and when tasks get
> to execute. I would probably go for a structure on the task queue in which
> it is also divided into epochs. We process all of the tasks within an
> epoch. Any tasks produced during this processing as a result of andThen,
> etc. go in the next epoch. All tasks produced during an update go in the
> current epoch which we process at the end of the update. This design keeps
> chains of tasks from blocking other update processing. We could go further
> and pull tasks generated by tasks off of a queue that executes even more
> incrementally. The key point is that all of the tasks from an update get
> initiated immediately following the update and tasks initiated from other
> tasks happen as we have time to process them.
>
> In the case of ticks, this means that a tick task that initiates a chain
> will execute immediately following the update but a tick task that is
> initiated from some other task might get run at an arbitrary later time.
> (How arbitrary determines whether we can do things like write Task.tick
> |> Task.andThen (always Task.tick) in order to wait two ticks as opposed
> to at least two ticks.)
>
> To make animation frame updates as efficient as possible, we probably also
> want to avoid draining the task-initiated task queue until after the view
> function is run. That's not critical to the semantics but it could matter
> for performance.
>
> Now, maybe I've missed some other detail that matters, but as I've said
> the documentation for both Effects.tick and AnimationFrame is relatively
> thin on detailed semantics and requirements. But if I've gotten the
> concerns right, then I believe the above shows how a task-based system
> could do what is called for here. Am I missing something? I know I'm
> handwaving through some of the execution machinery, but my intuition from
> writing lots of promise systems in Lua says that this sort of structure
> would work.
>
> Mark
>
> On Sat, Dec 10, 2016 at 10:20 PM, Janis Voigtländer <
> janis.voigtlaen...@gmail.com> wrote:
>
>> In the case of ticks, what I gather from a read through of the code that
>> it does is guarantee that all of the tick requests placed between animation
>> frame strobes will all be delivered at the next animation frame strobe. Is
>> that a correct read?
>>
>> Yes, that is a correct read. But no, I don’t think that your post shows
>> the same can be done with tasks instead of commands. The reason is, as
>> previously mentioned, the existence of andThen for tasks. And your
>> “P.S.” does not address this, because you are not there considering what
>> the real complication with andThen is. The complication is not whether a
>> tick task involved in two andThen chains is run once or twice, the
>> complication is how to deal with the “continuations” in those two chains.
>> Let’s look at this with some example:
>>
>> In the Effects/Cmd world, using ticks would be like this:
>>
>>1. At some point, a command tick tagger1 reaches the runtime system,
>>where tagger1 : Time -> Msg for Msg being the program’s message type.
>>The runtime system will not do anything at that point, except for
>>registering in some internal state that a tick request was issued, and 
>> that
>>the tagger to use for it is tagger1. So essentially, the runtime
>>system (specifically, the effect manager) at that point stores the 
>> function
>>tagger1 in some list.
>>

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

[Janis Voigtländer]

In the case of ticks, what I gather from a read through of the code that it
does is guarantee that all of the tick requests placed between animation
frame strobes will all be delivered at the next animation frame strobe. Is
that a correct read?

Yes, that is a correct read. But no, I don’t think that your post shows the
same can be done with tasks instead of commands. The reason is, as
previously mentioned, the existence of andThen for tasks. And your “P.S.”
does not address this, because you are not there considering what the real
complication with andThen is. The complication is not whether a tick task
involved in two andThen chains is run once or twice, the complication is
how to deal with the “continuations” in those two chains. Let’s look at
this with some example:

In the Effects/Cmd world, using ticks would be like this:

   1. At some point, a command tick tagger1 reaches the runtime system,
   where tagger1 : Time -> Msg for Msg being the program’s message type.
   The runtime system will not do anything at that point, except for
   registering in some internal state that a tick request was issued, and that
   the tagger to use for it is tagger1. So essentially, the runtime system
   (specifically, the effect manager) at that point stores the function
   tagger1 in some list.
   2. At some point after that, but before the next animation frame
   happens, a command tick tagger2 reaches the runtime system. At that
   point, the effect manager adds the function tagger2 to said internal
   list.
   3. Some time later, the next animation frame is due. So the runtime
   system looks at its internal list, sees that there are [tagger1, tagger2],
   takes the current time stamp t, evaluates msg1 = tagger1 t and msg2 =
   tagger2 t, and passes msg1 and msg2 to the program’s update function one
   after the other *but without any intermediate view rendering*. If the
   update function creates additional effects/commands, the ones created
   from the calls of update with msg1 and msg2 are batched (so that
   actually the grouping together of updates will propagate to the future).

What about in your hypothetical world in which no Cmd abstraction exists,
but instead tick has type Task Never Time? Now instead of just using tick
with functions of type Time -> Msg, tick can be used in task chains, like tick
|> andThen cont with cont : Time -> Task Never Msg. Let’s look at such a
scenario:

   1. At some point, a task tick |> andThen cont1 reaches the runtime
   system, where cont1 : Time -> Task Never Msg. As above, the runtime
   system shouldn’t do anything at that point, except for registering in its
   internal state that there is this tick request and what to do when it
   eventually becomes active. The difference to above is that now instead of
   storing a function Time -> Msg for later use, the system has to store a
   function Time -> Task Never Msg. Fine enough.
   2. At some point after that, but before the next animation frame
   happens, a task tick |> andThen cont2 reaches the runtime system,
where cont2
   : Time -> Task Never Msg. Again, the effect manager should simply add
   that to the internal list of open tick requests.
   3. Some time later, the next animation frame is due. Now what? The
   runtime system knows that two tick requests are open. So of course it takes
   the current time stamp t and passes it to the two functions stored in
   its internal list. But instead of getting some msg1 : Msg and msg2 : Msg
   as above, it now gets some task1 = cont1 t : Task Never Msg and task2 =
   cont2 t : Task Never Msg. So *unlike above*, the strategy now cannot be
   to pass the relevant two messages to the program’s update function while
   ensuring that no view rendering happens in between (which was the whole
   point of tick batching in the animation scenario). Because those messages
   are simply not available right now. What is available are two tasks that
   when run will eventually return with messages (maybe after some http
   requests or whatever). So the runtime system can now fire off task1 and
   task2, but there is no way to tell when they will return, and certainly
   no assumption can be made that they will return still before the view
   rendering that is supposed to happen right now because we have an animation
   frame just due. In consequence, the whole point of tick batching is lost.
   We don’t get to ensure that groups of update calls get performed
   “atomically” without intermediate view rendering.

What do you think about the above? To me, it means that in the “just tasks”
world tick batching as in the “separate tasks and commands” world is not
possible (with the same quality).
​

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

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

[Janis Voigtländer]

Those are Elm 0.16 effects are something totally different. There is no
> reason why tick tasks couldn't be batched in their execution.

I disagree. I said I’m not authoritative, and meant that I can’t speak for
*all* the possible reasons that Task and Cmd cannot be unified into one
concept. But what I can say is:

   - Elm 0.16 effects are not something totally different. In fact, the
   Effects type from that package is the direct predecessor of the Cmd
   type, and the implementation of the “tick batching trick” was the first
   nontrivial effect manager (though that concept didn’t have a name back
   then). If you can substantiate the claim that 0.16’s Effects and 0.17’s
   Cmd type constructors are totally different, I would be interested to
   hear the argument.
   - I was the person who implemented the “tick batching trick” back then.
   I can tell from that experience that to make it work, an abstraction was
   needed (but preexisting, not “invented” by me) that absolutely mustn’t
   support an andThen operation like Task does. So on that specific count,
   I can with a bit of authority contradict your assertion that there is no
   reason why tick tasks couldn’t be batched (with the same quality as
   Effects/Cmds can).

​

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

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

[Janis Voigtländer]

You probably already suspect as much, but anyway: I think (and I’m not
authoritative at that) that the following part is the crux of the matter.

Commands tie into the effects manager system but that’s at this point still
an undocumented portion of Elm and I don’t see why effects managers could
not also work with tasks.

Do you have real reason to believe that effect managers could work with
tasks? That you don’t see why not seems to be a consequence of you not
seeing any information about their internals at all, right?

If you were told that indeed effect managers cannot work as well with tasks
(for example, that the “batching of ticks” trick mentioned in the
documentation of old
http://package.elm-lang.org/packages/evancz/elm-effects/2.0.1/Effects#toTask
would not be possible), would that make you retract the proposal to have
only Task, instead of Task and Cmd?
​

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

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

[Janis Voigtländer]

Kasey, you keep talking as if there were a mathematical, semantic concept
of “left-associativity” (and the same for “right-associativity”). But there
isn’t. Or can you give a definition?

A definition of the mathematical, semantic concept of “associativity” is:
“An operator is associative if applying that operator to a and b (in that
order) and then applying it to the result of that and c (in that order)
evaluates to the same result as applying it to a and to the result of
applying it to b and c (in those orders).” No corresponding concept of
“left-associativity” exists.

Reaching for something like “left-associativity means that a op b op c
should be read as (a op b) op c“ means that you are talking of a parsing
convention, not a mathematical property of the operator.

And all that is relevant because you are trying to make an argument about
the behavior of some function being “mathematically wrong”, and basing that
on something like “because it does not respect left-associativity”, which
is moot given that there is no semantic property that you could state and
see violated.

Similarly, you make a statement about “current foldl does not fold from the
left”, but haven’t defined semantically what it means to “fold from the
left”. One such definition could be “folding from the left means that the
left-most element is first combined with the second-left-most element
before any other elements are used”. In that sense, current foldl *is*
folding from the left. If you want to say that it is not, you have to
provide an alternative definition of the concept of “folding from the
left”. Can you? Can you tell us what it is?

Aside: About the concepts of associativity, you may want to compare
https://en.wikipedia.org/wiki/Operator_associativity and
https://en.wikipedia.org/wiki/Associative_property, and to consider the
explicit pointer from the former to the latter as regards “the mathematical
concept of associativity”, as well as taking note of the fact that the
latter page does not mention anything like “left-associativity” and
“right-associativity” (because, I repeat, those do not exist as
mathematical, semantical-as-opposed-to-syntactical concepts).
​

2016-12-10 6:43 GMT+01:00 Kasey Speakman :

> Minor term correction. String concatenation isn't left-associative (duh on
> my part). It's just not commutative (the order can't be swapped and still
> get the same answer, unlike addition/multi).
>
> On Friday, December 9, 2016 at 11:15:04 PM UTC-6, Kasey Speakman wrote:
>>
>> It's about associativity. Some operations have specific associativity
>> even when a and b are different types.
>>
>> Cons (::) is a great example of this. Cons is only right associative even
>> when `a` is Int and `b` is List Int. You cannot write `[] :: 1 :: 2 :: 3`,
>> because cons does not work from the left, but from the right: `1 :: 2 :: 3
>> :: []`.
>>
>> Switching to same type: subtraction and string concatenation are left
>> associative. Addition is (either-way) associative (order doesn't matter).
>>
>> When folding over a list, I need to know whether it will handle left- or
>> right-associative operators. The naming of foldl would suggest left. and
>> foldr would suggest right.
>>
>> Both fold functions in Elm are right associative (due to the a -> b -> b
>> folder definition). You can already define a left associative operation
>> with foldr using reverse and flip, so there's no reason for foldl to exist
>> except to be a convenience for using left associative operations. And it
>> doesn't event do that.
>>
>> I just said a bunch of words that probably nobody will bother (or has
>> time) to dig into to discover my point. So I'll leave you with this. Plug
>> this into Elm Hello World example
>> .
>>
>> import Html exposing (text)
>>
>> main =
>>  List.foldl (++) "" ["a", "b", "c"]
>>   == List.foldr (++) "" ["c", "b", "a"]
>>
>>   |> toString
>>   |> text
>>
>> Now ask yourself if you would expect the given outcome just by looking at
>> it.
>>
>> On Friday, December 9, 2016 at 4:17:50 PM UTC-6, Nick H wrote:
>>>
>>> I would disagree with "not expected in general." In general -- when a
>>> and b are different types -- Elm's API design guidelines should set you up
>>> to always expect a -> b -> b and never b -> a -> b. If the definition of
>>> foldl were changed to take the latter, it would be the only exception to
>>> this expectation.
>>>
>>> On Fri, Dec 9, 2016 at 7:03 AM, Kasey Speakman 
>>> wrote:
>>>
 Ok, correction

 List.foldl (-) 0 [1, 2, 3]
 -- returns 2
 -- expands to 3 - (2 - (1 - 0)) = 2

 During my testing last night, I had a typo (foldr instead of foldl)
 when I was testing the expansions. That was the center-building behavior.

 Using the form a -> b -> b is right-building regardless of the order
 the list is traversed. Traversing from head to tail is equivalent to
 reversing the list and building right. This is obviously broken fo

Re: [elm-discuss] Inter triplets communication.

[Janis Voigtländer]

2016-12-01 12:23 GMT+01:00 ‘Rupert Smith’ via Elm Discuss <
elm-discuss@googlegroups.com>:

Its not a solution I would reach for quickly, but decomposing record types
> and functions over them in this way does seem entirely permissable within
> the language.

It’s certainly doable/permissible in the language Elm, but it is strongly
discouraged by the designer of Elm. There have been several discussions
revolving around this in the past, on GitHub and the mailing list(s).
Search for something like “record nesting is better than record extension”
(that’s Evan’s claim). For example:
https://groups.google.com/d/msg/elm-discuss/AaL8iLjhEdU/pBe29vQdCgAJ.
​

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

[Janis Voigtländer]

I can't answer for OP, but for example doing the calculations for my project 
https://github.com/jvoigtlaender/circuits with Floats would be 
forbidding/forbidden. Determining whether a certain branch of the constructed 
circuit has current or not in a given switch setting, that needs exact 
comparisons between values computed by Gauss-Jordan. Calculating with Floats 
would be unsafe. 

> Am 26.11.2016 um 16:44 schrieb Max Goldstein :
> 
> What problem are you trying to solve that you can't do with Floats?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [elm-discuss] What is the motivation for using google groups?

[Janis Voigtländer]

Suggestion: Use the google group's search facility to check whether the thing 
you propose has been discussed before. :-)

Hint: It's the case, and I think that even the "discourse" suggestion was made 
and discussed then. 

> Am 25.11.2016 um 20:04 schrieb W. Brian Gourlie :
> 
> I find google groups to be a poor experience on many different levels, and 
> I'm wondering if there is any motivation for using it other than "it's free 
> and easy."  If there is any interest in an alternative, I would be willing to 
> set up a discourse instance, if only temporarily, to see if people may prefer 
> that instead.  It's much better suited for technical discussion as it 
> supports markdown and syntax highlighting, and is generally a much better UX.
> 
> If you haven't heard of discourse, you can get an idea of what it is by 
> checking out the rustlang forums: https://users.rust-lang.org/
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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

[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] 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] Maybe oneOf

[Janis Voigtländer]

2016-11-18 12:19 GMT+01:00 John Watson :

 It is interesting to me that Maybe.Extra's or
> 
> function is documented (quite readably) like this:
>
> ```elm
> Just 4 `or` Just 5 == Just 4
> ```
>
> but, of course, backticks have just been consigned to oblivion.
>
Well, see https://github.com/elm-community/maybe-extra/issues/28.

About your question how to write something with more than two values to be
“or”ed: How about using List.foldl or List.foldr with Maybe.Extra.or as the
combining function, and your three or more values put into a list?

Or, of course, use |> and either Maybe.Extra.or or Maybe.Extra.orElse.
​

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

[Janis Voigtländer]

See
https://github.com/elm-lang/core/commit/5f43ad84532bd4d462edf5c1ec22b7a62352a2db
and the comments there.
​

2016-11-18 10:51 GMT+01:00 John Watson :

> Maybe oneOf
> 
> has vanished in 0.18.  Is it intended that it will crop up somewhere in
> some other library or is there some sort of problem with it that I haven't
> tumbled to?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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] Async requests in 0.18.0

[Janis Voigtländer]

… which is equivalent to: handleRequest = Result.Extra.unpack FailMessage
SuccessMessage.
​

2016-11-16 14:22 GMT+01:00 Peter Damoc :

> The old Task.perform was creating either a success message (if it
> succeeded) or a fail message (if it failed)
> The current Task.perform cannot fail. It is used for Tasks that are known
> to succeed like requesting the window size or requesting some random
> number.
>
> The Task.attempt takes a function that takes a result (results encapsulate
> both the success and the failure) and produces a message based on that
> result.
>
> You could define something like:
>
> handleRequest result =
> case result of
> Ok val ->
> SuccessMessage val
> Err err ->
> FailMessage err
>
> and use it like this:
>
> someHttpCmd = Task.attempt handleRequest someHttpRequestTask
>
> Alternatively, you could just have only one message that takes a Result
> and handle each case in that message's part of the update as demonstrated
> by the Http example:
> http://elm-lang.org/examples/http
>
>
>
>
> On Wed, Nov 16, 2016 at 3:05 PM, Tim Bezhashvyly <
> tim.bezhashv...@gmail.com> wrote:
>
>> Sorry again if something obvious but Im not sure how now to make async
>> requests in 0.18.0.
>>
>> In 0.17.1 it was done with Task.perform where first parameter was a
>> success Msg, second - fail Msg and third is the task which execution result
>> is then passed to first function.
>>
>> As far as I understand now Task.attempt must be used but documentation is
>> not quite comprehensive. Could someone please advise?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Janis Voigtländer]

Where in 0.17 you had Task.perform f g, you can replace that in 0.18 by
simply Task.attempt (unpack f g), where unpack is from
http://package.elm-lang.org/packages/elm-community/result-extra/2.0.1.
​

2016-11-16 14:05 GMT+01:00 Tim Bezhashvyly :

> Sorry again if something obvious but Im not sure how now to make async
> requests in 0.18.0.
>
> In 0.17.1 it was done with Task.perform where first parameter was a
> success Msg, second - fail Msg and third is the task which execution result
> is then passed to first function.
>
> As far as I understand now Task.attempt must be used but documentation is
> not quite comprehensive. Could someone please advise?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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] Passing decoding results to another decoder in 0.18.0

[Janis Voigtländer]

"fieldName" := Json.list anotherDecoder becomes field "fieldName"
(Json.list anotherDecoder)
​

2016-11-16 11:44 GMT+01:00 Tim Bezhashvyly :

> Sorry if I'm asking something obvious but with changes to Json.Decode in
> 0.18.0 I'm not quite sure how to pass results of one decoder to another.
>
> So in 0.17.1 it was:
>
> decoder : Json.Decoder SomeType
> decoder =
>  Json.object1 identity
>  ("feildName" := Json.list anotherDecoder)
>
> object1 becomes map,  "feildName" := Json.list becomes field "fieldName"
> Json.list. Just not sure about anotherDecoder.
>
> Thank you.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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 0.18: What's wrong with "number" type?

[Janis Voigtländer]

Two part answer:

1) Type-checking with number types has been partly broken for a while. See
#1268 , #1270
, #1281
, #1316
, which are part of
#1373 . It's possible
that you found an additional fail case, maybe even one that did not exist
with Elm 0.17.1 but appeared with Elm 0.18.

2) In your specific case, maybe you can salvage the situation by replacing
"index - period >= 0" by "index >= period"?


2016-11-15 12:13 GMT+01:00 Pi :

> I'm trying to upgrade ggb/elm-trend to Elm 0.18 but got stuck at this
> error message:
>
> -- TYPE MISMATCH -- src/
> Seasonal.elm
>
> The left argument of (>=) is causing a type mismatch.
>
> 101|  index - period >= 0
>   ^^
> (>=) is expecting the left argument to be a:
>
> comparable
>
> But the left argument is:
>
> number
>
> Hint: Only ints, floats, chars, strings, lists, and tuples are comparable.
>
> Detected errors in 1 module.
>
> See the source code here: https://github.com/Pisys/elm-
> trend/blob/upgrade/0.18/src/Seasonal.elm#L101
>
> I have no idea what I should do about this error message.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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] Possible compiler bug while parsing type annotation in a let ?

[Janis Voigtländer]

What you encountered is https://github.com/elm-lang/elm-compiler/issues/1214,
and it is fixed in version 0.18 of the compiler.

Am Freitag, 11. November 2016 schrieb Matthieu Pizenberg :

> Hi,
>
> I just came accross one very strange compiler error and wanted to have the
> point of view of the community before creating any github issue.
> I wrote some code to create  tag more easily (seems to be trendy
> these days ^^) in a module Helpers.Views.elm. When I put a type annotation
> for a very simple variable (see gist here
> )
> *inside* a let expression, the compiler goes crazy XD and tell me that
> the type annotation of the function *containing* the let expression is
> wrong and tell me what it should be -> (apparently it should be what I
> wrote ^^).
>
> The type annotation is saying:
>
> (Maybe ( Int, a ) -> String)
> -> Array a
> -> Maybe ( Int, a )
> -> (Maybe ( Int, a ) -> b)
> -> Html b
>
> But I am inferring that the definition has this type:
>
> (Maybe ( Int, a ) -> String)
> -> Array a
> -> Maybe ( Int, a )
> -> (Maybe ( Int, a ) -> b)
> -> Html b
>
> All the corresponding code is on this gist
> 
> if you want to try by yourself.
> Any idea ?
> Should I fill a github 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] port Maybe field behavior

[Janis Voigtländer]

Isn't that exactly the following issue?

https://github.com/elm-lang/core/issues/476


> Am 11.11.2016 um 04:41 schrieb Max Goldstein :
> 
> I also think this is reasonable, although it's possible there's something I'm 
> missing.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Is Elm really wrong?

[Janis Voigtländer]

I think that was quite well put.

I agree.

2016-11-10 22:04 GMT+01:00 ‘Andrew Radford’ via Elm Discuss <
elm-discuss@googlegroups.com>:


> On Thursday, 10 November 2016 20:49:08 UTC, Max Goldstein wrote:
>>
>> What I meant was, Elm needs to choose differently from Haskell, at least
>> some of the time, or else there wouldn't be a reason for it to exist. And,
>> what seems weak and limited to one person can seem friendly and
>> easy-to-start-using to others.
>>
>
> I think that was quite well put.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Is Elm really wrong?

[Janis Voigtländer]

> "We" means the Elm community.


I disagree with the first sentence, then. "That the Elm community is
pissing off Haskellers is good" is not something I agree to.

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

Re: [elm-discuss] Re: Is Elm really wrong?

[Janis Voigtländer]

Finally, the fact that we're pissing off Haskellers is good. We're not
> making the language for them. We're making it for JS developers and those
> new to programming.

Sorry, I have to ask: Who is “we” in each of those three sentences?
​

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

Re: [elm-discuss] Re: Is Elm really wrong?

[Janis Voigtländer]

Max:

when is a 7-element tuple more useful than a record with named fields? For
> any purpose, not just comparison?

Is this “not just comparison” meant in an ironic way? Records with named
fields are not comparable, so if you were to suggest they should be used in
place of 7-tuples for comparison (among other things), that would seem odd.

In other words, maybe the attraction to use tuples instead of records
sometimes has to do with the fact that tuples are comparable while records
are not. And then, of course, after 6-tuples that stops to be true, because
even tuples are not comparable anymore from 7 onwards. Which can then lead
to disappointment. But saying “you shouldn’t even have used 6-tuples in the
first place” then is not appropriate, if using tuples was forced because
comparable was needed.
​

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

[Janis Voigtländer]

Yes, quite old news: https://github.com/elm-lang/core/issues/590

> Am 09.11.2016 um 19:27 schrieb John Orford :
> 
> I get an error when I try
> 
> 8 % 0
> 
> In 17.1. 
> 
> Is this old news?
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Sub.filterMap and Sub.concatMap

[Janis Voigtländer]

You may also want to read this later discussion: 
https://groups.google.com/forum/#!topic/elm-discuss/Ud7WzAhRsqE

> Am 31.10.2016 um 07:25 schrieb David Andrews :
> 
> I found a discussion from May that has many thoughts on this.
> 
> https://groups.google.com/d/msg/elm-discuss/u-6aCwaJezo/fu-HMPy6CQAJ
> 
> My actual use case is that I'm looking into implementing a 0.17-compatible 
> local storage library (which I'll post about in another thread), and would 
> love to be able to write
> eventsForKey : String -> Sub (Maybe String)
> eventsForKey key =
> events
> |> Sub.filterMap (\x -> if x.key == key then Just x.newValue else 
> Nothing)
> 
> which is implemented in terms of
> events : Sub (Maybe String)
> 
> 
> because I think it's a cleaner API than
> eventsForKey : String -> (Maybe String -> msg) -> msg -> Sub msg
> eventsForKey makeMsg noOp =
> events
> |> Sub.map (\x -> if x.key == key then makeMsg key.newValue else noOp)
> 
> 
>> On Monday, October 31, 2016 at 1:31:08 AM UTC-4, David Andrews wrote:
>> Right now, the Platform.Sub library has a map function which allows for 
>> transforming subscriptions.  However, the initial and modified subscriptions 
>> will always produce the same number of messages.  Are there plans to add 
>> filterMap and/or concatMap methods to Platform.Sub so that the number of 
>> messages can be modified?
>> 
>> A simple use case (not that you would actually do this) would be
>> Time.every Time.second identity
>> |> Sub.filterMap (\x -> if floor x % 2 == 0 then Just x else Nothing)
>> to implement
>> Time.every (2 * Time.second)
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [elm-discuss] What is an idiomatic way to extract a container component?

[Janis Voigtländer]

Drop the Message type definition from the outsourced module, and in that module 
make labeledContainer polymorphic by replacing all occurrences of Message in 
its type annotation by a type variable, such as (lowercase) "message". 

> Am 29.10.2016 um 13:35 schrieb Vlad GURDIGA :
> 
> Hey guys! 🤓
> 
> I’m trying to build an UI widget that would accept a label and a set of 
> fields and render them as a . Here is how it looks implemented as a 
> simple Elm function:
> 
> labeledContainer : String -> List (Html Message) -> Html Message
> labeledContainer labelText fieldList =
> let
> label =
> legend [] [ text labelText ]
> 
> in
> fieldset [] (label :: fieldList)
> 
> and then I use it like this:
> 
> view : Model -> Html Message
> view model =
> labeledContainer "A person section"
> [ personTypeField initialModel.personType
> , personTypeSpecificFields initialModel.personType
> ]
> 
> This is quite common a pattern, so I wanted to extract it as a module so that 
> I can reuse it for other widgets. I have tried to just move the 
> labeledContainer function in its own file, like this:
> 
> module LabeledContainer exposing (..)
> 
> import Html exposing (..)
> import Html.Attributes exposing (..)
> 
> 
> labeledContainer : String -> List (Html Message) -> Html Message
> labeledContainer labelText fieldList =
> let
> label =
> legend [] [ text labelText ]
> 
> in
> fieldset [] (label :: fieldList)
> 
> 
> type Message -- ??? This is required as per signature, but I don’t know what 
> should it be
> = None
> 
> and then import it, but the compiler throws this:
> 
> elm-make Main.elm --output=index.html
> -- TYPE MISMATCH - 
> ././PersonSection.elm
> 
> The type annotation for `view` does not match its definition.
> 
> 29| view : Model -> Html Message
>^
> The type annotation is saying:
> 
> Model -> Html Message
> 
> But I am inferring that the definition has this type:
> 
> Model -> Html LabeledContainer.Message
> 
> -- TYPE MISMATCH - 
> ././PersonSection.elm
> 
> The 2nd argument to function `labeledContainer` is causing a mismatch.
> 
> 31| labeledContainer "A person section"
> 32|>[ personTypeField initialModel.personType
> 33|>, personTypeSpecificFields initialModel.personType
> 34|>]
> 
> Function `labeledContainer` is expecting the 2nd argument to be:
> 
> List (Html LabeledContainer.Message)
> 
> But it is:
> 
> List (Html Message)
> 
> Hint: I always figure out the type of arguments from left to right. If an
> argument is acceptable when I check it, I assume it is "correct" in subsequent
> checks. So the problem may actually be in how previous arguments interact with
> the 2nd.
> 
> Detected errors in 1 module.
> 
> 🤔 I’m kind of lost and I’m wondering wether this is The Right Approach® to 
> reuse the labeledContainer function, and if not, any link/advice on how can I 
> find it would be awesome. 👷
> 
> Cheers! 🤓
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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] Suggested small edit to official Elm guide (for beginner-friendliness) ... and maybe the Elm error message?

[Janis Voigtländer]

You mean like this?

https://github.com/evancz/guide.elm-lang.org/pull/51/files
​

2016-10-28 9:29 GMT+02:00 Daniel Clarke :

> Hi everyone, I'm about 10 minutes into learning Elm (coming from
> JavaScript) and came across this example in the official guide
> :
>
> > over9000 powerLevel = \
> |   if powerLevel > 9000 then "It's over 9000!!!" else "meh"
> 
>
>
> When I first typed out this example I got this error message:
>
> I ran into something unexpected when parsing your code!
>
> 3|   over9000 powerLevel =
>  ^
> I am looking for one of the following things:
>
> end of input
> whitespace
>
> ...because I forgot to indent the second line.
>
> The guide could help beginners by pointing out that the indentation is
> required. (I assume it's part of the language?)
>
> Maybe the Elm error message could make this more explicit too? Any
> thoughts?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] why no more primes on 0.18 ?

[Janis Voigtländer]

I'm pretty sure that if this were on the dev list, we would be told that it 
should be on elm-discuss because the dev list is "for work, not for 
discussion". :-)

> Am 19.10.2016 um 22:41 schrieb Max Goldstein :
> 
> Hey folks, this really should be on the dev list. 
> 
> That said I agree with most of what's been said here. The place I'll miss 
> primes the most is actually the grammatical possessive: root'sValue, etc. But 
> that's not a huge deal. 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [elm-discuss] why no more primes on 0.18 ?

[Janis Voigtländer]

Nick, can you elaborate on why you think that my statement that foo
`function` bar corresponds to bar |> function foo rather than foo |>
function bar is wrong?
​

2016-10-19 9:55 GMT+02:00 Nick H :

> N
>
> On Wed, Oct 19, 2016 at 12:34 AM, Janis Voigtländer <
> janis.voigtlaen...@gmail.com> wrote:
>
>>
>> 2016-10-19 9:27 GMT+02:00 Nick H :
>>
>>> The only situation where backticks are useful is when you are doing a
>>> single function call, and "foo `function` bar" is easier to read than 
>>> "function
>>> foo bar". I haven't seen this crop up too many times. But if it does, "foo
>>> |> function bar" is just as good.
>>>
>>
>>
>> Except, "foo |> function bar" would be wrong. It would have to be "bar
>> |> function foo". :-)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Generating a batched Cmd of more than one msg from Task.perform

[Janis Voigtländer]

Why don’t you enrich your Msg type like so:

type Msg = ... | Several (List Msg)

and add a generic branch to your update function for processing a message
of the Several kind (something in the spirit of: update (Several msgs) =
List.foldr (... calling update recursively in an appropriate way ...) ...
msgs)?

Then when you call Task.perform you make it generate a *single* Msg that is
a Several [msg1, msg2] value. That way, you do have the “production of two
messages” at the place you want it expressed.
​

2016-10-19 13:51 GMT+02:00 Austin Bingham :

> Yes, my current approach does seem pretty solid from a theoretical point
> of view, but it feels like a poor expression of my intent. I have to create
> this "synthetic" intermediate msg which only exists for the purposes of the
> recursion, and then I have to handle the production of two messages in a
> different part of the code (the update function) from where I really ask
> for them (the call to Task.perform).
>
> I guess what I'm getting hung up on is the fact that this is all
> necessitated by the design of Task.perform. What I'm trying to do may be so
> marginal that it doesn't make sense to try modifying Task.perform to
> accommodate it, and that's not really what I'm looking for anyway. I just
> wanted to see if there was some existing trick for doing a task-local
> expression of multiple msgs.
>
> On Wednesday, October 19, 2016 at 1:11:30 PM UTC+2, Simon wrote:
>>
>> Sounds like you a recursively apply the update function, and that sounds
>> like pretty solid functional programming
>>
>>
>> On Wednesday, 19 October 2016 11:51:16 UTC+2, Austin Bingham wrote:
>>>
>>> Is there a way to make Task.perform produce a batched "Cmd msg" on
>>> success (or failure, for that matter)? I've got a case where, on success, I
>>> want to send out more than one Msg, but because the success handler for
>>> Task.perform can only generate one msg this isn't straightforward.
>>>
>>> What I'm doing now is creating an intermediate msg from the success
>>> handler. When my update function handles this intermediate msg, it is then
>>> able to generate the batched Cmd of two msgs that I want. This seems to
>>> work well, but it feels like pattern that only exists because of
>>> Task.perform's design.
>>>
>>> So, is there a better way? Am I missing something that would let me
>>> remove this intermediate message, or is that just the way things have to
>>> work?
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] why no more primes on 0.18 ?

[Janis Voigtländer]

???

2016-10-19 9:55 GMT+02:00 Nick H :

> N
>
> On Wed, Oct 19, 2016 at 12:34 AM, Janis Voigtländer <
> janis.voigtlaen...@gmail.com> wrote:
>
>>
>> 2016-10-19 9:27 GMT+02:00 Nick H :
>>
>>> The only situation where backticks are useful is when you are doing a
>>> single function call, and "foo `function` bar" is easier to read than 
>>> "function
>>> foo bar". I haven't seen this crop up too many times. But if it does, "foo
>>> |> function bar" is just as good.
>>>
>>
>>
>> Except, "foo |> function bar" would be wrong. It would have to be "bar
>> |> function foo". :-)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] why no more primes on 0.18 ?

[Janis Voigtländer]

2016-10-19 9:27 GMT+02:00 Nick H :

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


Except, "foo |> function bar" would be wrong. It would have to be "bar |>
function foo". :-)

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

Re: [elm-discuss] Elm Automaton "Step" src?

[Janis Voigtländer]

No, it has nothing to do with the scheduler. The constructor Step is
defined in this line
.
You probably should read up on union types, here
.
​

2016-10-19 0:19 GMT+02:00 Ben Greer :

> Hi All,
>
> I'm ned to Elm and trying to learn.
>
> I'm reading through the src of Automaton
>
> https://github.com/evancz/automaton/blob/master/src/Automaton.elm
>
> but I can't seem to find the definition to the all important "Step"
> function here. I've looked the Elm Core src and can't seem to find a
> matching built-in.
> Intuition tells me this is somehow related to Elm's scheduler stuff, but
> where does one look?
>
> -Ben
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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] List.filter -> List.keep?

[Janis Voigtländer]

If you wonder if this has been discussed before, why not, like, search the
mailing list archive for whether this has been discussed before? :-)

https://groups.google.com/d/msg/elm-discuss/s4ciEzTvhvU/HkkDZqrkzdMJ
​

2016-10-18 21:35 GMT+02:00 Duane Johnson :

> I saw @_chunglou's tweet
>  yesterday and
> wondered if this had been discussed before:
>
> "I can never, ever remember whether `filter` needs `true` or `false`.
> `keep` would be a nicer name."
>
> I agree `keep` would remove the ambiguity. Thoughts?
>
> -- Duane
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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] Outgoing port event ordering

[Janis Voigtländer]

Peter, the problem in David’s case is that the actions he wants to order
execution of are port data sending, and there is no “something lower level,
like Tasks” for that. The only API available for port data sending is Cmd
-based.
​

2016-10-15 23:06 GMT+02:00 Peter Damoc :

> Cmd.batch does not make any guarantee about the order of execution. It is
> use to bundle a batch of commands in one entity.
>
> If you need order of execution, you need to use something lower level,
> like Tasks where you have `andThen`.
>
>
> On Thu, Oct 13, 2016 at 9:59 PM, David Andrews 
> wrote:
>
>> When using Cmd.batch to send data over two ports, the ports receive the
>> events in the same order regardless of the order in which they appear in
>> the batch.  I would expect the events to occur in the order they appear in
>> the batch.
>>
>> Working example: https://daviddta.github.io/elm-port-order-bug/
>> Code: https://github.com/DavidDTA/elm-port-order-bug
>> Looking at the console, we see that port one always receives the event
>> before port two.
>>
>> As some motivation, consider two ports which both write to the same local
>> storage key.  Without a guarantee on the ordering of events, the two
>> subscriptions will race to write the key.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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] Properly using Task.perform with tasks that always succeed

[Janis Voigtländer]

The function from that thread exists as 
http://package.elm-lang.org/packages/NoRedInk/elm-task-extra/2.0.0/Task-Extra#performFailproof



> Am 15.10.2016 um 19:39 schrieb Austin Bingham :
> 
> I've got a situation where I've got task that will always succeed, and I want 
> to know the best practice for using it with Task.perform.
> 
> The task itself is a Task.sequence of tasks that may individually fail, and I 
> want to report the result - success or failure - for each of them. So there's 
> no meaningful failure mode that I can find for the final Task.perform.
> 
> I've seen a suggestion in this group for defining a performSucceed function 
> (https://groups.google.com/d/msg/elm-discuss/5Q9ktTuavgY/mGk3PVn7CgAJ), and 
> this seems perfectly reasonable to me. But I'm also trying to write elm as 
> idiomatically as I can, so I wanted to know if this is generally considered 
> "correct".
> 
> Similarly, if my approach (i.e. aggregating a bunch of results into a 
> sequence of success-failure Results) is wrong-headed, I'm happy to entertain 
> alternative implementations. 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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: control structure

[Janis Voigtländer]

Your statement about tail call elimination is wrong. The Elm compiler does it. 

> Am 13.10.2016 um 23:38 schrieb Kasey Speakman :
> 
> It probably sounds insane that Elm doesn't have `for` or `while`. It would to 
> me before exposure to functional programming.
> 
> There are prebuilt functions for working with collections like List and Array 
> which will take care of most needs.
> 
> When you find you need something a bit more custom, a recursive loop is the 
> normal way. Those take a little practice to get the feel for them.
> 
> Often when I write my own recursive loop, I later find that I can accomplish 
> the same by combining list operations or by just playing with List.foldr.
> 
> One current limitation of Elm is that there is no tail call elimination when 
> using a recursive loop, so if you write your own loop and have a large list, 
> you can get a stack overflow. In practice, this is not a typical problem due 
> to other factors. I.e. miles of data on the screen impacts performance, and 
> is not considered good UX.
> 
>> On Wednesday, October 12, 2016 at 5:52:31 AM UTC-5, Patricia Nicole 
>> Benedicto wrote:
>> hi can i ask what is the repetiton control structucture of this programming 
>> languages?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [elm-discuss] why -> Sub msg in ports instead of Sub Msg

[Janis Voigtländer]

Relevant:
http://faq.elm-community.org/17.html#what-is-the-difference-between-cmd-msg-and-cmd-msg
​

2016-10-13 18:42 GMT+02:00 António Ramos :

> I would like to know why Sub msg in lowercase in above code
>
> port suggestions : (List String -> msg) -> Sub 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.
>

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

[Janis Voigtländer]

https://github.com/elm-lang/svg/commit/41f979b6d5ee06cbbfde877e755aab3d521dd09f

> Am 11.10.2016 um 06:11 schrieb Jeff Russell :
> 
> I've been looking around the documentation for a function Svg.map : (a -> 
> msg) -> Svg a -> Svg msg, which would be exactly analogous to Html.App.map. 
> But I can't find this function anywhere. Did I miss it? Am I supposed to 
> handle nesting Svg-based graphical components in a different way from Html 
> components? Is it possible to write this function myself using the exposed 
> API for Svg? Am I using the Svg library in an unintended way, so this 
> question shouldn't even have come up? Thanks for any help you can offer.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Teaching children Elm

[Janis Voigtländer]

2016-10-10 10:18 GMT+02:00 Fedor Nezhivoi :

@Javis, do you have any plans of having an English translation?

Unfortunately, from my side this is only going to happen if I give the
course to a group of youths that speak better English than German.

But it might be possible to have a low effort translation using Google
Translate. I just experimented and took a random instruction page from my
course and sent it through Google Translate, and the result is remarkably
good (see below). Moreover, all the code of the exercises is of course
already in English rather than German.

Anyway, here is what Google Translate gives for the German instruction
block below the code block on
https://github.com/jvoigtlaender/Elm-Kurs/blob/master/pages/Counter.md.
Pretty good (though not completely accurate, it’s still just a machine
translation):

There are some things to explain:

We have to express what the “remembered state” should be at the beginning,
if there is no past to remember. Since we want to implement a simple
counter here, we use the number 0 for this.

We have to express how the state should change when an event occurs. This
is done in the update function. It uses case … of … to make a case
distinction on the event. Here, we will first react only to the event
“Empty button was pressed” (space), in this case, increase the counter
reading by 1.

To express that in any other case (when the empty key has been pressed), we
will use the line _ -> state. Such or similar lines should always exist in
the following.

In the scene function, the current state is now available as a further
input and can be used to calculate the output (ie the display to be
rendered). Here, we simply output the current counter reading directly. We
ignore the current mouse position and time (also in the update function).

By means of the displayWithState function, we bring everything together.

Task: Change the above program so that the counter starts at 10, is
increased by means of the arrow-up key and is reduced by means of the
arrow-down-key, but never drops below 0. In addition, the empty button
should now be able to set the counter to 0 at any time. (The left, up,
right and down event names exist for the four arrow keys.)

​

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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] Maybe.andThen with List.foldr type trick?

[Janis Voigtländer]

http://package.elm-lang.org/packages/elm-community/maybe-extra/2.0.0/Maybe-Extra#combine

You can also check that function's source code. 

> Am 08.10.2016 um 17:03 schrieb Max Goldstein :
> 
> The Elm compiler is correctly telling you that your list is a list of 
> functions that produce Maybes, but you said you had a list of Maybes.
> 
> If you wanted the first Just regardless of other values: List.filterMap 
> identity >> List.head
> 
> My advice is to check the lengths of the original list and the filterMap'd 
> list. If they're equal, take the head of the filterMap'd list. If not, 
> Nothing.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [elm-discuss] Re: How to decode a recursive JSON from a port?

[Janis Voigtländer]

2016-10-05 20:38 GMT+02:00 Wil Chung :

> I feel like I'm not getting exactly what to do in the case of a recursive
> model.
>

This is what you are to do in that case:
http://package.elm-lang.org/packages/elm-community/json-extra/1.1.0/Json-Decode-Extra#lazy

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

[Janis Voigtländer]

Have you searched in the mailing list archive? Your question is a recurring 
one. It already has answers. 

> Am 04.10.2016 um 19:49 schrieb Bulat Shamsutdinov 
> :
> 
> Hello everyone!
> 
> I'm an experienced developer but newbie in web. I chose to learn Elm in order 
> to avoid all the complexity with JS and it's ecosystem (learned JS and Node 
> on a decent level and feel like I don't want to touch it ever again without a 
> great need).
> 
> Is there something as good for the back-end? It would be great to use 
> something opinionated, light, simple and functional maybe. 
> 
> I learned myself some Golang and it is ok, I learned Node and it is not ok. 
> Are there any "Elm-way" options (maybe not with the language itself but with 
> the same philosophy)?
> 
> If there was no one to ask I would go with Golang, but there is)
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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] Teaching children Elm

[Janis Voigtländer]

I have concrete material (guided exercises) that I used with slightly older
youths, 16-18 y.o., here: https://github.com/jvoigtlaender/Elm-Kurs

Also, you might be interested in this mailing list thread
.
​

2016-10-04 7:33 GMT+02:00 Fedor Nezhivoi :

> Hello folks,
>
>
> Evan, Richard and the whole community as well as Elm language itself do a
> great job in teaching community. If you are staying with this community for
> a long time, you probably already can notice some improvements in your
> understanding of programming, API design, abstractions and etc. How can we
> take it even further?
>
>
> Recently I got an opportunity to share some knowledge about functional
> programming and programming in general. However target audience are
> children (mostly 14-16 y.o.) and I am a little bit stuck. Not only I've
> never been a teacher, but with children I expect it to be even harder
> because of curse of knowledge. On the other hand trying to teach some
> boring basics doesn't feel right, to be interesting it should be kind of
> journey.
>
>
> Previously there was some information about courses in USA where children
> are thought programming with Elm. So I am kindly ask people who are doing
> this to share your experience, tips, tricks and whatever may be helpful. It
> would be even better if you can share some actual 
> content/topics/lessons/exercises.
> If you know exact person, but they are not here, please, provide me with
> contacts.
>
>
> *I am kindly ask you to abstain from discussions and only participate if
> you have something concrete.*
>
>
> Have a nice day!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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] More than one argument in the receive port call?

[Janis Voigtländer]

2016-10-04 2:22 GMT+02:00 Wil C :

> It says to visit http://guide.elm-lang.org/effect_managers/
>

In the next release of the compiler it will correctly tell you to visit
https://guide.elm-lang.org/interop/javascript.html 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.

Re: [elm-discuss] I made Elm crash runtime...

[Janis Voigtländer]

2016-10-03 17:33 GMT+02:00 OvermindDL1 :

>  I'm curious which direction will be taken


Your curiosity can be satisfies here:
https://github.com/elm-lang/elm-compiler/commit/8b484abfb313f2877403b168e4d7229863f20ba1

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

[Janis Voigtländer]

That’s something LiquidHaskell does (
http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/). It’s way out of
scope for Elm’s type checker.
​

2016-10-02 16:40 GMT+02:00 Marco Perone :

> Some days ago I had an idea, which I don't know if it's worth exploring,
> so I'll just share it here and ask for some feedback.
>
> Thinking about how to handle only valid state of an application, I tought
> it would be nice if, for every function, we could be able to specify
> precisely its domain, instead of dealing with unacceptable input values
> with special return values (i.e. what we usually do with Option).
>
> Think for example about the `logBase` function in the `Core.Basics`
> package. Its type annotation is `logBase: Float -> Float -> Float`, where
> the first Float is the base of the logarithm and the second is the
> argument. Actually, a logarithm is defined only for a base positive and not
> equal to one and for a positive argument.
>
> At the moment the presence of invalid input values is handled returning
> `Infinity` or `NaN` when the logarithm is actually not defined.
>
> Wouldn't it be nicer if we could define the same function as something like
>
> logBase: (Float | > 0 && != 1) -> (Float | > 0) -> Float
>
> in a way that the compiler itself could check that we are invoking the
> function only with correct values to avoid NaN return values?
>
> As I said, I don't know if this is a good idea, and I don't know how much
> of a burder this would be to the compiler...
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Moving Color to evancz/graphics

[Janis Voigtländer]

Given this:

The Gradient type is opaque, so it’s impossible for anyone but
evancz/graphics to use it.

How about moving the Gradient type and functions related to it to
evancz/elm-graphics?
​

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

Re: [elm-discuss] Proposal: shorthand record names

[Janis Voigtländer]

That feature, for pattern matching, Elm already has.

> Am 24.09.2016 um 20:38 schrieb Dave Thomas :
> 
> I don't think its overly verbose as it is, ocaml has a feature called field 
> pruning:
> 
>> When the name of a variable coincides with the name of a record field, OCaml 
>> provides some handy syntactic shortcuts. For example, the pattern in the 
>> following function binds all of the fields in question to variables of the 
>> same name. 
>  
> let host_info_to_string { hostname; os_name; cpu_arch; timestamp; _ } =
>  sprintf "%s (%s / %s) <%s>" hostname os_name cpu_arch
>(Time.to_string timestamp)
> 
>  
> 
>> On Saturday, September 24, 2016 at 6:27:07 PM UTC+1, Joey Eremondi wrote:
>> Can you give a concrete example of what this would look like in Elm? Are you 
>> sure this is compatible with type inference?
>> 
>> 
>>> On Sep 24, 2016 10:46 AM, "Zane Hitchcox"  wrote:
>>> Shorthand property names like in javascript
>>> 
>>> 
>>> 
>>> These are a great feature, and maybe elm can steal something from 
>>> javascript for a change.
>>> 
>>> 
>>> 
>>> Like I see no reason for this overly-verbose syntax:
>>> 
>>> 
>>> 
>>> main : Program Never
>>> main =
>>> Html.App.program
>>> { init = init
>>> , view = view
>>> , update = update
>>> , subscriptions = subscriptions
>>> }
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [elm-discuss] Re: Some questions about types.

[Janis Voigtländer]

Exactly!

2016-09-21 15:50 GMT+02:00 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com>:

> On Wednesday, September 21, 2016 at 10:42:49 AM UTC+1, Janis Voigtländer
> wrote:
>>
>> This type is very special. The definition in Elm is solely a placeholder,
>> the actual implementation is in native code. You should not think further
>> about this trickery, assuming you want to program Elm, not
>> native-JS-in-the-runtime-of-Elm.
>>
>
> These are not the droids you are looking for. :-P
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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: 'comparable' recrods and union types?

[Janis Voigtländer]

Also, maybe you want to make a habit of first checking the
http://faq.elm-community.org/. Some questions you come with here are
readily answered there. For example, you would only have had to enter
“comparable” into the search box there to be pointed to two useful
question/answer pairs that might have helped you a lot:

http://faq.elm-community.org/#does-elm-have-ad-hoc-polymorphism-or-typeclasses

http://faq.elm-community.org/#which-special-type-variables-are-there-and-how-do-they-work
​

2016-09-21 15:42 GMT+02:00 Janis Voigtländer :

> Yes, there is. Here: http://package.elm-lang.org/
> packages/elm-lang/core/4.0.5/Basics#compare
> ​
>
> 2016-09-21 15:36 GMT+02:00 'Rupert Smith' via Elm Discuss <
> elm-discuss@googlegroups.com>:
>
>> On Wednesday, September 21, 2016 at 2:29:44 PM UTC+1, Rupert Smith wrote:
>>>
>>> There is an issue here noting that there is no way to make records or
>>> union types 'comparable':
>>>
>>> https://github.com/elm-lang/elm-compiler/issues/774
>>>
>>> Closed. Has this feature been implemented, or is it something that is
>>> not on the radar?
>>>
>>
>> Also, is there a complete list of all 'comparable' types somewhere in the
>> docs?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and 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: 'comparable' recrods and union types?

[Janis Voigtländer]

Yes, there is. Here:
http://package.elm-lang.org/packages/elm-lang/core/4.0.5/Basics#compare
​

2016-09-21 15:36 GMT+02:00 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com>:

> On Wednesday, September 21, 2016 at 2:29:44 PM UTC+1, Rupert Smith wrote:
>>
>> There is an issue here noting that there is no way to make records or
>> union types 'comparable':
>>
>> https://github.com/elm-lang/elm-compiler/issues/774
>>
>> Closed. Has this feature been implemented, or is it something that is not
>> on the radar?
>>
>
> Also, is there a complete list of all 'comparable' types somewhere in the
> docs?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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] 'comparable' recrods and union types?

[Janis Voigtländer]

Evan’s comment in that discussion should answer your question?

https://github.com/elm-lang/elm-compiler/issues/774#issuecomment-127834812
​

2016-09-21 15:29 GMT+02:00 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com>:

> There is an issue here noting that there is no way to make records or
> union types 'comparable':
>
> https://github.com/elm-lang/elm-compiler/issues/774
>
> Closed. Has this feature been implemented, or is it something that is not
> on the radar?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Some questions about types.

[Janis Voigtländer]

That’s because it is an effect module. There is no documentation yet about
writing effect modules. Quite deliberately, I think.
​

2016-09-21 11:48 GMT+02:00 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com>:

> On Tuesday, September 20, 2016 at 2:03:49 PM UTC+1, Rupert Smith wrote:
>>
>> The docs around the basics of syntax don't really cover this:
>> http://elm-lang.org/docs/syntax#type-annotations
>>
>
> In the module declaration for Task there is a 'where':
>
> effect module Task where { command = MyCmd } exposing
>
> with MyCmd later declared to be a type:
>
> type MyCmd msg =
>   T (Task Never msg)
>
> then later we see command used like a function:
>
> perform onFail onSuccess task = command (T (map onSuccess task `onError` \x
> -> succeed (onFail x)))
>
> can someone explain what is going on here? I can't find any documentation
> on the use of 'where' in a module declaration.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Some questions about types.

[Janis Voigtländer]

This type is very special. The definition in Elm is solely a placeholder,
the actual implementation is in native code. You should not think further
about this trickery, assuming you want to program Elm, not
native-JS-in-the-runtime-of-Elm.

2016-09-21 11:30 GMT+02:00 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com>:

> On Tuesday, September 20, 2016 at 4:25:42 PM UTC+1, Rupert Smith wrote:
>>
>> type Cmd msg = Cmd
>>
>
> I am still a bit perplexed by this. It is a parameterized type, but the
> parameter is thrown away and not used. I can only create one of them, since
> their is only one constructor.
>
> Given that, why do I have to use Cmd.none - if the only isntance of Cmd
> that can be constructed is Cmd, why not simply use Cmd instead of Cmd.none?
>
> Does this exist purely to make the commands created by the update function
> have a particular type, in order to constrain where and how that update
> function can be used?
>
> If the constructor takes no args, then Cmd must be encapsulating no
> context - I kind of thought the commands would be constructed with some
> context that tells the program what the command is, or how to execute it.
> That is a constructor like this:
>
> type Cmd msg = Cmd 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.
>

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

[Janis Voigtländer]

So the definition of List might look like:

type List a
= Nil
| Cons a (List a)

That’s exactly how the definition of List would look like if it didn’t have
a native implementation.

So it seems you already know everything.
​

2016-09-20 17:25 GMT+02:00 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com>:

> Some more questions about types. I just ran into the recursive 'type
> alias' issue:
>
> https://github.com/elm-lang/elm-compiler/blob/0.17.1/
> hints/recursive-alias.md
>
> which is clear enough. It seems a bit of a shame that some of this
> documentation is a bit buried away - it really feels like this should be in
> the syntax guide (or whatever chapter comes after the syntax guide).
> Anyway, the other questions:
>
> Can type definitions be recursive? as per ML, I think the answer is yes.
>
> type Expression
>   = Integer Int
>   | Sum Expression Expression
>
> for a simple syntax tree representing expressions over integers and
> addition.
>
> I have seen some type definitions like this:
>
> type Cmd msg = Cmd
>
> but I am more used to seeing type definitions that look like this:
>
> type Msg
>   = SomeMsg String
>   | ...
>
> What does the 'msg' parameter on this type do? Does it just mean that the
> type is polymorphic and the 'msg' is the type parameter? So the definition
> of List might look like:
>
> type List a
>  = Nil
>  | Cons a (List a)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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] Some questions about types.

[Janis Voigtländer]

http://package.elm-lang.org/packages/javcasas/elm-integer/latest
​

2016-09-20 15:08 GMT+02:00 Joey Eremondi :

> Both int and float end up as a JS number at the end of the day, so
> definitely bounded. Defer to the JS spec?
>
> Not sure about bignum, there's definitely not language support, but there
> might be a library doing it somewhere, and if not, someone should write
> one!
>
> On Sep 20, 2016 10:03 PM, "'Rupert Smith' via Elm Discuss" <
> elm-discuss@googlegroups.com> wrote:
>
>> Is Int unbounded? I mean is it a 'big integer' implementation as per ML,
>> or is it 64-bit or soe other limit?
>>
>> What is the precision of a Float? Is it the same as 64-bit IEEE 754?
>>
>> Is there a 'big decimal' representation?
>>
>> The docs around the basics of syntax don't really cover this:
>> http://elm-lang.org/docs/syntax#type-annotations
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and 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] Can you have a port that takes no args? What is its type?

[Janis Voigtländer]

See also https://github.com/evancz/guide.elm-lang.org/issues/34.
​

2016-09-16 16:36 GMT+02:00 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com>:

>
> On Friday, September 16, 2016 at 3:17:25 PM UTC+1, Joey Eremondi wrote:
>>
>> If you need this, make it take an arg of type (), which is just a
>> placeholder (0 element tuple to be precise, carries no data).
>>
>> port logout : () -> Cmd msg
>>
>
> Aha. Thanks.
>
>
>>
>> On Fri, Sep 16, 2016 at 7:13 AM, 'Rupert Smith' via Elm Discuss <
>> elm-d...@googlegroups.com> wrote:
>>
>>> port logout : Cmd msg
>>>
>>> yields:
>>>
>>> 13| port logout : Cmd msg
>>> ^
>>> You are saying it should be:
>>>
>>> Platform.Cmd.Cmd msg
>>>
>>> But you need to use the particular format described here:
>>>  Use --force to continue.
>>>
>>> But http://guide.elm-lang.org/effect_managers/ sheds no light.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Json Decode Issue

[Janis Voigtländer]

Your type "Players" is recursive in a way you almost certainly did not intend. 
That's what leads to this mismatch. 

> Am 16.09.2016 um 04:09 schrieb Mohammad Samman :
> 
> I have the following elm code:
> 
> import Json.Decode as Json exposing(..)
> import Result
> 
> type Players = Players (List Players)
> type alias Player = {
>   name: String
>   , team: Maybe Team
> }
> 
> type alias Team = {
>   name: String
>   , players: Maybe Players
> }
> 
> teamDecoder: Json.Decoder Team
> teamDecoder =
>   Json.object2 Team ("name" := Json.string) (Json.maybe ("players" := 
> playersDecoder))
> 
> playersDecoder: Json.Decoder Players
> playersDecoder =
>   Json.customDecoder (Json.list playerDecoder) (\pl ->
> Result.Ok (Players pl)
>   )
> 
> playerDecoder: Json.Decoder Player
> playerDecoder = 
>   Json.object2 Player ("name" := Json.string) (Json.maybe ("team" := 
> teamDecoder))
> 
> Compiling give me the following error
> 
> -- TYPE MISMATCH 
> ---
> The 2nd argument to function `customDecoder` is causing a mismatch.
> 26|>  Json.customDecoder (Json.list playerDecoder) (\pl ->
> 27|>Result.Ok (Players pl)
> Function `customDecoder` is expecting the 2nd argument to be:
> List { name : String, team : Maybe Team } -> Result String a
> But it is:
> List Players -> Result a Players
> Hint: I always figure out the type of arguments from left to right. If an
> argument is acceptable when I check it, I assume it is "correct" in subsequent
> checks. So the problem may actually be in how previous arguments interact with
> the 2nd.
> 
> I'm wondering why this is the case? Shouldn't the pl variable inside of the 
> anon func be a List Players based on the type signature of 
> Json.customDecoder? How can I decode into the Team type alias?
> 
> Thanks!
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [elm-discuss] Upgrading 0.16 `Effects.task <| Task.succeed` to 0.17

[Janis Voigtländer]

One of the following two pages/sections of the FAQ should solve that for
you:

http://faq.elm-community.org/17-tasks.html

http://faq.elm-community.org/17.html#how-do-i-generate-a-new-message-as-a-command
​

2016-09-15 20:30 GMT+02:00 Rex van der Spuy :

> Hi Everyone!
>
> I'm upgrading some complex old 0.16 code to 0.17 and came across this in
> my `update` function:
>
> ```
> (
>   model''
> , Effects.batch
> [ Effects.task <| Task.succeed FadeOutOldPage
> , Effects.task <| Task.succeed FadeInNewPage
> , Effects.task
> <| Task.succeed (UpdateInfoBox (InfoBox.UpdateData storyLevel
> inventoryQuantities storyPhaseChapter))
> ]
>  )
>
> ```
> Does anyone know what this should look like in 0.17?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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] Type Alias With Arguments

[Janis Voigtländer]

The feature "constructor functions for parametrized record type aliases" is 
gone. See the fourth row of the table under 
https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.16.md#updating-syntax

> Am 14.09.2016 um 22:08 schrieb Matic Zavadlal :
> 
> type alias WithLoadedIndicator a =
> { a | isLoaded : Bool }
> 
> 
> type alias WithSearchField a =
> { a | searchInput : String }
> 
> 
> type alias Tags =
> { available : List Tag
> , facets : List String
> }
> 
> 
> type alias Tag =
> { name : String
> , value : String
> }
> 
> 
> 
> 
> let
> ta =
> Tags
> []
> [ "subject", "professor", "school", "term", "class", "year" ]
> in
> (WithLoadedIndicator ta) False
> 
> I can't find any Elm reference for this type of type aliases in current Elm 
> syntax docs, but I remember they were once available. 
> Though I know how to use the concept and everything, Elm started to report 
> that WithLoadedIndicator type can't be found. 
> 
> Why does this happen?
> 
> Is this because of a leak of a constructor function or is it my error in code?
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [elm-discuss] Inherit function comment

[Janis Voigtländer]

I think we are galaxies away from a world where this issue should be a
priority for work on the compiler or other Elm language tools. :-)

2016-09-08 15:31 GMT+02:00 'Thomas Henley' via Elm Discuss <
elm-discuss@googlegroups.com>:

> Browsing the source of the Html.App module in order to see the signature
> of Html.App.map and how it works I read the documentation
> to get a good understanding of the function, which can be seen below
>
> https://github.com/elm-lang/html/blob/1.1.0/src/Html/App.elm#L52
>
>
>> {-| This function is useful when nesting components with [the Elm
>> Architecture](https://github.com/evancz/elm-architecture-tutorial/). It
>> lets
>> you transform the messages produced by a subtree.
>>
>>
>> Say you have a node named `button` that produces `()` values when it is
>> clicked. To get your model updating properly, you will probably want to
>> tag
>> this `()` value like this:
>>
>>type Msg = Click | ...
>>
>>update msg model =
>>  case msg of
>>Click ->
>>  ...
>> view model =
>>  map (\_ -> Click) button
>>
>> So now all the events produced by `button` will be transformed to be of
>> type
>> `Msg` so they can be handled by your update function!
>> -}
>> map : (a -> msg) -> Html a -> Html msg
>> map =
>>   VirtualDom.map
>
>
> I then went and checked out the implementation of VirtualDom.map and
> noticed the comment being identical
> https://github.com/elm-lang/virtual-dom/blob/master/src/VirtualDom.elm#L79
>
> I couldn't help but think, keeping comments between packages in sync has
> to be a pointless task and a waste
> of time, even worse if one updates without the other we have two identical
> functions with different sets of
> documentation.
>
> I'm proposing we have a way of inheriting comments from another function,
> two (maybe possible) ways I could
> think off were
>
> *Alternative version of special doc comment*
>
>> {-> VirtualDom.map -}
>
>
> Instead of a pipe character, using an arrow pointing to the function which
> is being documented
>
> *Version similar to @docs keyword*
>
>> {-| @inherit VirtualDom.node -}
>
>
>
> I'm galaxies away from being experienced in compiler/language design so
> forgive me if this is sounds like
> a ridiculous idea.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Elm Runtime Exceptions

[Janis Voigtländer]

If that is the case, http://elm-lang.org/try has not yet benefitted from
that fix (which is strange, after a couple of months).

2016-09-08 10:30 GMT+02:00 José Lorenzo Rodríguez :

> > String.indices "" "Goodbye, Cruel World!"
>
> Nathan, that's not a error anymore, I submitted a pull request to fix it
> and it was merged a couple months ago.
>
> On Thursday, September 8, 2016 at 10:27:04 AM UTC+2, Nathan Schultz wrote:
>>
>> A run-time error that stung me today is if you accidentally pass an empty
>> string to String.indices. i.e.:
>>
>>
>> String.indices "" "Goodbye, Cruel World!"
>>
>>
>> I would have expected it simply returned a [] rather than just crashing.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Elm Runtime Exceptions

[Janis Voigtländer]

https://github.com/elm-lang/core/issues/708

2016-09-08 10:27 GMT+02:00 Nathan Schultz :

> A run-time error that stung me today is if you accidentally pass an empty
> string to String.indices. i.e.:
>
>
> String.indices "" "Goodbye, Cruel World!"
>
>
> I would have expected it simply returned a [] rather than just crashing.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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] Confused type definition

[Janis Voigtländer]

Would you have been more comfortable if the definition would have been like
the following?

type Config data msg =
  ConfigConstructor
{ toId : data -> String
, toMsg : State -> msg
, columns : List (ColumnData data msg)
, customizations : Customizations data msg
}

If yes, then the only additional thing you need to know is that it is just
fine to use the name Config in both the places of Config and
ConfigConstructor here, because these two entities live in two different
name spaces, so the compiler can never be confused by them.

If not, if the above definition would not be clear to you either, then you
probably need to read (more) about union types. The guide is recommended,
specifically the above is like the example
http://guide.elm-lang.org/types/union_types.html#anonymous-users, where
Config is like User in that example and ConfigConstructor is like Named in
that example.
​

2016-09-05 12:22 GMT+02:00 Luis Fei :

> Hello, I just tried to look into elm-sortable-table's source code, and
> this `Config` type got me confused
>
> https://github.com/evancz/elm-sortable-table/blob/master/
> src/Table.elm#L96-L102
>
> I'll paste it here for convenience
>
> type Config data msg =
>   Config
> { toId : data -> String
> , toMsg : State -> msg
> , columns : List (ColumnData data msg)
> , customizations : Customizations data msg
> }
>
> How this type works? Is the inner Config called like a function? What's
> related between two Config? And so on...
>
> Hope someone can explain it a bit, thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Ahead-of-time generation of server-side JSON data to drive client app

[Janis Voigtländer]

For the Haskell option, you may want to take a look at
https://github.com/krisajenkins/elm-export and
https://github.com/agrafix/elm-bridge.

Am Montag, 5. September 2016 schrieb Matt McHenry :

> I've just started learning Elm, and am starting to think about how to
> structure my first application.
>
> The app in question is a photo album viewer (in the spirit of
> http://bins.sautret.org/).  The idea is to start with a directory tree of
> images (on a local FS, served by a plain HTTP server.)  Run a program over
> that FS tree to produce a JSON description of the album tree.  Then feed
> that JSON into an Elm program to browse through the albums.
>
> My question is: how best to implement the dir-tree -> JSON program?
> Ideally I'd like to declare the data types representing the album tree once
> and share them between the dir-tree -> JSON program and the Elm browsing
> app.  Options I've considered:
>
> a) Elm compiled to js, run in node, using ports to communicate with node's
> file API
> b) Haskell program, using a mechanically-transformed Elm types file to
> share the types (think: sed s/type alias Image/data Image = Image/)
>
> I don't have much Haskell or Elm experience, so there's a lot of
> hand-waving in both approaches for me at this point.  Any thoughts on the
> above options, or suggestions that I haven't considered, are appreciated!
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: When to use Dict vs. List?

[Janis Voigtländer]

Let me try to answer that, though I don’t have the compiler at hand right
now for checking this code works exactly:

update msg ({ entries } as model) =
let
updateEntry =
case msg of
ToggleDone id ->
Dict.update id (Maybe.map (\({ done } as t) -> { t
| done = not done }))

UpdateTaskName id newTaskName ->
Dict.update id (Maybe.map (\t -> { t | name =
newTaskName }))
in
{ model | entries = updateEntry entries }

​

2016-09-03 16:11 GMT+02:00 Brian John Farrar :

> Thanks all for the responses.
>
> For:
> "Maybe.map doesn't appear useful as record updates aren't compose-able?)"
>
> I'll reformulate the question: What is the most factored version of the
> following code?
>
> update msg model =
> case msg of
> ToggleDone id ->
> let
> updateEntry t =
> case t of
> Nothing ->
> Nothing
>
> Just t ->
> Just { t | done = not t.done }
> in
> { model | entries = Dict.update id updateEntry
> model.entries }
>
> UpdateTaskName id newTaskName ->
> let
> updateEntry t =
> case t of
> Nothing ->
> Nothing
>
> Just t ->
> Just { t | name = newTaskName }
> in
> { model | entries = Dict.update id updateEntry
> model.entries }
>
>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Missing deps trying to build elm-lang.org

[Janis Voigtländer]

Hmm, too bad. This has really turned into a “How to install a specific GHC
version on OS X”, which I am not qualified to answer *at all*.
​

2016-08-30 20:24 GMT+02:00 suttlecommakevin :

> That brew commit checkout doesn't work either. Runs into permissions and
> $PATH issues (at least on my machine).
>
> On Tuesday, August 30, 2016 at 2:07:32 PM UTC-4, Janis Voigtländer wrote:
>>
>> Depends on the operating system. And should be answered at
>> https://www.haskell.org/downloads.
>>
>> For what seems to be your specific situation (OS X with Homebrew), the
>> commit discussion you linked to contains a comment that appears to answer
>> the question: https://github.com/elm-lang/el
>> m-platform/commit/f46c95cf826651c56cf11388148df4406a834ee8#
>> commitcomment-18102434
>> ​
>>
>> 2016-08-30 19:57 GMT+02:00 suttlecommakevin :
>>
>>> Right, and how does one obtain GHC 7.10?
>>>
>>> On Tuesday, August 30, 2016 at 1:51:50 PM UTC-4, Janis Voigtländer wrote:
>>>>
>>>> GHC 7.10.x + whatever cabal comes with that + Elm 0.17.1
>>>>
>>>> 2016-08-30 19:44 GMT+02:00 suttlecommakevin :
>>>>
>>>>> Thanks. I still am not able to contribute to elm-lang.org without a
>>>>> proper set up.
>>>>> In order to develop, how *exactly *should and which versions of, elm,
>>>>> ghc, and cabal be installed most reliably?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, August 30, 2016 at 1:39:07 PM UTC-4, Janis Voigtländer
>>>>> wrote:
>>>>>>
>>>>>> I tried 0.16, because that’s what’s in the README*. Others have been
>>>>>> scolded for not reading the instructions closely.
>>>>>>
>>>>>> In all fairness, the README of https://github.com/elm-lang/el
>>>>>> m-lang.org says to use 0.17, not 0.16.
>>>>>> ​
>>>>>>
>>>>>> 2016-08-30 19:30 GMT+02:00 suttlecommakevin :
>>>>>>
>>>>>>>
>>>>>>>- Yes, 8.0.1 as Richard pointed out in that commit.
>>>>>>>- I tried 0.16, because that's what's in the README*. Others
>>>>>>>have been scolded for not reading the instructions closely.
>>>>>>>- Yes, I also tried 0.17.1, and that failed as well.
>>>>>>>
>>>>>>> For me, what is needed is a more explicit set of instructions than
>>>>>>> > Before getting Haskell Platform, make sure it is going to give
>>>>>>> you these things <https://www.haskell.org/platform/contents.html>.
>>>>>>>
>>>>>>> As someone who has never used Haskell, and is just getting going
>>>>>>> with Elm, I would rather see explicit, tested, instructions.
>>>>>>> *I tried to make a minor fix to these, but there are some odd errors
>>>>>>> in Travis. Maybe these will help shed some light.
>>>>>>>
>>>>>>> https://travis-ci.org/elm-lang/elm-platform/jobs/156272879#L754-L794
>>>>>>> https://travis-ci.org/elm-lang/elm-platform/jobs/156272879#L861
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, August 30, 2016 at 12:57:41 PM UTC-4, Janis Voigtländer
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>- That does not yet tell me which version of GHC you have. I
>>>>>>>>could guess that 8.0.1, but is that the case?
>>>>>>>>- Why is it that you try to install 0.16 of the platform in
>>>>>>>>your gist, rather than 0.17 or better yet 0.17.1?
>>>>>>>>- It is not clear that GHC 8.0.1 will fail you (with 0.17.1 of
>>>>>>>>elm-platform). Have you tried?
>>>>>>>>
>>>>>>>> ​
>>>>>>>>
>>>>>>>> 2016-08-30 18:53 GMT+02:00 suttlecommakevin 
>>>>>>>> :
>>>>>>>>
>>>>>>>>> I'm on Mac. I installed *ghc* via brew cask install
>>>>>>>>> haskell-platform.
>>>>>>>>>
>>>>>>>>> It's not clear where or how to obtain GHC < 8.0.1 reliably or
>>

Re: [elm-discuss] Re: Missing deps trying to build elm-lang.org

[Janis Voigtländer]

Depends on the operating system. And should be answered at
https://www.haskell.org/downloads.

For what seems to be your specific situation (OS X with Homebrew), the
commit discussion you linked to contains a comment that appears to answer
the question:
https://github.com/elm-lang/elm-platform/commit/f46c95cf826651c56cf11388148df4406a834ee8#commitcomment-18102434
​

2016-08-30 19:57 GMT+02:00 suttlecommakevin :

> Right, and how does one obtain GHC 7.10?
>
> On Tuesday, August 30, 2016 at 1:51:50 PM UTC-4, Janis Voigtländer wrote:
>>
>> GHC 7.10.x + whatever cabal comes with that + Elm 0.17.1
>>
>> 2016-08-30 19:44 GMT+02:00 suttlecommakevin :
>>
>>> Thanks. I still am not able to contribute to elm-lang.org without a
>>> proper set up.
>>> In order to develop, how *exactly *should and which versions of, elm,
>>> ghc, and cabal be installed most reliably?
>>>
>>>
>>>
>>>
>>> On Tuesday, August 30, 2016 at 1:39:07 PM UTC-4, Janis Voigtländer wrote:
>>>>
>>>> I tried 0.16, because that’s what’s in the README*. Others have been
>>>> scolded for not reading the instructions closely.
>>>>
>>>> In all fairness, the README of https://github.com/elm-lang/elm-lang.org
>>>> says to use 0.17, not 0.16.
>>>> ​
>>>>
>>>> 2016-08-30 19:30 GMT+02:00 suttlecommakevin :
>>>>
>>>>>
>>>>>- Yes, 8.0.1 as Richard pointed out in that commit.
>>>>>- I tried 0.16, because that's what's in the README*. Others have
>>>>>been scolded for not reading the instructions closely.
>>>>>- Yes, I also tried 0.17.1, and that failed as well.
>>>>>
>>>>> For me, what is needed is a more explicit set of instructions than
>>>>> > Before getting Haskell Platform, make sure it is going to give you
>>>>> these things <https://www.haskell.org/platform/contents.html>.
>>>>>
>>>>> As someone who has never used Haskell, and is just getting going with
>>>>> Elm, I would rather see explicit, tested, instructions.
>>>>> *I tried to make a minor fix to these, but there are some odd errors
>>>>> in Travis. Maybe these will help shed some light.
>>>>>
>>>>> https://travis-ci.org/elm-lang/elm-platform/jobs/156272879#L754-L794
>>>>> https://travis-ci.org/elm-lang/elm-platform/jobs/156272879#L861
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, August 30, 2016 at 12:57:41 PM UTC-4, Janis Voigtländer
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>- That does not yet tell me which version of GHC you have. I
>>>>>>could guess that 8.0.1, but is that the case?
>>>>>>- Why is it that you try to install 0.16 of the platform in your
>>>>>>gist, rather than 0.17 or better yet 0.17.1?
>>>>>>- It is not clear that GHC 8.0.1 will fail you (with 0.17.1 of
>>>>>>elm-platform). Have you tried?
>>>>>>
>>>>>> ​
>>>>>>
>>>>>> 2016-08-30 18:53 GMT+02:00 suttlecommakevin :
>>>>>>
>>>>>>> I'm on Mac. I installed *ghc* via brew cask install haskell-platform
>>>>>>> .
>>>>>>>
>>>>>>> It's not clear where or how to obtain GHC < 8.0.1 reliably or
>>>>>>> consistently.
>>>>>>> https://github.com/elm-lang/elm-platform/commit/f46c95cf8266
>>>>>>> 51c56cf11388148df4406a834ee8
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, August 30, 2016 at 12:49:38 PM UTC-4, Joey Eremondi
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> @suttlecommakevin Are you trying to use Elm from Hackage, or the
>>>>>>>> Elm platform? Hackage elm is woefully out of date.
>>>>>>>>
>>>>>>>> On Tue, Aug 30, 2016 at 9:38 AM, Janis Voigtländer <
>>>>>>>> janis.voi...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> You don't feel like telling us which GHC version you are trying to
>>>>>>>>> do this with?
>>>>>>>>>
>>>>>>>>> 2016-08-30 18:11 GMT+02:00 suttlecommakevin >>>&g

Re: [elm-discuss] Re: Missing deps trying to build elm-lang.org

[Janis Voigtländer]

GHC 7.10.x + whatever cabal comes with that + Elm 0.17.1

2016-08-30 19:44 GMT+02:00 suttlecommakevin :

> Thanks. I still am not able to contribute to elm-lang.org without a
> proper set up.
> In order to develop, how *exactly *should and which versions of, elm,
> ghc, and cabal be installed most reliably?
>
>
>
>
> On Tuesday, August 30, 2016 at 1:39:07 PM UTC-4, Janis Voigtländer wrote:
>>
>> I tried 0.16, because that’s what’s in the README*. Others have been
>> scolded for not reading the instructions closely.
>>
>> In all fairness, the README of https://github.com/elm-lang/elm-lang.org
>> says to use 0.17, not 0.16.
>> ​
>>
>> 2016-08-30 19:30 GMT+02:00 suttlecommakevin :
>>
>>>
>>>- Yes, 8.0.1 as Richard pointed out in that commit.
>>>- I tried 0.16, because that's what's in the README*. Others have
>>>been scolded for not reading the instructions closely.
>>>- Yes, I also tried 0.17.1, and that failed as well.
>>>
>>> For me, what is needed is a more explicit set of instructions than
>>> > Before getting Haskell Platform, make sure it is going to give you
>>> these things <https://www.haskell.org/platform/contents.html>.
>>>
>>> As someone who has never used Haskell, and is just getting going with
>>> Elm, I would rather see explicit, tested, instructions.
>>> *I tried to make a minor fix to these, but there are some odd errors in
>>> Travis. Maybe these will help shed some light.
>>>
>>> https://travis-ci.org/elm-lang/elm-platform/jobs/156272879#L754-L794
>>> https://travis-ci.org/elm-lang/elm-platform/jobs/156272879#L861
>>>
>>>
>>>
>>>
>>> On Tuesday, August 30, 2016 at 12:57:41 PM UTC-4, Janis Voigtländer
>>> wrote:
>>>>
>>>>
>>>>- That does not yet tell me which version of GHC you have. I could
>>>>guess that 8.0.1, but is that the case?
>>>>- Why is it that you try to install 0.16 of the platform in your
>>>>gist, rather than 0.17 or better yet 0.17.1?
>>>>- It is not clear that GHC 8.0.1 will fail you (with 0.17.1 of
>>>>elm-platform). Have you tried?
>>>>
>>>> ​
>>>>
>>>> 2016-08-30 18:53 GMT+02:00 suttlecommakevin :
>>>>
>>>>> I'm on Mac. I installed *ghc* via brew cask install haskell-platform.
>>>>>
>>>>> It's not clear where or how to obtain GHC < 8.0.1 reliably or
>>>>> consistently.
>>>>> https://github.com/elm-lang/elm-platform/commit/f46c95cf8266
>>>>> 51c56cf11388148df4406a834ee8
>>>>>
>>>>>
>>>>> On Tuesday, August 30, 2016 at 12:49:38 PM UTC-4, Joey Eremondi wrote:
>>>>>>
>>>>>> @suttlecommakevin Are you trying to use Elm from Hackage, or the Elm
>>>>>> platform? Hackage elm is woefully out of date.
>>>>>>
>>>>>> On Tue, Aug 30, 2016 at 9:38 AM, Janis Voigtländer <
>>>>>> janis.voi...@gmail.com> wrote:
>>>>>>
>>>>>>> You don't feel like telling us which GHC version you are trying to
>>>>>>> do this with?
>>>>>>>
>>>>>>> 2016-08-30 18:11 GMT+02:00 suttlecommakevin :
>>>>>>>
>>>>>>>> I get missing deps, but because of conflicts that were rejected.
>>>>>>>>
>>>>>>>> https://gist.github.com/kevinSuttle/a867b0d2048f6f6c6f646964
>>>>>>>> 061ec3c1
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thursday, August 14, 2014 at 11:19:13 PM UTC-4, Evan Cameron
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I've installed elm on arch using a cabal sandbox and the cabal
>>>>>>>>> install methods. I've added the /bin directory to my path so commands 
>>>>>>>>> like
>>>>>>>>> elm-get run from everywhere.
>>>>>>>>>
>>>>>>>>> I'm trying to build the elm-lang.org locally but cabal configure
>>>>>>>>> fails
>>>>>>>>>
>>>>>>>>> ➜  elm-lang.org git:(stable) elm-get install
>>>>>>>>> Installing all declared dependencies...
>>>>

Re: [elm-discuss] Re: Missing deps trying to build elm-lang.org

[Janis Voigtländer]

Yes, I also tried 0.17.1, and that failed as well.

Indeed, it turns out there are version constraints baked into 0.17.1 that
are incompatible with GHC 8.0.1.

FWIW, you would need to use the master branches of the elm-* repositories
and update, in the .cabal files of elm-make and elm-package, the upper
bounds for optparse-applicative and HTTP to <0.13 and <4000.4, respectively.

Otherwise, you will have to use a 7.10 variety of GHC, as the elm-platform
README says is typically used by developers, and then “explicit, tested,
instructions” amounts to exactly what is given in the README, namely
calling runhaskell BuildFromSource.hs with the version number.
​

2016-08-30 19:30 GMT+02:00 suttlecommakevin :

>
>- Yes, 8.0.1 as Richard pointed out in that commit.
>- I tried 0.16, because that's what's in the README*. Others have been
>scolded for not reading the instructions closely.
>- Yes, I also tried 0.17.1, and that failed as well.
>
> For me, what is needed is a more explicit set of instructions than
> > Before getting Haskell Platform, make sure it is going to give you
> these things <https://www.haskell.org/platform/contents.html>.
>
> As someone who has never used Haskell, and is just getting going with Elm,
> I would rather see explicit, tested, instructions.
> *I tried to make a minor fix to these, but there are some odd errors in
> Travis. Maybe these will help shed some light.
>
> https://travis-ci.org/elm-lang/elm-platform/jobs/156272879#L754-L794
> https://travis-ci.org/elm-lang/elm-platform/jobs/156272879#L861
>
>
>
>
> On Tuesday, August 30, 2016 at 12:57:41 PM UTC-4, Janis Voigtländer wrote:
>>
>>
>>- That does not yet tell me which version of GHC you have. I could
>>guess that 8.0.1, but is that the case?
>>- Why is it that you try to install 0.16 of the platform in your
>>gist, rather than 0.17 or better yet 0.17.1?
>>- It is not clear that GHC 8.0.1 will fail you (with 0.17.1 of
>>elm-platform). Have you tried?
>>
>> ​
>>
>> 2016-08-30 18:53 GMT+02:00 suttlecommakevin :
>>
>>> I'm on Mac. I installed *ghc* via brew cask install haskell-platform.
>>>
>>> It's not clear where or how to obtain GHC < 8.0.1 reliably or
>>> consistently.
>>> https://github.com/elm-lang/elm-platform/commit/f46c95cf8266
>>> 51c56cf11388148df4406a834ee8
>>>
>>>
>>> On Tuesday, August 30, 2016 at 12:49:38 PM UTC-4, Joey Eremondi wrote:
>>>>
>>>> @suttlecommakevin Are you trying to use Elm from Hackage, or the Elm
>>>> platform? Hackage elm is woefully out of date.
>>>>
>>>> On Tue, Aug 30, 2016 at 9:38 AM, Janis Voigtländer <
>>>> janis.voi...@gmail.com> wrote:
>>>>
>>>>> You don't feel like telling us which GHC version you are trying to do
>>>>> this with?
>>>>>
>>>>> 2016-08-30 18:11 GMT+02:00 suttlecommakevin :
>>>>>
>>>>>> I get missing deps, but because of conflicts that were rejected.
>>>>>>
>>>>>> https://gist.github.com/kevinSuttle/a867b0d2048f6f6c6f646964061ec3c1
>>>>>>
>>>>>>
>>>>>> On Thursday, August 14, 2014 at 11:19:13 PM UTC-4, Evan Cameron wrote:
>>>>>>>
>>>>>>> I've installed elm on arch using a cabal sandbox and the cabal
>>>>>>> install methods. I've added the /bin directory to my path so commands 
>>>>>>> like
>>>>>>> elm-get run from everywhere.
>>>>>>>
>>>>>>> I'm trying to build the elm-lang.org locally but cabal configure
>>>>>>> fails
>>>>>>>
>>>>>>> ➜  elm-lang.org git:(stable) elm-get install
>>>>>>> Installing all declared dependencies...
>>>>>>> Cloning repo johnpmayer/elm-webgl
>>>>>>> Checking out version 0.1
>>>>>>> Cloning repo johnpmayer/elm-linear-algebra
>>>>>>> Checking out version 1.0
>>>>>>> Success!
>>>>>>> ➜  elm-lang.org git:(stable) cabal configure
>>>>>>> Resolving dependencies...
>>>>>>> Configuring elm-website-0.1.0.2...
>>>>>>> cabal: At least the following dependencies are missing:
>>>>>>> Elm >=0.12,
>>>>>>> HTTP -any,
>>>>>>> aeson -any,
>>>>>>> blaze-html -any,
>>>>>&g

Re: [elm-discuss] Re: Missing deps trying to build elm-lang.org

[Janis Voigtländer]

I tried 0.16, because that’s what’s in the README*. Others have been
scolded for not reading the instructions closely.

In all fairness, the README of https://github.com/elm-lang/elm-lang.org
says to use 0.17, not 0.16.
​

2016-08-30 19:30 GMT+02:00 suttlecommakevin :

>
>- Yes, 8.0.1 as Richard pointed out in that commit.
>- I tried 0.16, because that's what's in the README*. Others have been
>scolded for not reading the instructions closely.
>- Yes, I also tried 0.17.1, and that failed as well.
>
> For me, what is needed is a more explicit set of instructions than
> > Before getting Haskell Platform, make sure it is going to give you
> these things <https://www.haskell.org/platform/contents.html>.
>
> As someone who has never used Haskell, and is just getting going with Elm,
> I would rather see explicit, tested, instructions.
> *I tried to make a minor fix to these, but there are some odd errors in
> Travis. Maybe these will help shed some light.
>
> https://travis-ci.org/elm-lang/elm-platform/jobs/156272879#L754-L794
> https://travis-ci.org/elm-lang/elm-platform/jobs/156272879#L861
>
>
>
>
> On Tuesday, August 30, 2016 at 12:57:41 PM UTC-4, Janis Voigtländer wrote:
>>
>>
>>- That does not yet tell me which version of GHC you have. I could
>>guess that 8.0.1, but is that the case?
>>- Why is it that you try to install 0.16 of the platform in your
>>gist, rather than 0.17 or better yet 0.17.1?
>>- It is not clear that GHC 8.0.1 will fail you (with 0.17.1 of
>>elm-platform). Have you tried?
>>
>> ​
>>
>> 2016-08-30 18:53 GMT+02:00 suttlecommakevin :
>>
>>> I'm on Mac. I installed *ghc* via brew cask install haskell-platform.
>>>
>>> It's not clear where or how to obtain GHC < 8.0.1 reliably or
>>> consistently.
>>> https://github.com/elm-lang/elm-platform/commit/f46c95cf8266
>>> 51c56cf11388148df4406a834ee8
>>>
>>>
>>> On Tuesday, August 30, 2016 at 12:49:38 PM UTC-4, Joey Eremondi wrote:
>>>>
>>>> @suttlecommakevin Are you trying to use Elm from Hackage, or the Elm
>>>> platform? Hackage elm is woefully out of date.
>>>>
>>>> On Tue, Aug 30, 2016 at 9:38 AM, Janis Voigtländer <
>>>> janis.voi...@gmail.com> wrote:
>>>>
>>>>> You don't feel like telling us which GHC version you are trying to do
>>>>> this with?
>>>>>
>>>>> 2016-08-30 18:11 GMT+02:00 suttlecommakevin :
>>>>>
>>>>>> I get missing deps, but because of conflicts that were rejected.
>>>>>>
>>>>>> https://gist.github.com/kevinSuttle/a867b0d2048f6f6c6f646964061ec3c1
>>>>>>
>>>>>>
>>>>>> On Thursday, August 14, 2014 at 11:19:13 PM UTC-4, Evan Cameron wrote:
>>>>>>>
>>>>>>> I've installed elm on arch using a cabal sandbox and the cabal
>>>>>>> install methods. I've added the /bin directory to my path so commands 
>>>>>>> like
>>>>>>> elm-get run from everywhere.
>>>>>>>
>>>>>>> I'm trying to build the elm-lang.org locally but cabal configure
>>>>>>> fails
>>>>>>>
>>>>>>> ➜  elm-lang.org git:(stable) elm-get install
>>>>>>> Installing all declared dependencies...
>>>>>>> Cloning repo johnpmayer/elm-webgl
>>>>>>> Checking out version 0.1
>>>>>>> Cloning repo johnpmayer/elm-linear-algebra
>>>>>>> Checking out version 1.0
>>>>>>> Success!
>>>>>>> ➜  elm-lang.org git:(stable) cabal configure
>>>>>>> Resolving dependencies...
>>>>>>> Configuring elm-website-0.1.0.2...
>>>>>>> cabal: At least the following dependencies are missing:
>>>>>>> Elm >=0.12,
>>>>>>> HTTP -any,
>>>>>>> aeson -any,
>>>>>>> blaze-html -any,
>>>>>>> blaze-markup -any,
>>>>>>> cmdargs -any,
>>>>>>> mtl -any,
>>>>>>> snap-core -any,
>>>>>>> snap-server -any,
>>>>>>> unordered-containers -any
>>>>>>>
>>>>>>>
>>>>>>> how is it even possible that elm-get ran if Elm is missing?
>>>>>>>
>>>>&

Re: [elm-discuss] Re: Missing deps trying to build elm-lang.org

[Janis Voigtländer]

   - That does not yet tell me which version of GHC you have. I could guess
   that 8.0.1, but is that the case?
   - Why is it that you try to install 0.16 of the platform in your gist,
   rather than 0.17 or better yet 0.17.1?
   - It is not clear that GHC 8.0.1 will fail you (with 0.17.1 of
   elm-platform). Have you tried?

​

2016-08-30 18:53 GMT+02:00 suttlecommakevin :

> I'm on Mac. I installed *ghc* via brew cask install haskell-platform.
>
> It's not clear where or how to obtain GHC < 8.0.1 reliably or
> consistently.
> https://github.com/elm-lang/elm-platform/commit/
> f46c95cf826651c56cf11388148df4406a834ee8
>
>
> On Tuesday, August 30, 2016 at 12:49:38 PM UTC-4, Joey Eremondi wrote:
>>
>> @suttlecommakevin Are you trying to use Elm from Hackage, or the Elm
>> platform? Hackage elm is woefully out of date.
>>
>> On Tue, Aug 30, 2016 at 9:38 AM, Janis Voigtländer <
>> janis.voi...@gmail.com> wrote:
>>
>>> You don't feel like telling us which GHC version you are trying to do
>>> this with?
>>>
>>> 2016-08-30 18:11 GMT+02:00 suttlecommakevin :
>>>
>>>> I get missing deps, but because of conflicts that were rejected.
>>>>
>>>> https://gist.github.com/kevinSuttle/a867b0d2048f6f6c6f646964061ec3c1
>>>>
>>>>
>>>> On Thursday, August 14, 2014 at 11:19:13 PM UTC-4, Evan Cameron wrote:
>>>>>
>>>>> I've installed elm on arch using a cabal sandbox and the cabal install
>>>>> methods. I've added the /bin directory to my path so commands like elm-get
>>>>> run from everywhere.
>>>>>
>>>>> I'm trying to build the elm-lang.org locally but cabal configure fails
>>>>>
>>>>> ➜  elm-lang.org git:(stable) elm-get install
>>>>> Installing all declared dependencies...
>>>>> Cloning repo johnpmayer/elm-webgl
>>>>> Checking out version 0.1
>>>>> Cloning repo johnpmayer/elm-linear-algebra
>>>>> Checking out version 1.0
>>>>> Success!
>>>>> ➜  elm-lang.org git:(stable) cabal configure
>>>>> Resolving dependencies...
>>>>> Configuring elm-website-0.1.0.2...
>>>>> cabal: At least the following dependencies are missing:
>>>>> Elm >=0.12,
>>>>> HTTP -any,
>>>>> aeson -any,
>>>>> blaze-html -any,
>>>>> blaze-markup -any,
>>>>> cmdargs -any,
>>>>> mtl -any,
>>>>> snap-core -any,
>>>>> snap-server -any,
>>>>> unordered-containers -any
>>>>>
>>>>>
>>>>> how is it even possible that elm-get ran if Elm is missing?
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Elm Discuss" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to elm-discuss...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Missing deps trying to build elm-lang.org

[Janis Voigtländer]

The log provided in his gist answers that question, Joey.

2016-08-30 18:49 GMT+02:00 Joey Eremondi :

> @suttlecommakevin Are you trying to use Elm from Hackage, or the Elm
> platform? Hackage elm is woefully out of date.
>
> On Tue, Aug 30, 2016 at 9:38 AM, Janis Voigtländer <
> janis.voigtlaen...@gmail.com> wrote:
>
>> You don't feel like telling us which GHC version you are trying to do
>> this with?
>>
>> 2016-08-30 18:11 GMT+02:00 suttlecommakevin :
>>
>>> I get missing deps, but because of conflicts that were rejected.
>>>
>>> https://gist.github.com/kevinSuttle/a867b0d2048f6f6c6f646964061ec3c1
>>>
>>>
>>> On Thursday, August 14, 2014 at 11:19:13 PM UTC-4, Evan Cameron wrote:
>>>>
>>>> I've installed elm on arch using a cabal sandbox and the cabal install
>>>> methods. I've added the /bin directory to my path so commands like elm-get
>>>> run from everywhere.
>>>>
>>>> I'm trying to build the elm-lang.org locally but cabal configure fails
>>>>
>>>> ➜  elm-lang.org git:(stable) elm-get install
>>>> Installing all declared dependencies...
>>>> Cloning repo johnpmayer/elm-webgl
>>>> Checking out version 0.1
>>>> Cloning repo johnpmayer/elm-linear-algebra
>>>> Checking out version 1.0
>>>> Success!
>>>> ➜  elm-lang.org git:(stable) cabal configure
>>>> Resolving dependencies...
>>>> Configuring elm-website-0.1.0.2...
>>>> cabal: At least the following dependencies are missing:
>>>> Elm >=0.12,
>>>> HTTP -any,
>>>> aeson -any,
>>>> blaze-html -any,
>>>> blaze-markup -any,
>>>> cmdargs -any,
>>>> mtl -any,
>>>> snap-core -any,
>>>> snap-server -any,
>>>> unordered-containers -any
>>>>
>>>>
>>>> how is it even possible that elm-get ran if Elm is missing?
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and 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] Re: Missing deps trying to build elm-lang.org

[Janis Voigtländer]

You don't feel like telling us which GHC version you are trying to do this
with?

2016-08-30 18:11 GMT+02:00 suttlecommakevin :

> I get missing deps, but because of conflicts that were rejected.
>
> https://gist.github.com/kevinSuttle/a867b0d2048f6f6c6f646964061ec3c1
>
>
> On Thursday, August 14, 2014 at 11:19:13 PM UTC-4, Evan Cameron wrote:
>>
>> I've installed elm on arch using a cabal sandbox and the cabal install
>> methods. I've added the /bin directory to my path so commands like elm-get
>> run from everywhere.
>>
>> I'm trying to build the elm-lang.org locally but cabal configure fails
>>
>> ➜  elm-lang.org git:(stable) elm-get install
>> Installing all declared dependencies...
>> Cloning repo johnpmayer/elm-webgl
>> Checking out version 0.1
>> Cloning repo johnpmayer/elm-linear-algebra
>> Checking out version 1.0
>> Success!
>> ➜  elm-lang.org git:(stable) cabal configure
>> Resolving dependencies...
>> Configuring elm-website-0.1.0.2...
>> cabal: At least the following dependencies are missing:
>> Elm >=0.12,
>> HTTP -any,
>> aeson -any,
>> blaze-html -any,
>> blaze-markup -any,
>> cmdargs -any,
>> mtl -any,
>> snap-core -any,
>> snap-server -any,
>> unordered-containers -any
>>
>>
>> how is it even possible that elm-get ran if Elm is missing?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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.