Re: [elm-discuss] Listening to messages from different modules on an update

[Tim Bezhashvyly]

Sure I'm using something different. :-)

On Wednesday, November 16, 2016 at 12:07:25 AM UTC+1, OvermindDL1 wrote:
>
> aMSG is not a valid constructor name, perhaps instead AMSG or A_Msg or 
> MsgA or so, as long as it starts with an uppercase.  :-)
>
>
> On Tuesday, November 15, 2016 at 3:50:36 PM UTC-7, Tim Bezhashvyly wrote:
>>
>> Thank you. Tried to apply it but my problem is that I'm trying to send 
>> initialize a request on init:
>>
>> init : ( Model, Cmd Msg )
>> init =
>>  ( { 
>>  -- my model here
>>  }
>>  , getJson
>>  )
>>
>> And of course `getJson` is returning `A.Msg`, so even if in B I declare:
>>
>> type Msg
>>  = aMSG A.Msg
>>  | SomeLocalMessage
>>
>>
>> I'm still getting an error that init was expecting `Main.Msg` but got 
>> `A.Msg`.
>>
>> Hope I make sense.
>>
>>
>> On Tuesday, November 15, 2016 at 7:40:50 AM UTC+1, Peter Damoc wrote:
>>>
>>> There used to be a "nesting" set of examples in The Elm Architecture but 
>>> lately this approach has been discouraged. 
>>>
>>> What you describe here is a kind of decomposition into components. 
>>>
>>> It is recommended that you have one model and you decompose the 
>>> functionality of update & view using regular functions. 
>>>
>>> If you want to see how this used to be done, take a look at the old 
>>> CounterPair example:
>>>
>>> https://github.com/pdamoc/elm-architecture-tutorial/blob/master/examples/2/CounterPair.elm
>>>
>>> Please note that this code is obsolete. 
>>>
>>>
>>>  
>>>
>>> On Mon, Nov 14, 2016 at 4:43 PM, Tim Bezhashvyly  
>>> wrote:
>>>
 I just started digging into Elm so quite possible that my question has 
 a conceptual problem. Please let me know if so.

 I have a module A which is asynchronously reading data from JSON. 
 Module A among other things exposes `getJson` function. As the read is 
 processing data asynchronously it can not just return data structure but 
 returning it's Msg type instead which is:

 type Msg
   = FetchSucceed (Maybe Jobs)
   | FetchFail Http.Error

 Now if module B imports module A it can call `getJson` method but it 
 will only trigger  initial call and then has to listen to `FetchSucceed
 `:

 update : A.Msg -> A -> (A, Cmd A.Msg)
 update msg model =
   case msg of
   FetchSucceed a ->
   (A a, Cmd.none)

   FetchFail _ ->
   (model, Cmd.none)

 My question is if module B has it's own command how does `update` 
 function combines listening to commands from both modules?

 Thanks.

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

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

[elm-discuss] Converting a UTC date to a local one?

[Liam Curry]

I have some UTC dates that I need to show in the users local time. All I 
really need is the users local timezone offset, which I can then use to 
calculate the date in their local timezone.

I've looked over several Date/Time packages and none of them seem to do 
this. Am I missing something, or is there no easy way to do this in Elm 
without using Native 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.

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

[Duane Johnson]

On Tue, Nov 15, 2016 at 2:38 PM, 'Andrew Radford' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> I agree with you there. I'm just pointing out that calling this a
> community decision is misrepresenting things.
>

What would a community decision look like to you (procedurally)?

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

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

[Nick H]

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

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

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

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

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

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

~Nick

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

Re: [elm-discuss] How are you handling images references in Elm with Webpack?

[Birowsky]

So you just gonna leave me here.. hanging..

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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] Listening to messages from different modules on an update

[OvermindDL1]

aMSG is not a valid constructor name, perhaps instead AMSG or A_Msg or MsgA 
or so, as long as it starts with an uppercase.  :-)


On Tuesday, November 15, 2016 at 3:50:36 PM UTC-7, Tim Bezhashvyly wrote:
>
> Thank you. Tried to apply it but my problem is that I'm trying to send 
> initialize a request on init:
>
> init : ( Model, Cmd Msg )
> init =
>  ( { 
>  -- my model here
>  }
>  , getJson
>  )
>
> And of course `getJson` is returning `A.Msg`, so even if in B I declare:
>
> type Msg
>  = aMSG A.Msg
>  | SomeLocalMessage
>
>
> I'm still getting an error that init was expecting `Main.Msg` but got 
> `A.Msg`.
>
> Hope I make sense.
>
>
> On Tuesday, November 15, 2016 at 7:40:50 AM UTC+1, Peter Damoc wrote:
>>
>> There used to be a "nesting" set of examples in The Elm Architecture but 
>> lately this approach has been discouraged. 
>>
>> What you describe here is a kind of decomposition into components. 
>>
>> It is recommended that you have one model and you decompose the 
>> functionality of update & view using regular functions. 
>>
>> If you want to see how this used to be done, take a look at the old 
>> CounterPair example:
>>
>> https://github.com/pdamoc/elm-architecture-tutorial/blob/master/examples/2/CounterPair.elm
>>
>> Please note that this code is obsolete. 
>>
>>
>>  
>>
>> On Mon, Nov 14, 2016 at 4:43 PM, Tim Bezhashvyly  
>> wrote:
>>
>>> I just started digging into Elm so quite possible that my question has a 
>>> conceptual problem. Please let me know if so.
>>>
>>> I have a module A which is asynchronously reading data from JSON. Module 
>>> A among other things exposes `getJson` function. As the read is processing 
>>> data asynchronously it can not just return data structure but returning 
>>> it's Msg type instead which is:
>>>
>>> type Msg
>>>   = FetchSucceed (Maybe Jobs)
>>>   | FetchFail Http.Error
>>>
>>> Now if module B imports module A it can call `getJson` method but it 
>>> will only trigger  initial call and then has to listen to `FetchSucceed
>>> `:
>>>
>>> update : A.Msg -> A -> (A, Cmd A.Msg)
>>> update msg model =
>>>   case msg of
>>>   FetchSucceed a ->
>>>   (A a, Cmd.none)
>>>
>>>   FetchFail _ ->
>>>   (model, Cmd.none)
>>>
>>> My question is if module B has it's own command how does `update` 
>>> function combines listening to commands from both modules?
>>>
>>> Thanks.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>

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

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

[OvermindDL1]

Heh, good looking library, but you should definitely make it in a new 
thread titled as your library.  :-)


On Tuesday, November 15, 2016 at 3:13:34 PM UTC-7, Nick H wrote:
>
> On second thought, maybe it was not the best idea to resurrect a thread 
> whose title refers to two functions that no longer exist...
>
> On Tue, Nov 15, 2016 at 1:09 PM, Nick H  > wrote:
>
>> Thread... resurrected!
>>
>> Just wanted to mention that I took the game loop pattern and wrapped it 
>> up in a library 
>> . If 
>> anyone has feedback on the API, I would love to hear it. I went with 
>> something that made sense to me, but... well, you can draw any line you 
>> want through just one data point :-)
>>
>>
>> On Thu, Feb 25, 2016 at 4:38 PM, d13 > 
>> wrote:
>>
>>> That's brilliant, thanks so much for sharing your code!!
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to elm-discuss...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

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

[elm-discuss] Re: How to manage subscriptions that require side effects?

[OvermindDL1]

There is not much documentation on it on purpose.  ^.^
Best way to learn it is to read how it is implemented in the core 
libraries.  :-)

As a comparison, if you are try to implement TEA in Swift, I managed to 
make subscriptions in mine via startup/shutdown callbacks and a back-end 
differ, quite easy to make then.  :-)


On Tuesday, November 15, 2016 at 2:35:20 PM UTC-7, Guido Marucci Blas wrote:
>
> Thanks a lot for the detailed answer!!! I clearly wasn't aware of the 
> effect manager. I would read more about it.
>
> Thanks!
>
> On Tuesday, November 15, 2016 at 6:20:27 PM UTC-3, OvermindDL1 wrote:
>>
>> Comments i
>>
>> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
>> wrote:
>>>
>>> Hi everybody! I've been reading the docs and following Elm every now and 
>>> then.  I did some toy application to learn the language and the 
>>> architecture. I am working on a native iOS application so using Elm in my 
>>> day job won't happen (for now). The main reason I want to learn Elm (apart 
>>> from it being awesome!) is that I want to apply Elm's architecture to iOS 
>>> with Swift (yeah a lot of people is doing the same thing). There are quite 
>>> a few libraries that try to bring Elm's architecture to Swift but I don't 
>>> want to use them. I want to implement something myself because that way I 
>>> will be able to understand it better. 
>>>
>>> The reason I am writing is that I want to better understand how 
>>> subscriptions work internally. Please correct me if I am wrong. My 
>>> understanding of how subscription works is that they provide a mechanism to 
>>> "hook" to a stream of infinite events. Those events get mapped to your own 
>>> application message by virtue of the message constructor function that is 
>>> passed when creating a new subscription. As far as I can tell the only way 
>>> of creating subscription is by a model update. Every time the model gets 
>>> updated, Elm's runtime calls the subscription function (passed to the init 
>>> function when you bootstrap your app). This gives us the change to create a 
>>> new subscription based of the current state. Am I correct? 
>>>
>>>- Is there any other way of creating subscriptions? 
>>>- What happens when the process of starting a subscription needs to 
>>>perform a expensive side-effect? 
>>>- What is the Elm way of doing this?
>>>
>>> No other way of creating subscriptions.
>> The subscription itself should be fairly minimal, the effect manager 
>> handling the subscription setup and teradown should be doing all the costly 
>> stuff 'out-of-band' of your main app.
>>
>> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
>> wrote: 
>>
>>> Lets say that I have an application that connects to an external device 
>>> and after connecting with this device it wants to start listening to a 
>>> stream of data that this device reports every one second. Lets imagine this 
>>> device is thermometer that advertises the room's temperature. I want to 
>>> have an app that prints the average temperature since a connection with 
>>> thermometer was established. We can omit how we connect with thermometer 
>>> for now
>>>
>>
>>> type alias Model = 
>>> { thermometer: Maybe Thermometer
>>> , temperatureSamples: List Float
>>> }
>>>
>>>
>>> type Msg 
>>>   = ConnectedThermometer Thermometer
>>>   | TemperatureSample Float
>>>
>>>
>>> update : Msg -> Model -> (Model, Cmd Msg) 
>>> update msg model =
>>>   case msg of
>>> ConnectedThermometer thermometer ->
>>>   ({ model | thermometer = thermometer }, Cmd.none)
>>>
>>>
>>> TemperatureSample temperature ->
>>>   ({ model | temperatureSamples = temperature :: model.
>>> temperatureSamples}, Cmd.none)
>>>
>>> view : Model -> Html Msg
>>> view model = 
>>>   let
>>> averageTemperature = (List.sum model.temperatureSamples) / List.length 
>>> model.temperatureSamples
>>>   in
>>> Html.text (toString averageTemperature)
>>>
>>>
>>> subscriptions : Model -> Sub Msg
>>> subscriptions model =
>>>   model.thermometer
>>> |> map Thermometer.temperature TemperatureSample
>>> |> withDefault Sub.none
>>>
>>>
>>> -- Inside the Thermometer module
>>> temperature : (Float -> Msg) -> Thermometer -> Sub Msg
>>> temperature msgConstructor thermometer = ...
>>>
>>>
>>> *I am assuming there is a function in the Thermometer that knows how to 
>>> create subscription for a given connected thermometer. I am also assuming 
>>> that this MUST be implemented in Javascript and that all needed 
>>> side-effects in order to create the subscription are performed on the JS 
>>> side.*
>>>
>>
>> Nah, subscription can be managed within Elm by an effect manager (though 
>> it tends to eventually go out to a javascript effect manager, like via HTTP 
>> requests or whatever).
>>
>>
>> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
>> wrote: 
>>
>>> If my assumptions are correct then my main concern is that for every 
>>> state upd

Re: [elm-discuss] Listening to messages from different modules on an update

[Tim Bezhashvyly]

Thank you. Tried to apply it but my problem is that I'm trying to send 
initialize a request on init:

init : ( Model, Cmd Msg )
init =
 ( { 
 -- my model here
 }
 , getJson
 )

And of course `getJson` is returning `A.Msg`, so even if in B I declare:

type Msg
 = aMSG A.Msg
 | SomeLocalMessage


I'm still getting an error that init was expecting `Main.Msg` but got 
`A.Msg`.

Hope I make sense.


On Tuesday, November 15, 2016 at 7:40:50 AM UTC+1, Peter Damoc wrote:
>
> There used to be a "nesting" set of examples in The Elm Architecture but 
> lately this approach has been discouraged. 
>
> What you describe here is a kind of decomposition into components. 
>
> It is recommended that you have one model and you decompose the 
> functionality of update & view using regular functions. 
>
> If you want to see how this used to be done, take a look at the old 
> CounterPair example:
>
> https://github.com/pdamoc/elm-architecture-tutorial/blob/master/examples/2/CounterPair.elm
>
> Please note that this code is obsolete. 
>
>
>  
>
> On Mon, Nov 14, 2016 at 4:43 PM, Tim Bezhashvyly  > wrote:
>
>> I just started digging into Elm so quite possible that my question has a 
>> conceptual problem. Please let me know if so.
>>
>> I have a module A which is asynchronously reading data from JSON. Module 
>> A among other things exposes `getJson` function. As the read is processing 
>> data asynchronously it can not just return data structure but returning 
>> it's Msg type instead which is:
>>
>> type Msg
>>   = FetchSucceed (Maybe Jobs)
>>   | FetchFail Http.Error
>>
>> Now if module B imports module A it can call `getJson` method but it will 
>> only trigger  initial call and then has to listen to `FetchSucceed`:
>>
>> update : A.Msg -> A -> (A, Cmd A.Msg)
>> update msg model =
>>   case msg of
>>   FetchSucceed a ->
>>   (A a, Cmd.none)
>>
>>   FetchFail _ ->
>>   (model, Cmd.none)
>>
>> My question is if module B has it's own command how does `update` 
>> function combines listening to commands from both modules?
>>
>> Thanks.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>

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

Re: [elm-discuss] Help for article review for SPA applications in Elm 0.18

[Wouter In t Velt]

Great article!
I really like the way that you take the reader step by step through 
building a basic SPA, which even includes navigation and url parsing.

Personally, I think it is fine to let the reader "play along" by making a 
local copy and work on that. It would be useful if you point out that the 
"localhost" links only work if reader already has elm-reactor running. But 
I guess the point you are trying to make is that your app allows user to 
type these urls in the browser.
Maybe keep the urls, but remove the links?
In general, it would be nice to have links to a working example, possibly 
on gh-pages.

As general feedback: Because it is quite a long read,  adding an explicit 
comment in the beginning of what you hope the reader will learn from your 
post would be useful. E.g. "demonstrate that it is easy and fun to scale 
Elm, that your code remains readable", or "if you are learning Elm, or want 
to build a SPA for yourself, here is an example to get you started".

I've added some minor comments on typo's and readibility in the article too.
Suggest that you make function calls to imported functions explicit, e.g. 
Navigation.newUrl instead of newUrl.
Make it clear to readers whether a function is defined by you or imported 
(and from where).

Thanks for sharing this! 
Really useful, I have just begun to refactor a SPA to 0.18, and your 
explanation of the new navigation module was really helpful.

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

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

[Nick H]

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

On Tue, Nov 15, 2016 at 1:09 PM, Nick H  wrote:

> Thread... resurrected!
>
> Just wanted to mention that I took the game loop pattern and wrapped it
> up in a library
> . If
> anyone has feedback on the API, I would love to hear it. I went with
> something that made sense to me, but... well, you can draw any line you
> want through just one data point :-)
>
>
> On Thu, Feb 25, 2016 at 4:38 PM, d13  wrote:
>
>> That's brilliant, thanks so much for sharing your code!!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [elm-discuss] Re: Correct use of port subscriptions in a submodule reused multiple times?

[Witold Szczerba]

Thank you, Wouter for explanation. I was reading the documentation, but the
chapter covers just the reusable views. View functions seems fine, using
modules one can create, group, nest, etc.

I am wondering how making everything "flat" scales in a long term. Having
everything in just 4 files (Model/Mgs/Update/View) would eventually lead to
huge, separated silos with all the "business domains" mixed, wouldn't it?

What wrong happens when the application gets divided by features (in
opposite to features being divided by those 4 files)?

Maybe when app gets bigger, some kind of hybrid approach would emerge?

Thanks,
Witold Szczerba


On Mon, Nov 14, 2016 at 10:58 AM, Wouter In t Velt  wrote:

> Op maandag 14 november 2016 02:24:16 UTC+1 schreef Witold Szczerba:
>>
>> Can you provide some real-life example of "moving away from components"?
>> That could be helpful…
>>
>
> Sure. My background is in React, where everything there is components too.
> No examples of my own to share just yet. My app is very much "work in
> progress", and not yet clean enough to share I am afraid.
>
> In the first version of my app (to plan homework), I would have e.g. an
> EditExam.elm file that contained its own Model, init, update, Msg and view.
> And in my main.elm, I would import this module and integrate each of these
> into the main Model, init etc.
> So basically, EditExam.elm was a "component". With the purpose of
> displaying an Exam, and allowing user to edit details.
>
> When moving away from components, I created top-level files in my root
> directory:
>
>- Model.elm
>- Msg.elm
>- Update.elm
>- View.elm
>- Main.elm (which imports all of the above).
>
> I copied the code bits from the component into each of these files. So for
> example:
> type alias Model =
>   { ...
>   , exams : List Exam
>   , currentExam : Exam
>   }
>
> type alias Exam =
>   { subject : String
>   , ...
>   }
>
> So the Exam type is the Model from the old EditExam.elm file.
> Did the same for init, Msg, update, and view.
>
> A (larger) real-life example that I use as a reference is the time-tracker
> SPA (here on github ). Which is
> a project as part of a DailyDrip  series.
>
> A very good explanation (with simple examples) of non-component scaling in
> Elm is in the Official Guide here .
> That explanation helped me a lot, along with the video's on sortable table
> linked there.
>
> Hope this helps!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

['Andrew Radford' via Elm Discuss]

I agree with you there. I'm just pointing out that calling this a community 
decision is misrepresenting things. 

On Tuesday, 15 November 2016 21:04:27 UTC, Duane Johnson wrote:
>
>
> On Tue, Nov 15, 2016 at 1:23 PM, 'Andrew Radford' via Elm Discuss <
> elm-d...@googlegroups.com > wrote:
>
>> No, it wasn't.  Some parts of the community were aware of it, but calling 
>> it a community decision is overstating it.
>
>
> While I wish it were otherwise, my experience from other communities is 
> that consensus (if that's what you're looking for), or even an attempt at 
> complete inclusion, in community decision-making is both procedurally 
> costly and an impediment to progress.
>

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

[elm-discuss] Re: How to manage subscriptions that require side effects?

[Guido Marucci Blas]

Thanks a lot for the detailed answer!!! I clearly wasn't aware of the 
effect manager. I would read more about it.

Thanks!

On Tuesday, November 15, 2016 at 6:20:27 PM UTC-3, OvermindDL1 wrote:
>
> Comments i
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
> wrote:
>>
>> Hi everybody! I've been reading the docs and following Elm every now and 
>> then.  I did some toy application to learn the language and the 
>> architecture. I am working on a native iOS application so using Elm in my 
>> day job won't happen (for now). The main reason I want to learn Elm (apart 
>> from it being awesome!) is that I want to apply Elm's architecture to iOS 
>> with Swift (yeah a lot of people is doing the same thing). There are quite 
>> a few libraries that try to bring Elm's architecture to Swift but I don't 
>> want to use them. I want to implement something myself because that way I 
>> will be able to understand it better. 
>>
>> The reason I am writing is that I want to better understand how 
>> subscriptions work internally. Please correct me if I am wrong. My 
>> understanding of how subscription works is that they provide a mechanism to 
>> "hook" to a stream of infinite events. Those events get mapped to your own 
>> application message by virtue of the message constructor function that is 
>> passed when creating a new subscription. As far as I can tell the only way 
>> of creating subscription is by a model update. Every time the model gets 
>> updated, Elm's runtime calls the subscription function (passed to the init 
>> function when you bootstrap your app). This gives us the change to create a 
>> new subscription based of the current state. Am I correct? 
>>
>>- Is there any other way of creating subscriptions? 
>>- What happens when the process of starting a subscription needs to 
>>perform a expensive side-effect? 
>>- What is the Elm way of doing this?
>>
>> No other way of creating subscriptions.
> The subscription itself should be fairly minimal, the effect manager 
> handling the subscription setup and teradown should be doing all the costly 
> stuff 'out-of-band' of your main app.
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
> wrote: 
>
>> Lets say that I have an application that connects to an external device 
>> and after connecting with this device it wants to start listening to a 
>> stream of data that this device reports every one second. Lets imagine this 
>> device is thermometer that advertises the room's temperature. I want to 
>> have an app that prints the average temperature since a connection with 
>> thermometer was established. We can omit how we connect with thermometer 
>> for now
>>
>
>> type alias Model = 
>> { thermometer: Maybe Thermometer
>> , temperatureSamples: List Float
>> }
>>
>>
>> type Msg 
>>   = ConnectedThermometer Thermometer
>>   | TemperatureSample Float
>>
>>
>> update : Msg -> Model -> (Model, Cmd Msg) 
>> update msg model =
>>   case msg of
>> ConnectedThermometer thermometer ->
>>   ({ model | thermometer = thermometer }, Cmd.none)
>>
>>
>> TemperatureSample temperature ->
>>   ({ model | temperatureSamples = temperature :: model.
>> temperatureSamples}, Cmd.none)
>>
>> view : Model -> Html Msg
>> view model = 
>>   let
>> averageTemperature = (List.sum model.temperatureSamples) / List.length 
>> model.temperatureSamples
>>   in
>> Html.text (toString averageTemperature)
>>
>>
>> subscriptions : Model -> Sub Msg
>> subscriptions model =
>>   model.thermometer
>> |> map Thermometer.temperature TemperatureSample
>> |> withDefault Sub.none
>>
>>
>> -- Inside the Thermometer module
>> temperature : (Float -> Msg) -> Thermometer -> Sub Msg
>> temperature msgConstructor thermometer = ...
>>
>>
>> *I am assuming there is a function in the Thermometer that knows how to 
>> create subscription for a given connected thermometer. I am also assuming 
>> that this MUST be implemented in Javascript and that all needed 
>> side-effects in order to create the subscription are performed on the JS 
>> side.*
>>
>
> Nah, subscription can be managed within Elm by an effect manager (though 
> it tends to eventually go out to a javascript effect manager, like via HTTP 
> requests or whatever).
>
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
> wrote: 
>
>> If my assumptions are correct then my main concern is that for every 
>> state update this "expensive" side effects that could be performed on the 
>> JS side by creating a new subscription are executed for every model update. 
>> If that is the case then I have the following questions
>>
>
> A subscription is just that, a subscription, saying that you 'want to 
> listen to messages from a given effect manager'.  The remote effect manager 
> could even be doing stuff even when nothing is subscribed, a subscription 
> is just that the main app wants to listen to messages from that effect 
> manager. 

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

[Nick H]

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


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

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

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


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

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

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

[elm-discuss] Re: How to manage subscriptions that require side effects?

[OvermindDL1]

Comments i

On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas wrote:
>
> Hi everybody! I've been reading the docs and following Elm every now and 
> then.  I did some toy application to learn the language and the 
> architecture. I am working on a native iOS application so using Elm in my 
> day job won't happen (for now). The main reason I want to learn Elm (apart 
> from it being awesome!) is that I want to apply Elm's architecture to iOS 
> with Swift (yeah a lot of people is doing the same thing). There are quite 
> a few libraries that try to bring Elm's architecture to Swift but I don't 
> want to use them. I want to implement something myself because that way I 
> will be able to understand it better. 
>
> The reason I am writing is that I want to better understand how 
> subscriptions work internally. Please correct me if I am wrong. My 
> understanding of how subscription works is that they provide a mechanism to 
> "hook" to a stream of infinite events. Those events get mapped to your own 
> application message by virtue of the message constructor function that is 
> passed when creating a new subscription. As far as I can tell the only way 
> of creating subscription is by a model update. Every time the model gets 
> updated, Elm's runtime calls the subscription function (passed to the init 
> function when you bootstrap your app). This gives us the change to create a 
> new subscription based of the current state. Am I correct? 
>
>- Is there any other way of creating subscriptions? 
>- What happens when the process of starting a subscription needs to 
>perform a expensive side-effect? 
>- What is the Elm way of doing this?
>
> No other way of creating subscriptions.
The subscription itself should be fairly minimal, the effect manager 
handling the subscription setup and teradown should be doing all the costly 
stuff 'out-of-band' of your main app.

On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
wrote: 

> Lets say that I have an application that connects to an external device 
> and after connecting with this device it wants to start listening to a 
> stream of data that this device reports every one second. Lets imagine this 
> device is thermometer that advertises the room's temperature. I want to 
> have an app that prints the average temperature since a connection with 
> thermometer was established. We can omit how we connect with thermometer 
> for now
>

> type alias Model = 
> { thermometer: Maybe Thermometer
> , temperatureSamples: List Float
> }
>
>
> type Msg 
>   = ConnectedThermometer Thermometer
>   | TemperatureSample Float
>
>
> update : Msg -> Model -> (Model, Cmd Msg) 
> update msg model =
>   case msg of
> ConnectedThermometer thermometer ->
>   ({ model | thermometer = thermometer }, Cmd.none)
>
>
> TemperatureSample temperature ->
>   ({ model | temperatureSamples = temperature :: model.
> temperatureSamples}, Cmd.none)
>
> view : Model -> Html Msg
> view model = 
>   let
> averageTemperature = (List.sum model.temperatureSamples) / List.length 
> model.temperatureSamples
>   in
> Html.text (toString averageTemperature)
>
>
> subscriptions : Model -> Sub Msg
> subscriptions model =
>   model.thermometer
> |> map Thermometer.temperature TemperatureSample
> |> withDefault Sub.none
>
>
> -- Inside the Thermometer module
> temperature : (Float -> Msg) -> Thermometer -> Sub Msg
> temperature msgConstructor thermometer = ...
>
>
> *I am assuming there is a function in the Thermometer that knows how to 
> create subscription for a given connected thermometer. I am also assuming 
> that this MUST be implemented in Javascript and that all needed 
> side-effects in order to create the subscription are performed on the JS 
> side.*
>

Nah, subscription can be managed within Elm by an effect manager (though it 
tends to eventually go out to a javascript effect manager, like via HTTP 
requests or whatever).


On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
wrote: 

> If my assumptions are correct then my main concern is that for every state 
> update this "expensive" side effects that could be performed on the JS side 
> by creating a new subscription are executed for every model update. If that 
> is the case then I have the following questions
>

A subscription is just that, a subscription, saying that you 'want to 
listen to messages from a given effect manager'.  The remote effect manager 
could even be doing stuff even when nothing is subscribed, a subscription 
is just that the main app wants to listen to messages from that effect 
manager.  Subscriptions should change only based on your state.  Basically 
it works kind of like this:

1. You have a subscription that appears when something on your model is, 
say, True.
2. The system sees that a new subscription has appeared compared to the 
last check, so it calls into the effect manager (passing it a 
'registration' m

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

[Nick H]

Thread... resurrected!

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


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

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

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

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

[Duane Johnson]

On Tue, Nov 15, 2016 at 1:23 PM, 'Andrew Radford' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> No, it wasn't.  Some parts of the community were aware of it, but calling
> it a community decision is overstating it.


While I wish it were otherwise, my experience from other communities is
that consensus (if that's what you're looking for), or even an attempt at
complete inclusion, in community decision-making is both procedurally
costly and an impediment to progress.

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

[elm-discuss] How to manage subscriptions that require side effects?

[Guido Marucci Blas]

Hi everybody! I've been reading the docs and following Elm every now and 
then.  I did some toy application to learn the language and the 
architecture. I am working on a native iOS application so using Elm in my 
day job won't happen (for now). The main reason I want to learn Elm (apart 
from it being awesome!) is that I want to apply Elm's architecture to iOS 
with Swift (yeah a lot of people is doing the same thing). There are quite 
a few libraries that try to bring Elm's architecture to Swift but I don't 
want to use them. I want to implement something myself because that way I 
will be able to understand it better. 

The reason I am writing is that I want to better understand how 
subscriptions work internally. Please correct me if I am wrong. My 
understanding of how subscription works is that they provide a mechanism to 
"hook" to a stream of infinite events. Those events get mapped to your own 
application message by virtue of the message constructor function that is 
passed when creating a new subscription. As far as I can tell the only way 
of creating subscription is by a model update. Every time the model gets 
updated, Elm's runtime calls the subscription function (passed to the init 
function when you bootstrap your app). This gives us the change to create a 
new subscription based of the current state. Am I correct? 

   - Is there any other way of creating subscriptions? 
   - What happens when the process of starting a subscription needs to 
   perform a expensive side-effect? 
   - What is the Elm way of doing this?

Lets say that I have an application that connects to an external device and 
after connecting with this device it wants to start listening to a stream 
of data that this device reports every one second. Lets imagine this device 
is thermometer that advertises the room's temperature. I want to have an 
app that prints the average temperature since a connection with thermometer 
was established. We can omit how we connect with thermometer for now

type alias Model = 
{ thermometer: Maybe Thermometer
, temperatureSamples: List Float
}


type Msg 
  = ConnectedThermometer Thermometer
  | TemperatureSample Float


update : Msg -> Model -> (Model, Cmd Msg) 
update msg model =
  case msg of
ConnectedThermometer thermometer ->
  ({ model | thermometer = thermometer }, Cmd.none)


TemperatureSample temperature ->
  ({ model | temperatureSamples = temperature :: model.
temperatureSamples}, Cmd.none)

view : Model -> Html Msg
view model = 
  let
averageTemperature = (List.sum model.temperatureSamples) / List.length 
model.temperatureSamples
  in
Html.text (toString averageTemperature)


subscriptions : Model -> Sub Msg
subscriptions model =
  model.thermometer
|> map Thermometer.temperature TemperatureSample
|> withDefault Sub.none


-- Inside the Thermometer module
temperature : (Float -> Msg) -> Thermometer -> Sub Msg
temperature msgConstructor thermometer = ...


*I am assuming there is a function in the Thermometer that knows how to 
create subscription for a given connected thermometer. I am also assuming 
that this MUST be implemented in Javascript and that all needed 
side-effects in order to create the subscription are performed on the JS 
side.*

If my assumptions are correct then my main concern is that for every state 
update this "expensive" side effects that could be performed on the JS side 
by creating a new subscription are executed for every model update. If that 
is the case then I have the following questions 


   - Is the responsibility of the JS code that creates the subscriptions to 
   keep track of the created subscriptions and avoid creating a new one if a 
   previous subscription to the same thermometer has already been created? 
   - How would you terminate a subscription? 
   - What happens if the process of establishing a subscription could fail? 
   - What is the best way to handle that? 
   - Do I need to execute a command to perform the side effect (which could 
   possible fail) that would allow to create a subscription and if and only if 
   this command is successfully executed then try to create a subscription?

Sorry for the big bulk of text and thanks in advance!

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

Re: [elm-discuss] 0.18 Below the Hood

[OvermindDL1]

Most of it is safety, you can work around it by excluding type definitions, 
or using magical type definition, in fact take this example with magical 
type definitions (put it in http://elm-lang.org/try or so):
```elm
import Html exposing (div, br, text)

filterIfAbove  : List comparable -> comparable -> List comparable
filterIfAbove  l above =
  let
aux : comparable -> Bool
aux v = v <= above
  in List.filter aux l

main =
  div []
  [ br [] [], text (toString (filterIfAbove [1,2,3,4,5] 3))
  , br [] [], text (toString (filterIfAbove [1.1,2.2,3.3,4.4,5.5] 3.0))
  , br [] [], text (toString (filterIfAbove ["Hello","World"] "Test"))
  ]
```
This prints out:
```
[1,2,3]
[1.1,2.2]
["Hello"]
```
Which is entirely expected, so let's make a new function that acts a little 
bit different:
```elm
addTogetherIfAbove : List comparable -> comparable -> comparable
addTogetherIfAbove l above =
  let
aux : comparable -> Bool
aux v = v <= above
  in List.filter aux l |> List.sum
```
Now remember, elm does not have real typeclasses, things like comparable 
are breaking the type system since they are internal magic, so with magic 
this compiles!  And it outputs what I'd expect:
```elm
main =
  div []
  [ br [] [], text (toString (addTogetherIfAbove [1,2,3,4,5] 3))
  , br [] [], text (toString (addTogetherIfAbove [1.1,2.2,3.3,4.4,5.5] 3.0))
  , br [] [], text (toString (addTogetherIfAbove ["Hello","World"] "Test"))
  ]
```
Output:
```
6
3.3003
"Hello0"
```
It outputs entirely wtf.

However I got side-tracked by the sudden wtf, back to the issue.  ^.^
Define this function again without typing:
```elm
addTogetherIfAbove l above =
  let
aux v = v <= above
  in List.filter aux l |> List.sum
```
It compiles and works fine (and will properly give an error message if you 
pass in a list of strings),

Using this code in elm 0.17, before this feature was added:
```elm

import Html exposing (div, br, text)

addTogetherIfAbove : List a -> a -> a
addTogetherIfAbove l above =
  let
aux : a -> Bool
aux v = v <= above
  in List.filter aux l |> List.sum

main =
  div []
  [ br [] [], text (toString (addTogetherIfAbove [1,2,3,4,5] 3))
  , br [] [], text (toString (addTogetherIfAbove [1.1,2.2,3.3,4.4,5.5] 3.0))
  ]
```
You'd get this for this the compile output in 0.17:
```
-- TYPE MISMATCH -- 
main.elm

The type annotation for `aux` does not match its definition.

6| aux : a -> Bool
 ^
The type annotation is saying:

a -> Bool

But I am inferring that the definition has this type:

comparable -> Bool

Hint: A type annotation is too generic. You can probably just switch to the 
type
I inferred. These issues can be subtle though, so read more about it.

```
And, uh, this is because Elm does not have HKT's, hrmm, how to show this 
without HKT's..

Oh fascinating, tried this code:
```elm

import Html exposing (div, br, text)

addTogetherIfAbove : List a -> a -> a
addTogetherIfAbove l above =
  let
aux : comparable -> Bool
aux v = v <= above
  in List.filter aux l |> List.sum

main =
  div []
  [ br [] [], text (toString (addTogetherIfAbove [1,2,3,4,5] 3))
  , br [] [], text (toString (addTogetherIfAbove [1.1,2.2,3.3,4.4,5.5] 3.0))
  ]
```
And got this from the compiler:
```
elm-make: It looks like something went wrong with the type inference 
algorithm.

Unable to generalize a type variable. It is not unranked.

Please create a minimal example that triggers this problem and report it to

elm-make: thread blocked indefinitely in an MVar operation
```
Well that is new, elm is not enforcing that the type `a` must be comparable 
due to its usage in the `List.filter` call, and it cannot enforce that it 
is a `number` because of the `List.sum` call, and so it croaks with a new 
error message, fun...

Well in general there are usages where if you leave the type information 
out, it works, but if you try to type it then you absolutely cannot.  A 
more simple example might just be:
```elm
import Html exposing (div, br, text)

blah : a -> b -> (a, b)
blah a b =
  let
aux : a
aux = a
  in (aux, b)

main =
  div []
[ br [] [], text (toString (blah 2 3))
]
```
Will compile fine in 0.18, but gives this error in 0.17:
```
The type annotation for `blah` does not match its definition.

3| blah : a -> b -> (a, b)
  
The type annotation is saying:

a -> b -> ( a, b )

But I am inferring that the definition has this type:

a -> b -> ( c, b )

Hint: A type annotation is clashing with itself or with a sub-annotation. 
This
can be particularly tricky, so read more about it.


Detected errors in 1 module.
```



On Tuesday, November 15, 2016 at 11:43:58 AM UTC-7, John Orford wrote:
>
> 

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

['Andrew Radford' via Elm Discuss]

No, it wasn't.  Some parts of the community were aware of it, but calling 
it a community decision is overstating it. 

On Tuesday, 15 November 2016 15:30:52 UTC, Robin Heggelund Hansen wrote:
>
>  This was very much a community 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] What do you think about Eve?

[Nick H]

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

On Tue, Nov 15, 2016 at 11:27 AM, Nick H  wrote:

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

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

Re: [elm-discuss] What do you think about Eve?

[Nick H]

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

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

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

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

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

> I wonder, what the elm community thinks about Eve: http://witheve.com/ ?
> Here is the syntax reference: https://witheve.github.io/assets/docs/
> SyntaxReference.pdf
>
> I think that this language/architecture is worth to look at.
> It has many similarities with elm.
> But it is more like logic programming. (Is this the logic programming of
> the future?)
>
> I was following this project from far and I had the impression that he
> (Chris Granger) was doing some kind of excel.
> But now I see that they can do flappy bird in eve:
> http://play.witheve.com/#/examples/flappy.eve
> That is exciting!
>
> Is there something similar to Eve?
> It really looks like something new.
>
> My main question:
> What do you think, are advantages and disadvantages of Eve, if you compare
> it with Elm.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Making imports more pleasant

[Joey Eremondi]

I'm not sure what your proposing, the Python syntax you stated does the
exact same thing as exposing (..).

Showing where a name came from would be a great IDE feature though, Haskell
can do this on Atom and it's really helpful.

On Nov 15, 2016 10:33 AM, "Alejandro Do Nascimento" 
wrote:

> I'm just starting with Elm, I'm as newbie as someone can be. I'm reading
> some examples of how to use the hop router on github, most of the things
> I've have found use a lot of *exposing (..)* so I find myself wasting
> time just searching the declarations of the symbols I encounter. I think
> that's the only thing that I have found that makes Elm program a little
> harder to read.
>
> Maybe you can do like python does, in python you can import everything
> into your namespace with *from module import ** but that's something
> that's kind of frown upon the community and official style guide.
> On Monday, August 22, 2016 at 5:56:24 PM UTC+2, Francesco Orsenigo wrote:
>>
>> Are you going to write such plugin for every possible editor?
>> Is every newbie going to have such plugin?
>> What about browsing code from GitHub?
>>
>> A language's readability should not depend on tooling.
>>
>> On Mon, Aug 22, 2016 at 5:52 PM, William Bailey 
>> wrote:
>> > For years I coded in Java using IntelliJ.  It was super easy in that
>> IDE to
>> > hover on any symbol, system or otherwise, and learn all about it.  Or
>> hit
>> > ctrl-B (eg) to drill into the source. Again, worked fine for system
>> > libraries and was really useful for seeing how the under-the-covers
>> stuff
>> > worked.
>> >
>> > When I started coding in go-lang a couple years ago, people were
>> griping
>> > about having to manually remove unused imports as the compiler would
>> not
>> > allow that.  But now, most editors have plug-ins that do that
>> automatically.
>> >
>> > So... I think focusing on what the core language should and should not
>> allow
>> > here is misguided.  Just need better IDE tools.
>> >
>> > --
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "Elm Discuss" group.
>> > To unsubscribe from this topic, visit
>> > https://groups.google.com/d/topic/elm-discuss/ydhKsvJtDZw/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to
>> > elm-discuss...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+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] 0.18 Below the Hood

[John Orford]

> And there are certain classes of typed problems that are impossible
without this feature, so it is highly useful!

Can you expand on this? I imagine it's expressions all the way down and
type inference is still possible... so imagine it's a nice-to-have rather
than must-have.

Would like to understand more basically!
On Tue, 15 Nov 2016 at 17:40, OvermindDL1  wrote:

> On Tuesday, November 15, 2016 at 9:30:23 AM UTC-7, Max Goldstein wrote:
>
> My impression is that it's a Haskell extension that's very commonly used.
> In the process of upgrading, I uncommented some signatures only for the
> compiler to tell me that they are incorrect, so this feature has been
> useful already.
>
>
> Oh it is very useful!  And there are certain classes of typed problems
> that are impossible without this feature, so it is highly useful!
>
> An example of usage in OCaml anyway (since I have a shell of it up right
> now):
> ```ocaml
> let f (x : 'x) =
>   let a (y : 'x) = ()
>   in a
>
> let b = f 42 3
> ```
> That compiles right, changing b to this though:  let b = f 42 3.14
> Causes this error:
> ```
> Line 6, 14: Error: This expression has type float but an expression was
> expected of type
>  int
> ```
> Where this compiles fine (and may not only be entirely unexpected but
> could hide major bugs later in the program!):
> ```ocaml
> let f x =
>   let a y = ()
>   in a
>
> let b = f 42 3.14
> ```
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Making imports more pleasant

[Alejandro Do Nascimento]

I'm just starting with Elm, I'm as newbie as someone can be. I'm reading 
some examples of how to use the hop router on github, most of the things 
I've have found use a lot of *exposing (..)* so I find myself wasting time 
just searching the declarations of the symbols I encounter. I think that's 
the only thing that I have found that makes Elm program a little harder to 
read.

Maybe you can do like python does, in python you can import everything into 
your namespace with *from module import ** but that's something that's kind 
of frown upon the community and official style guide.
On Monday, August 22, 2016 at 5:56:24 PM UTC+2, Francesco Orsenigo wrote:
>
> Are you going to write such plugin for every possible editor? 
> Is every newbie going to have such plugin? 
> What about browsing code from GitHub? 
>
> A language's readability should not depend on tooling. 
>
> On Mon, Aug 22, 2016 at 5:52 PM, William Bailey  > wrote: 
> > For years I coded in Java using IntelliJ.  It was super easy in that IDE 
> to 
> > hover on any symbol, system or otherwise, and learn all about it.  Or 
> hit 
> > ctrl-B (eg) to drill into the source. Again, worked fine for system 
> > libraries and was really useful for seeing how the under-the-covers 
> stuff 
> > worked. 
> > 
> > When I started coding in go-lang a couple years ago, people were griping 
> > about having to manually remove unused imports as the compiler would not 
> > allow that.  But now, most editors have plug-ins that do that 
> automatically. 
> > 
> > So... I think focusing on what the core language should and should not 
> allow 
> > here is misguided.  Just need better IDE tools. 
> > 
> > -- 
> > You received this message because you are subscribed to a topic in the 
> > Google Groups "Elm Discuss" group. 
> > To unsubscribe from this topic, visit 
> > https://groups.google.com/d/topic/elm-discuss/ydhKsvJtDZw/unsubscribe. 
> > To unsubscribe from this group and all its topics, send an email to 
> > elm-discuss...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

Re: [elm-discuss] Help for article review for SPA applications in Elm 0.18

[Adrián Ribao]

Not sure about gh-pages, but I think is better to download the repo and 
checkout the tags running elm-reactor. It's quite easy to setup.

This way you can easily play with the code and make changes.

I will investigate about gh-pages though.

Thanks!

El martes, 15 de noviembre de 2016, 18:13:51 (UTC+1), Nick H escribió:
>
> I wonder if you could run the example on gh-pages? That way the links will 
> work (instead of linking to localhost).
>
> I've not ever used the navigation & url-parser packages, so some of this 
> was new to me. I like the way the program develops incrementally. Thanks 
> for sharing!
>
> On Tue, Nov 15, 2016 at 7:21 AM, Adrián Ribao  > wrote:
>
>> Hi!
>>
>> I've written a post related how to do SPAs using elm 0.18. It starts from 
>> scratch, following the process I took while I was creating mine.
>>
>> I'm new in Elm and functional languages so I'd love to get your feedback. 
>> Also, I'm not a native English speaker so the text could have typos or 
>> incorrect grammar. Any help is welcome.
>>
>> This is the post: 
>> https://medium.com/@adrian_ribao/how-to-create-a-spa-application-in-elm-0-18-from-scratch-68d25e0631f6
>>
>> It's also my first post on medium, I think you can make annotations even 
>> though it's in a draft state.
>>
>> Thank you!
>>
>> Adrián
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [elm-discuss] Help for article review for SPA applications in Elm 0.18

[Nick H]

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

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

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

> Hi!
>
> I've written a post related how to do SPAs using elm 0.18. It starts from
> scratch, following the process I took while I was creating mine.
>
> I'm new in Elm and functional languages so I'd love to get your feedback.
> Also, I'm not a native English speaker so the text could have typos or
> incorrect grammar. Any help is welcome.
>
> This is the post: https://medium.com/@adrian_ribao/how-to-create-a-spa-
> application-in-elm-0-18-from-scratch-68d25e0631f6
>
> It's also my first post on medium, I think you can make annotations even
> though it's in a draft state.
>
> Thank you!
>
> Adrián
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

[Nick H]

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

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

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

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

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

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

Re: [elm-discuss] 0.18 Below the Hood

[OvermindDL1]

On Tuesday, November 15, 2016 at 9:30:23 AM UTC-7, Max Goldstein wrote:
>
> My impression is that it's a Haskell extension that's very commonly used. 
> In the process of upgrading, I uncommented some signatures only for the 
> compiler to tell me that they are incorrect, so this feature has been 
> useful already.


Oh it is very useful!  And there are certain classes of typed problems that 
are impossible without this feature, so it is highly useful!

An example of usage in OCaml anyway (since I have a shell of it up right 
now):
```ocaml
let f (x : 'x) =
  let a (y : 'x) = ()
  in a

let b = f 42 3
```
That compiles right, changing b to this though:  let b = f 42 3.14
Causes this error:
```
Line 6, 14: Error: This expression has type float but an expression was 
expected of type
 int
```
Where this compiles fine (and may not only be entirely unexpected but could 
hide major bugs later in the program!):
```ocaml
let f x =
  let a y = ()
  in a

let b = f 42 3.14
```

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

[Max Goldstein]

My impression is that it's a Haskell extension that's very commonly used. In 
the process of upgrading, I uncommented some signatures only for the compiler 
to tell me that they are incorrect, so this feature has been useful already. 

Oh, and almost forgot: flipping the argument order for andThen, and the removal 
of backticks. It makes |> chains much nicer. 

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

[OvermindDL1]

On Tuesday, November 15, 2016 at 8:57:30 AM UTC-7, John Orford wrote:

> >  let-bound values can be given type annotations that reference type 
> variables from the top level
>
> that's v thoughtful actually, I hadn't heard that before, just local 
> variables in any case, makes a lot of sense for tricky functions.
>
> is this an elm specific creation or do you also see it in Haskell? (iirc, 
> never)
>

Haskell has an option for it: 
 
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#ghc-flag--XScopedTypeVariables

OCaml has it built-in.

I think SML has it built in too.

It is fairly common in other words, and very useful.  :-) 

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

[John Orford]

>  let-bound values can be given type annotations that reference type
variables from the top level

that's v thoughtful actually, I hadn't heard that before, just local
variables in any case, makes a lot of sense for tricky functions.

is this an elm specific creation or do you also see it in Haskell? (iirc,
never)

(what I wouldn't give for let-in in Python right now...)




On Tue, 15 Nov 2016 at 14:55 Max Goldstein  wrote:

> I'm personally looking forward to three longstanding bugs being fixed.
> First, recursive definitions like x = x are caught by the compiler. Second,
> a bug caching compiled forms of modules has been resolved, forcing a
> rebuild when necessary. Finally, let-bound values can be given type
> annotations that reference type variables from the top level. This makes
> certain code much more readable.
>
> 0.17 was a groundbreaking release. 0.18 is a much more polished one. It's
> true that we don't have server-side rendering yet, and the debugger UI
> needs a few tweaks, but this is forward progress and I'm happy for it.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

[Robin Heggelund Hansen]

I seem to remember that the discussion to keep or remove range syntax was 
done here on the mailing list, and a lot of people had no hard feelings 
about it going away. This was very much a community decision.

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

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

[elm-discuss] Help for article review for SPA applications in Elm 0.18

[Adrián Ribao]

Hi!

I've written a post related how to do SPAs using elm 0.18. It starts from 
scratch, following the process I took while I was creating mine.

I'm new in Elm and functional languages so I'd love to get your feedback. 
Also, I'm not a native English speaker so the text could have typos or 
incorrect grammar. Any help is welcome.

This is the post: 
https://medium.com/@adrian_ribao/how-to-create-a-spa-application-in-elm-0-18-from-scratch-68d25e0631f6

It's also my first post on medium, I think you can make annotations even 
though it's in a draft state.

Thank you!

Adrián

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

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

['Andrew Radford' via Elm Discuss]

I don't think flippantly dismissing anyone who abandons Elm as having a 
tenuous connection is fair.  A lot of existing users, especially long time 
users who when they started, may have done so because of the 'niceties' 
like this, and they are now being slowly eroded. Maybe you could say they 
are now better off going to purescript/websharper/whatever, but they are 
also the guys actually using Elm to get real stuff done, and  often act as 
evangelists /'recruiters' to bring more newcomers to Elm in the first 
place. Simplifying Elm to attract the JS hordes may be a good way to grow 
the user base, but it will come at the expense of some of these guys 
leaving, which is a bit sad. 

As usual, it's a tricky (but hopefully correct) BDFL decision for the good 
of the language ecosystem and usage, but not a clear slam-dunk for the 
language itself according to a lot of people.

On Tuesday, 15 November 2016 13:47:43 UTC, Max Goldstein wrote:
>
> If someone was so tenuously commuted to Elm that this syntax removal 
> drives them away, oh well.
>
>
>

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

[elm-discuss] 0.18 Below the Hood

[Max Goldstein]

I'm personally looking forward to three longstanding bugs being fixed. First, 
recursive definitions like x = x are caught by the compiler. Second, a bug 
caching compiled forms of modules has been resolved, forcing a rebuild when 
necessary. Finally, let-bound values can be given type annotations that 
reference type variables from the top level. This makes certain code much more 
readable. 

0.17 was a groundbreaking release. 0.18 is a much more polished one. It's true 
that we don't have server-side rendering yet, and the debugger UI needs a few 
tweaks, but this is forward progress and I'm happy for it. 

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

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

[Max Goldstein]

If someone was so tenuously commuted to Elm that this syntax removal drives 
them away, oh well.

Yes, the Elm language is getting smaller. That's been true for a few releases 
now. Evan is trying to remove hurdles for new users (because we need a lot of 
new users!), not preserve legacy code (Elm is young and inherently easy to 
refactor). 

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

[Pi]

Yes, that error did not appear with Elm 0.17. Changing the comparison to 
index >= period did not help.
However, I turned "number" in the type annotation to Float, and now it 
works.

Am Dienstag, 15. November 2016 12:49:28 UTC+1 schrieb 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

['Andrew Radford' via Elm Discuss]

I'd agree with all that - but it was also trivially achievable in 0.17. 
Make no mistake, this is a *reduction* of the Elm language, the gamble 
being that it will result in more new users moving to and sticking with 
Elm, than existing users bailing in favour of some other alternative. I 
suspect it will probably work.



On Tuesday, 15 November 2016 12:15:13 UTC, Witold Szczerba wrote:
>
> I really like the change (getting rid of an exceptional syntax), but 
> what's more important is how other things adapts: see the example 
> provided by Joey:
> >For example, if you want the range [0 .. n] for n in [0 .. k]:
> >
> > Old syntax:
> >   map (\x -> [0 .. x]) [0 .. k]
> > New syntax:
> >   map (Range 0) (Range 0 k)
>
> OK, it's just very simple piece of code, imagine something more 
> sophisticated… You can partially apply a function, but not the range 
> syntax. In functional languages like Elm, the more you have is nothing but 
> a normal function the better, other "building" blocks just get in the way.
>
> Regards,
> Witold Szczerba
>
>
>
>

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

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

[Witold Szczerba]

I really like the change (getting rid of an exceptional syntax), but what's
more important is how other things adapts: see the example provided by Joey:
>For example, if you want the range [0 .. n] for n in [0 .. k]:
>
> Old syntax:
>   map (\x -> [0 .. x]) [0 .. k]
> New syntax:
>   map (Range 0) (Range 0 k)

OK, it's just very simple piece of code, imagine something more
sophisticated… You can partially apply a function, but not the range
syntax. In functional languages like Elm, the more you have is nothing but
a normal function the better, other "building" blocks just get in the way.

Regards,
Witold Szczerba


On Tue, Nov 15, 2016 at 11:59 AM, 'Andrew Radford' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> Lists are pretty core, I don't really have a problem with short expressive
> syntax that reads well. 'Well' meaning closer to reading like English. i.e
> I'd never say "I'll drink Bourbon on the range of days from 1 to 3, then
> Scotch on the days that range from day 4 to day 7". No way, it's just
> "Bourbon on days 1-3, Scotch on days 4-7". In other words, when you declare
> a range, the more interesting and important thing you are trying to express
> is what you are doing *with* that range - i.e. what I'm drinking, the
> 'List.Range' clutter waters that down as noise in a lot of cases.
>
> I can see this is probably a 50/50 among users - so although I personally
> will miss it a little bit, I can see how the decision to make it easier for
> newcomers to the language to get started would tip the balance in favor of
> List.Range. After all, 'Lets be mainstream' effectively means 'Let's
> convert people who currently just use JS' so this call must be in pursuit
> of increasing the 'conversion ratio'
>
>
>
>
> On Monday, 14 November 2016 23:14:58 UTC, Joey Eremondi wrote:
>>
>> It's also worth mentioning that adding syntax for something usually
>> indicates that it's a "core" feature.
>>
>> In C-like languages, looping from integers in a range is the key
>> iteration structure. But in Elm, fold and map are much more important. So
>> having special syntax could give beginners the idea that [..] is a primary
>> iteration tool, when it actually comes up in relatively few cases.
>>
>> On Mon, Nov 14, 2016 at 3:13 PM, Francesco Orsenigo <
>> francesco...@gmail.com> wrote:
>>
>>> Yup.
>>> It is just not used often enough to warrant special syntax.
>>>
>>> On Tue, Nov 15, 2016 at 10:09 AM, Witold Szczerba
>>>  wrote:
>>> > I think List.range is just fine. No need for special syntax and strange
>>> > function names like ".." (hard to browse, find online, etc.).
>>> >
>>> > On Mon, Nov 14, 2016 at 10:29 PM, أحمد حبنكة 
>>> > wrote:
>>> >>
>>> >> What do you think about my suggestion in previous reply ? replacing
>>> >> List.range with List.(..) operator ?
>>> >>
>>> >>
>>> >> بتاريخ الاثنين، 14 نوفمبر، 2016 2:43:49 ص UTC+2، كتب Max Goldstein:
>>> >>>
>>> >>> Sometimes it's useful to pass arguments to List.range and have it be
>>> >>> empty when a > b.
>>> >>>
>>> >>> Perhaps there should be List.rangeWithStep 5 1 -1 to solve your
>>> problem.
>>> >>
>>> >> --
>>> >> You received this message because you are subscribed to the Google
>>> Groups
>>> >> "Elm Discuss" group.
>>> >> To unsubscribe from this group and stop receiving emails from it,
>>> send an
>>> >> email to elm-discuss...@googlegroups.com.
>>> >> For more options, visit https://groups.google.com/d/optout.
>>> >
>>> >
>>> > --
>>> > You received this message because you are subscribed to a topic in the
>>> > Google Groups "Elm Discuss" group.
>>> > To unsubscribe from this topic, visit
>>> > https://groups.google.com/d/topic/elm-discuss/z8t8u2f3iWk/unsubscribe.
>>> > To unsubscribe from this group and all its topics, send an email to
>>> > elm-discuss...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and 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.

[elm-discuss] Elm 0.18: What's wrong with "number" type?

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

Re: [elm-discuss] Re: Why Range syntax got removed in favor of List.range

['Andrew Radford' via Elm Discuss]

Lists are pretty core, I don't really have a problem with short expressive 
syntax that reads well. 'Well' meaning closer to reading like English. i.e 
I'd never say "I'll drink Bourbon on the range of days from 1 to 3, then 
Scotch on the days that range from day 4 to day 7". No way, it's just 
"Bourbon on days 1-3, Scotch on days 4-7". In other words, when you declare 
a range, the more interesting and important thing you are trying to express 
is what you are doing *with* that range - i.e. what I'm drinking, the 
'List.Range' clutter waters that down as noise in a lot of cases.

I can see this is probably a 50/50 among users - so although I personally 
will miss it a little bit, I can see how the decision to make it easier for 
newcomers to the language to get started would tip the balance in favor of 
List.Range. After all, 'Lets be mainstream' effectively means 'Let's 
convert people who currently just use JS' so this call must be in pursuit 
of increasing the 'conversion ratio'




On Monday, 14 November 2016 23:14:58 UTC, Joey Eremondi wrote:
>
> It's also worth mentioning that adding syntax for something usually 
> indicates that it's a "core" feature.
>
> In C-like languages, looping from integers in a range is the key iteration 
> structure. But in Elm, fold and map are much more important. So having 
> special syntax could give beginners the idea that [..] is a primary 
> iteration tool, when it actually comes up in relatively few cases.
>
> On Mon, Nov 14, 2016 at 3:13 PM, Francesco Orsenigo <
> francesco...@gmail.com > wrote:
>
>> Yup.
>> It is just not used often enough to warrant special syntax.
>>
>> On Tue, Nov 15, 2016 at 10:09 AM, Witold Szczerba
>> > wrote:
>> > I think List.range is just fine. No need for special syntax and strange
>> > function names like ".." (hard to browse, find online, etc.).
>> >
>> > On Mon, Nov 14, 2016 at 10:29 PM, أحمد حبنكة > >
>> > wrote:
>> >>
>> >> What do you think about my suggestion in previous reply ? replacing
>> >> List.range with List.(..) operator ?
>> >>
>> >>
>> >> بتاريخ الاثنين، 14 نوفمبر، 2016 2:43:49 ص UTC+2، كتب Max Goldstein:
>> >>>
>> >>> Sometimes it's useful to pass arguments to List.range and have it be
>> >>> empty when a > b.
>> >>>
>> >>> Perhaps there should be List.rangeWithStep 5 1 -1 to solve your 
>> problem.
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google 
>> Groups
>> >> "Elm Discuss" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send 
>> an
>> >> email to elm-discuss...@googlegroups.com .
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> > --
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "Elm Discuss" group.
>> > To unsubscribe from this topic, visit
>> > https://groups.google.com/d/topic/elm-discuss/z8t8u2f3iWk/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to
>> > elm-discuss...@googlegroups.com .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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