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

[Nick H]

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


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

Good luck!

On Sun, Oct 23, 2016 at 7:58 PM, John Kelly  wrote:

> To my knowledge, the recursive type that you specified *will* compile.
> See here
> 
> .
>
> My issue is in fact related to mutually recursive types, it's just that my
> types are truly infinite. According to the linked doc about recursive types:
> "Somewhere in that cycle, you need to define an actual type to end the
> infinite expansion." Which mine does not.
>
> And to address your comment in regards to: "But still, I think you might
> be able to salvage the API if you wrap the records in union type
> constructors." This is the idea I will be exploring next, thank you for the
> recommendation.
>
>
>
> On Sunday, October 23, 2016 at 6:19:38 PM UTC-7, Nick H wrote:
>>
>> I guess you weren't explicitly defining type aliases for those records.
>> But still, I think you might be able to salvage the API if you wrap the
>> records in union type constructors.
>>
>> On Sun, Oct 23, 2016 at 6:10 PM, Nick H  wrote:
>>
>>> If you are trying to make a recursive type definition, you need to use
>>> union types.
>>>
>>> E.G. This is not OK:
>>>
>>> type alias Session = { speaker : Speaker }
>>> type alias Speaker = { sessions : List Session }
>>>
>>> But this will compile.
>>>
>>> type Session = Session { speaker : Speaker }
>>> type Speaker = Speaker { sessions : List Session }
>>>
>>> Think of a type alias as a kind of search-and-replace. A recursive type
>>> alias leads to a never-ending search-and-replace process.
>>>
>>>
>>>
>>> On Sun, Oct 23, 2016 at 5:17 PM, John Kelly  wrote:
>>>
 I'm coming to the sad realization that an api like this is simply not
 possible:

 ```
 session =
 resource "sessions"
 { id = int "id"
 , speaker_id = int "speaker_id"
 , start_time = string "start_time"
 , end_time = string "end_time"
 , location = string "location"
 , session_type = int "session_type"
 , speaker = hasOne (\_ -> speaker)
 }


 speaker =
 resource "speakers"
 { id = int "id"
 , name = string "name"
 , sessions = hasMany (\_ -> session)
 }
 ```

 Any ideas? I was under the impression that the lambda would fix the
 recursive type issue, but now i see that elm still has trouble with the
 type of the record.

 On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote:
>
> Just to follow up on the limitations in my library I spoke about --
> namely, not being able to represent the relationships *in *the
> resource definition. I spent a bit of time drafting up some potential api
> changes that would make it possible: here
> 
> .
>
> Handling the recursive nature of relationships was influenced by
> Json.Decode.Extra.lazy
> 
>
> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote:
>>
>> Great Question!
>>
>> You can checkout an example here
>> .
>> It builds off of the example presented in the docs.
>>
>> Currently, the library does not support representing relationships in
>> the Resource definition, however, the library *does *support
>> representing the relationships in the queries (see example). I'm not yet
>> sure the best way / whether it will be possible to represent the
>> relationships in the Resource definition. Would love to chat if you have
>> any ideas!
>>
>>
>>
>> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote:
>>>
>>> Hi John,
>>>
>>> The project you linked to looks great.
>>> How do you deal with references? (entities referencing other
>>> entities)
>>>
>>>
>>>
>>> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly 
>>> wrote:
>>>
 I'm sorry to link drop, but I've been doing a bit of work on a
 library to remove some of the boilerplate when writing client code for 
 a
 REST API. The library is currently locked in / specific to what is 
 called

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

[John Kelly]

To my knowledge, the recursive type that you specified *will* compile. See 
here 

. 

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

And to address your comment in regards to: "But still, I think you might be 
able to salvage the API if you wrap the records in union type 
constructors." This is the idea I will be exploring next, thank you for the 
recommendation.



On Sunday, October 23, 2016 at 6:19:38 PM UTC-7, Nick H wrote:
>
> I guess you weren't explicitly defining type aliases for those records. 
> But still, I think you might be able to salvage the API if you wrap the 
> records in union type constructors.
>
> On Sun, Oct 23, 2016 at 6:10 PM, Nick H  > wrote:
>
>> If you are trying to make a recursive type definition, you need to use 
>> union types.
>>
>> E.G. This is not OK:
>>
>> type alias Session = { speaker : Speaker }
>> type alias Speaker = { sessions : List Session }
>>
>> But this will compile.
>>
>> type Session = Session { speaker : Speaker }
>> type Speaker = Speaker { sessions : List Session }
>>
>> Think of a type alias as a kind of search-and-replace. A recursive type 
>> alias leads to a never-ending search-and-replace process.
>>
>>
>>
>> On Sun, Oct 23, 2016 at 5:17 PM, John Kelly > > wrote:
>>
>>> I'm coming to the sad realization that an api like this is simply not 
>>> possible:
>>>
>>> ```
>>> session =
>>> resource "sessions"
>>> { id = int "id"
>>> , speaker_id = int "speaker_id"
>>> , start_time = string "start_time"
>>> , end_time = string "end_time"
>>> , location = string "location"
>>> , session_type = int "session_type"
>>> , speaker = hasOne (\_ -> speaker)
>>> }
>>>
>>>
>>> speaker =
>>> resource "speakers"
>>> { id = int "id"
>>> , name = string "name"
>>> , sessions = hasMany (\_ -> session)
>>> }
>>> ```
>>>
>>> Any ideas? I was under the impression that the lambda would fix the 
>>> recursive type issue, but now i see that elm still has trouble with the 
>>> type of the record. 
>>>
>>> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote:

 Just to follow up on the limitations in my library I spoke about -- 
 namely, not being able to represent the relationships *in *the 
 resource definition. I spent a bit of time drafting up some potential api 
 changes that would make it possible: here 
 . 

 Handling the recursive nature of relationships was influenced by 
 Json.Decode.Extra.lazy 
 

 On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote:
>
> Great Question!
>
> You can checkout an example here 
> . 
> It builds off of the example presented in the docs. 
>
> Currently, the library does not support representing relationships in 
> the Resource definition, however, the library *does *support 
> representing the relationships in the queries (see example). I'm not yet 
> sure the best way / whether it will be possible to represent the 
> relationships in the Resource definition. Would love to chat if you have 
> any ideas!
>
>
>
> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote:
>>
>> Hi John, 
>>
>> The project you linked to looks great. 
>> How do you deal with references? (entities referencing other 
>> entities)  
>>
>>
>>
>> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly  
>> wrote:
>>
>>> I'm sorry to link drop, but I've been doing a bit of work on a 
>>> library to remove some of the boilerplate when writing client code for 
>>> a 
>>> REST API. The library is currently locked in / specific to what is 
>>> called 
>>> PostgREST, but I imagine that the patterns could be applied to any REST 
>>> backend. Check it out: https://github.com/john-kelly/elm-postgrest/
>>>
>>> The core idea is to remove the boilerplate of always having to 
>>> define encoder, decoder and schema. Would love to chat.
>>>
>>> --
>>> You received this message because you are subscribed to the Google 
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to elm-discuss...@googlegroups.com.
>>> For more options, visit 

[elm-discuss] Re: How to write function that updates arbitrary element of a record

[Leroy Campbell]

I think I have something close to what you're looking for, but my solution 
makes me wonder, *why store text in your model rather than the parsed 
float/int values?* It seems like you want the parsed values for a 
calculation, not to format a paragraph of text.

update : Msg -> Model -> Model
update msg model =
  case msg of
ChangeDripText dripText ->
  { model
| dripText = valueOrDefault model.dripText String.toFloat dripText
  }

ChangeHoursText simulationHoursText ->
  { model
| simulationHoursText = valueOrDefault model.simulationHoursText 
String.toInt simulationHoursText
  }

ChangeMinutesText simulationMinutesText ->
  { model
| simulationMinutesText = valueOrDefault 
model.simulationMinutesText String.toInt simulationMinutesText
  }


valueOrDefault : a -> (a -> Result x b) -> a -> a
valueOrDefault default test value =
  test value
|> Result.map (always value)
|> Result.withDefault default

On Wednesday, October 19, 2016 at 10:49:03 AM UTC-4, Brian Marick wrote:
>
> I have a model that looks like this:
>
> type alias Model =
>   { ...
>   , dripText : String
>   , simulationHoursText : String
>   , simulationMinutesText : String
>   ...
>   }
>
> Those strings each correspond to a text field containing floating point 
> numbers. The whole thing looks like this:
>
>
> The text fields ensure that the values are all valid when characters are 
> typed, using `onInput` messages.  I would very much like to write something 
> like:
>
> — Ignore the fact that this `update` doesn’t return
> — a `Cmd Msg`. That’s coming.
> update : Msg -> Model -> Model
> update msg model =
>   case msg of
> ChangedDripText string ->
>   updateWhen isValidFloatString dripText string
> ChangedHoursText string ->
>   updateWhen isValidIntString simulationHoursText string
> ChangedMinutesText string ->
>   updateWhen isValidIntString simulationMinutesText string   
>
> … because that shows what’s different about each case. (Especially useful 
> is highlighting which fields accept integers and which floats.) 
>
> However, I think - based on 
> https://lexi-lambda.github.io/blog/2015/11/06/functionally-updating-record-types-in-elm/
>  
> - there’s no way to do that. Which has me writing this copypasta: 
>
> updateNextSpeed model nextString =
>   if isValidFloatString nextString then
> {model | dripText = nextString }
>   else
> model
>   
> updateHours model nextString =
>   if isValidIntString nextString then
> {model | simulationHoursText = nextString } 
>   else
> model
>
> updateMinutes model nextString = 
>   if isValidIntString nextString then
> {model | simulationMinutesText = nextString }
>   else
> model
>   
>
> update : Msg -> Model -> Model
> update msg model =
>   case msg of
> ChangedDripText string ->
>   updateNextSpeed model string
> ChangedHoursText string ->
>   updateHours model string
> ChangedMinutesText string ->
>   updateMinutes model string
>
> Is there a better way to handle this?
>

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

Re: [elm-discuss] Taking over the DOM in WebGL

[Rudi Chen]

This is possible, the folks at Figma are doing something similar to have a
native-like editing experience on the browser. It's hard though, you'd be
implementing a whole rendering engine to achieve that.

For the more average application, it would restrict you to one-page apps,
failures wouldn't be as graceful, etc. It's not clear that it would be
worth it. I mean, the Chrome team tries hard to use GPU-accelerated
rendering and are only getting so far, despite working with less
restrictions then WebGL.

On Sun, Oct 23, 2016 at 11:22 AM, Zane Hitchcox 
wrote:

> Would there be any interest/way to just take over the dom rather than use
> diffing? Like, could we just control the screen directly using WebGL and
> eliminate the dom completely?
>
> I feel like this would be easy using Three.js, but no one has done it...am
> I missing something here?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Nick H]

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

On Sun, Oct 23, 2016 at 6:10 PM, Nick H  wrote:

> If you are trying to make a recursive type definition, you need to use
> union types.
>
> E.G. This is not OK:
>
> type alias Session = { speaker : Speaker }
> type alias Speaker = { sessions : List Session }
>
> But this will compile.
>
> type Session = Session { speaker : Speaker }
> type Speaker = Speaker { sessions : List Session }
>
> Think of a type alias as a kind of search-and-replace. A recursive type
> alias leads to a never-ending search-and-replace process.
>
>
>
> On Sun, Oct 23, 2016 at 5:17 PM, John Kelly  wrote:
>
>> I'm coming to the sad realization that an api like this is simply not
>> possible:
>>
>> ```
>> session =
>> resource "sessions"
>> { id = int "id"
>> , speaker_id = int "speaker_id"
>> , start_time = string "start_time"
>> , end_time = string "end_time"
>> , location = string "location"
>> , session_type = int "session_type"
>> , speaker = hasOne (\_ -> speaker)
>> }
>>
>>
>> speaker =
>> resource "speakers"
>> { id = int "id"
>> , name = string "name"
>> , sessions = hasMany (\_ -> session)
>> }
>> ```
>>
>> Any ideas? I was under the impression that the lambda would fix the
>> recursive type issue, but now i see that elm still has trouble with the
>> type of the record.
>>
>> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote:
>>>
>>> Just to follow up on the limitations in my library I spoke about --
>>> namely, not being able to represent the relationships *in *the resource
>>> definition. I spent a bit of time drafting up some potential api changes
>>> that would make it possible: here
>>> .
>>>
>>> Handling the recursive nature of relationships was influenced by
>>> Json.Decode.Extra.lazy
>>> 
>>>
>>> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote:

 Great Question!

 You can checkout an example here
 .
 It builds off of the example presented in the docs.

 Currently, the library does not support representing relationships in
 the Resource definition, however, the library *does *support
 representing the relationships in the queries (see example). I'm not yet
 sure the best way / whether it will be possible to represent the
 relationships in the Resource definition. Would love to chat if you have
 any ideas!



 On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote:
>
> Hi John,
>
> The project you linked to looks great.
> How do you deal with references? (entities referencing other entities)
>
>
>
>
> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly 
> wrote:
>
>> I'm sorry to link drop, but I've been doing a bit of work on a
>> library to remove some of the boilerplate when writing client code for a
>> REST API. The library is currently locked in / specific to what is called
>> PostgREST, but I imagine that the patterns could be applied to any REST
>> backend. Check it out: https://github.com/john-kelly/elm-postgrest/
>>
>> The core idea is to remove the boilerplate of always having to define
>> encoder, decoder and schema. Would love to chat.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to elm-discuss...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
 --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [elm-discuss] Anyone using Firebase 3.0 with Elm 0.17?

[Scott Mueller]

Just a friendly bump and vote for Elm 0.18 and Firebase 3.0 support... Also 
happy to help with this.

On Wednesday, August 17, 2016 at 4:29:49 AM UTC-7, Thomas Weiser wrote:
>
> I have sketched an API for an effect manager module and will discuss it 
> soon with you all. 
>
> First I will target Firebase's existing realtime database and 
> authentication API before switching to Firebase 3.0 and its new 
> authentication API. I have not looked into Firebase's new storage API yet. 
>
> Sorry for the long delay. Time is very limited atm. Will be better from 
> September onwards. 
>
>
> On 17.08.2016 09:29, Corey Trampe wrote: 
> > I've been watching ElmFire for the 0.17 update 
> > , and Firebase 3.x 
> > support , but I 
> > guess Thomas Weiser hasn't had time to work on it. (And I'm not here 
> > to complain about free software! Thanks, Thomas, for sharing your good 
> > work.) 
> > 
> > But in the meantime... is anyone using Firebase 3.x with Elm 0.17? 
> > 
> > Are you using ports, or a custom effect manager? 
> > 
> > How's it working out? Can you share what you've learned? 
> > 
> > ( I need the new API for Storage 
> > . ) 
> > 
> > Thanks! 
>

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

[elm-discuss] Re: Problem with Html.Lazy

[Frank Bonetti]

I'd also like to hear way it was designed this way. I assumed that `lazy` 
would compare the argument *values*, not *references*. It appears to use 
`===` under the hood.

In its current state, lazy is pretty much unusable unless the given 
argument is a String, Int, Float, Bool (in other words, it must be a 
Javascript primitive). Records, Lists, Arrays, and Tuples will NOT pass the 
equality test even the value hasn't changed, since `===` on objects and 
arrays in Javascript always returns false unless the reference is the same. 
For example, { model | data = model.data } results in a new `model` 
reference, even though the value is exactly the same.

I understand that a deep equality check could potentially be very 
expensive, but it would be worth it if I could avoid having to diff and 
render thousands of elements. Perhaps we could have different lazy 
functions? One that checks on reference and one that checks of value 
equality?

In case anyone is wondering, I worked around this issue by removing the 
tuple argument from my view function and replacing it with regular 
arguments:

renderCell : ( Int, Int ) -> String -> Html Msg

changed to:

renderCell : Int -> Int -> String -> Html Msg




On Tuesday, September 13, 2016 at 8:43:28 AM UTC-5, James Wilson wrote:
>
> I had similar feelings; lazy uses a magical referential equality between 
> things that afaik isn't exposed elsewhere; to me it would be more 
> obvious/clear if it used the same sort of equality as everything else (==), 
> which I'd hope would be able to short circuit the meat of the checking if 
> referentially equal anyway.
>
> Basically, I'd be interested to hear more about the decision to use 
> referential equality with lazy too :)
>
> On Tuesday, 13 September 2016 12:09:05 UTC+1, Yosuke Torii wrote:
>>
>> Hi,
>>
>> I have a question about Html.Lazy.
>>
>> Now I'm optimizing rendering using Html.Lazy but I feel it is difficult 
>> to use. I found the arguments are not often *referentially* equal and 
>> the view functions are unfortunately called. There are some problems around 
>> this.
>>
>>
>> 1. Sometimes new values are created every time.
>>
>> view model = lazy someView { data = model.data }
>>
>> 2. Views do not know how arguments are passed.
>>
>> view model = lazy grandchildView model
>>
>> 3. It is not easy to know if optimization succeeds or not.
>>
>> view model = Debug.log "Unfortunately called!" <| text (toString model)
>>
>>
>> I made a demo to describe this problem.
>>
>> Source: https://github.com/jinjor/elm-issues/blob/master/src/HtmlLazy.elm
>> Demo: https://jinjor.github.io/elm-issues/html-lazy.html
>> (9 example views, but 4 ~ 9 are not optimized unfortunately)
>>
>> So my question is:
>>
>>- Is it a bad idea to compare by *normal *equal? 
>>- Have anyone already solved this problem?
>>
>>
>> Thanks.
>>
>

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

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

[Nick H]

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

E.G. This is not OK:

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

But this will compile.

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

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



On Sun, Oct 23, 2016 at 5:17 PM, John Kelly  wrote:

> I'm coming to the sad realization that an api like this is simply not
> possible:
>
> ```
> session =
> resource "sessions"
> { id = int "id"
> , speaker_id = int "speaker_id"
> , start_time = string "start_time"
> , end_time = string "end_time"
> , location = string "location"
> , session_type = int "session_type"
> , speaker = hasOne (\_ -> speaker)
> }
>
>
> speaker =
> resource "speakers"
> { id = int "id"
> , name = string "name"
> , sessions = hasMany (\_ -> session)
> }
> ```
>
> Any ideas? I was under the impression that the lambda would fix the
> recursive type issue, but now i see that elm still has trouble with the
> type of the record.
>
> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote:
>>
>> Just to follow up on the limitations in my library I spoke about --
>> namely, not being able to represent the relationships *in *the resource
>> definition. I spent a bit of time drafting up some potential api changes
>> that would make it possible: here
>> .
>>
>> Handling the recursive nature of relationships was influenced by
>> Json.Decode.Extra.lazy
>> 
>>
>> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote:
>>>
>>> Great Question!
>>>
>>> You can checkout an example here
>>> .
>>> It builds off of the example presented in the docs.
>>>
>>> Currently, the library does not support representing relationships in
>>> the Resource definition, however, the library *does *support
>>> representing the relationships in the queries (see example). I'm not yet
>>> sure the best way / whether it will be possible to represent the
>>> relationships in the Resource definition. Would love to chat if you have
>>> any ideas!
>>>
>>>
>>>
>>> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote:

 Hi John,

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



 On Thu, Oct 20, 2016 at 9:19 PM, John Kelly  wrote:

> I'm sorry to link drop, but I've been doing a bit of work on a library
> to remove some of the boilerplate when writing client code for a REST API.
> The library is currently locked in / specific to what is called PostgREST,
> but I imagine that the patterns could be applied to any REST backend. 
> Check
> it out: https://github.com/john-kelly/elm-postgrest/
>
> The core idea is to remove the boilerplate of always having to define
> encoder, decoder and schema. Would love to chat.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to elm-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

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

[John Kelly]

I'm coming to the sad realization that an api like this is simply not 
possible:

```
session =
resource "sessions"
{ id = int "id"
, speaker_id = int "speaker_id"
, start_time = string "start_time"
, end_time = string "end_time"
, location = string "location"
, session_type = int "session_type"
, speaker = hasOne (\_ -> speaker)
}


speaker =
resource "speakers"
{ id = int "id"
, name = string "name"
, sessions = hasMany (\_ -> session)
}
```

Any ideas? I was under the impression that the lambda would fix the 
recursive type issue, but now i see that elm still has trouble with the 
type of the record. 

On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote:
>
> Just to follow up on the limitations in my library I spoke about -- 
> namely, not being able to represent the relationships *in *the resource 
> definition. I spent a bit of time drafting up some potential api changes 
> that would make it possible: here 
> . 
>
> Handling the recursive nature of relationships was influenced by 
> Json.Decode.Extra.lazy 
> 
>
> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote:
>>
>> Great Question!
>>
>> You can checkout an example here 
>> . 
>> It builds off of the example presented in the docs. 
>>
>> Currently, the library does not support representing relationships in the 
>> Resource definition, however, the library *does *support representing 
>> the relationships in the queries (see example). I'm not yet sure the best 
>> way / whether it will be possible to represent the relationships in the 
>> Resource definition. Would love to chat if you have any ideas!
>>
>>
>>
>> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote:
>>>
>>> Hi John, 
>>>
>>> The project you linked to looks great. 
>>> How do you deal with references? (entities referencing other entities)  
>>>
>>>
>>>
>>> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly  wrote:
>>>
 I'm sorry to link drop, but I've been doing a bit of work on a library 
 to remove some of the boilerplate when writing client code for a REST API. 
 The library is currently locked in / specific to what is called PostgREST, 
 but I imagine that the patterns could be applied to any REST backend. 
 Check 
 it out: https://github.com/john-kelly/elm-postgrest/

 The core idea is to remove the boilerplate of always having to define 
 encoder, decoder and schema. Would love to chat.

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

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

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

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

[Nick H]

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

On Sun, Oct 23, 2016 at 11:57 AM, Brian Marick 
wrote:

>
> On Oct 22, 2016, at 7:56 PM, Nick H  wrote:
>
> Which of these elements can fire events? Is the text at the bottom the
> only place where the user can interact?
>
> If so, then the graphical elements up top can just be functions that take
> whatever data is needed to draw them.
>
>
>
> All of them. The two graphical events are animated using
> elm-style-animation, and some of the animated effects generate `Cmd Msg`.
> For example, if the bag runs out of fluid, it generates a message that will
> cause the droplets to stop falling.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[elm-discuss] Re: Pre-requisites for learning Elm?

[OvermindDL1]

Elm is definitely a front-end language for javascript so it does assume at 
least a little prior experience, at least with html/css and how they work 
if not javascript (depending on what you need to do).  The class does not 
have those pre-requisites first?  Is it Elm specific or just a generic 
functional language of which you could pick another?


On Sunday, October 23, 2016 at 3:22:22 PM UTC-6, Razi Syed wrote:
>
> Hi everyone, I've never programmed before and in my first year course 
> we're doing Elm. The prof expects us to learn Elm on our own, and simply 
> does examples in class applying what he thinks we should have learned. 
> Problem is, I'm totally lost. Some people are telling me you're supposed to 
> know HTML and CSS before Elm. Even the official elm guide seems like it 
> assumes you know HTML and CSS and javascript (note: I simply know the names 
> of these languages and nothing about them), or have programmed in a 
> non-functional programming.
>

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

[Mickey Vashchinsky]

What course is it?

On Monday, October 24, 2016 at 12:22:22 AM UTC+3, Razi Syed wrote:
>
> Hi everyone, I've never programmed before and in my first year course 
> we're doing Elm. The prof expects us to learn Elm on our own, and simply 
> does examples in class applying what he thinks we should have learned. 
> Problem is, I'm totally lost. Some people are telling me you're supposed to 
> know HTML and CSS before Elm. Even the official elm guide seems like it 
> assumes you know HTML and CSS and javascript (note: I simply know the names 
> of these languages and nothing about them), or have programmed in a 
> non-functional programming.
>

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

[Razi Syed]

Hi everyone, I've never programmed before and in my first year course we're 
doing Elm. The prof expects us to learn Elm on our own, and simply does 
examples in class applying what he thinks we should have learned. Problem 
is, I'm totally lost. Some people are telling me you're supposed to know 
HTML and CSS before Elm. Even the official elm guide seems like it assumes 
you know HTML and CSS and javascript (note: I simply know the names of 
these languages and nothing about them), or have programmed in a 
non-functional programming.

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

[Mickey Vashchinsky]

You might find https://github.com/debois/elm-mdl interesting.


On Wednesday, October 12, 2016 at 12:17:04 AM UTC+3, Casper Bollen wrote:
>
> I would love to use ELM as my client side language. However, a show 
> stopper at the moment is the lack of a decent ELM GUI component library. 
>
> Currently I am using webix  an extremely simple to use 
> library to create a complex one page application. I think it would be a 
> great boost to the ELM usage if a library like that would be natively 
> available. I also, tried to lure 
>  the webix 
> developers into looking at ELM.
>
> If you, from ELM were to cooperate in implementing a sort of 'ELM webix' 
> with the webix developers, this could be a very interesting project. I 
> personally don't have the time and the skill to do this.
>
> Just fishing here;-)
>
> P.s. To get a gist of the kind of application I am working on see: 
> http://github.com/halcwb/GenPDMS.git. Look at the latest commits in the 
> client folder.
>

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

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

[Mark Hamburg]

You may want to think in terms of "shared" data — e.g., the time or the
fluid level — and "private" data — e.g., the animation data — and possibly
some additional configuration data that doesn't change. Then you end up
with type signatures like the following:

view : Config -> SharedData -> PrivateData -> Html Msg

update : Config -> Msg -> SharedData -> PrivateData -> (SharedData,
PrivateData, Cmd Msg)


And feel free to drop parameters or results that aren't needed since type
checking will catch things if you later change your mind.

Mark

On Sun, Oct 23, 2016 at 11:57 AM, Brian Marick 
wrote:

>
> On Oct 22, 2016, at 7:56 PM, Nick H  wrote:
>
> Which of these elements can fire events? Is the text at the bottom the
> only place where the user can interact?
>
> If so, then the graphical elements up top can just be functions that take
> whatever data is needed to draw them.
>
>
>
> All of them. The two graphical events are animated using
> elm-style-animation, and some of the animated effects generate `Cmd Msg`.
> For example, if the bag runs out of fluid, it generates a message that will
> cause the droplets to stop falling.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: More on external "components"

[Mark Hamburg]

The project in question was Elm 0.16 based and we've moved on to other work
so the details need some translation (which I will attempt to handle here),
but the net was that it worked reasonably well with some caveats and hacks.

The first problem is getting Dropzone.js to attach its logic to the node.
If Dropzone supports web components, it sounds like people are having
reasonably good luck with those. Otherwise, you need a way to watch for
node creation. We'd seen warnings about performance problems regarding the
hook points one would expect to use regarding DOM elements and so used the
relatively twisted alternative of using a very fast CSS animation and
watching for the end of the animation. However, you go about it, you make a
div and write a small JavaScript hook to attach the Dropzone handling to it.

The second thing to watch out for is lifetime management. This matters both
from the standpoint of keeping the node alive and generating new nodes if
you need a different target for the dropzone. I posted at greater length
about that here recently, but the basic rule is that you want to use
Html.Keyed and you may want to use it all the way up your view tree for any
places where positional equivalence won't be sufficient. You need to guide
the virtual DOM diff logic so that it knows what it should consider as
being the "same" DOM element and what it should consider to be a different
DOM element.

The last thing is managing how the element communicates back. It may be
able to do so via DOM events but in the case of Dropzone at least, it was
easier to plug in to its callbacks and have those post messages to an Elm
port to which the app could then subscribe.

We haven't used any other significant JS components at this point, but I
would expect the same points would apply there as well.

Mark

On Fri, Oct 21, 2016 at 4:07 PM,  wrote:

> Hi Mark,
> We're looking at possibly starting our first Elm project.
> Our app would in the first phase rely heavily on a robust multi-file
> (images) uploader such as DropZone.js
>
> Over time we would need other sophisticated js libs such as Quill.js
>
> Do you have time to share your experience or suggestions with me?
>
> I'm at a tough point where I have to decide go or no go for Elm on this
> project.
>
> thanks, Jon
>
> On Tuesday, March 29, 2016 at 12:37:58 PM UTC+13, Mark Hamburg wrote:
>>
>> A teammate and I have been working on integrating Dropzone.js into our
>> Elm page and while we've got it working — including updating to different
>> URLs for posting as the context changes in the model — the implementation
>> isn't exactly pretty. We ended up dependent on sending our JavaScript code
>> a tickle event via a port. This seems likely to either be noisy or to miss
>> things and if Elm were ever to decide to be somewhat lazy about rendering
>> and diffing HTML — e.g., only doing so if there are no pending actions —
>> then this could suffer from timing problems wherein the tick driven
>> JavaScript runs ahead of the actual tree update. There have been a number
>> of proposals that have floated past but they tend to feel complicated.
>> Having just gone through this, I'm trying to think through what the
>> simplest, reasonably general purpose boundary is that could be more robust
>> than just using tick to send data on a delay.
>>
>> What it feels like we need is a way to create a virtual DOM node type
>> that would create a div and invoke appropriate JavaScript code on it in
>> conjunction with doing the DOM update. Nodes that aren't leaves on the Elm
>> side or going to make the JavaScript side logic a lot more complex, so
>> let's focus on Elm leaves — i.e., nodes with no Elm-managed nodes
>> underneath them. There are three things that happen during updates to leaf
>> nodes. They get created, they get updated, and they get deleted from the
>> DOM.
>>
>> So, the code to run the Elm app could take a JavaScript function with the
>> signature: function( extensionClassName, eventName, divElement ) This
>> would receive a "class" name specified in Elm — possibly just the standard
>> HTML classname — an event name out of the following set:
>> "willInsertElement", "didUpdateElement", and "didDeleteElement", and the
>> div element. The hook code can then create or update the children within
>> this div node. Other actions like changing the attributes of the div node
>> or adding, removing, or moving it within the tree should be disallowed.
>> Note that I tried to set these events up so that run before the node is in
>> the tree or after it's been removed from insert and delete and the update
>> event comes after the node has been updated so that it only sees new
>> values. These seemed like the most "useful" choices but others may differ.
>>
>> In the case of Dropzone, I would have used these hooks as follows:
>>
>> willInsertElement: Create a child div that gets handed to the Dropzone
>> setup code and for which we track the upload target URL.

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

[Brian Marick]

> On Oct 22, 2016, at 7:56 PM, Nick H  wrote:
> 
> Which of these elements can fire events? Is the text at the bottom the only 
> place where the user can interact?
> 
> If so, then the graphical elements up top can just be functions that take 
> whatever data is needed to draw them.


All of them. The two graphical events are animated using elm-style-animation, 
and some of the animated effects generate `Cmd Msg`. For example, if the bag 
runs out of fluid, it generates a message that will cause the droplets to stop 
falling.

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

Re: [elm-discuss] Re: Inter-Component Communication in 0.17

[Erik Lott]

If you need to communicate between 2 or more enclosed pieces of 
functionality/modules, you'll need to orchestrate that communication via their 
parent.

Like I said, I regret posting the original solution that I did, since it was 
essentially circumventing the elm language. You should try to stay within elm 
as much as possible, unless you're truly missing a piece of functionally, such 
as working with files, etc.

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

[Zane Hitchcox]

Would there be any interest/way to just take over the dom rather than use
diffing? Like, could we just control the screen directly using WebGL and
eliminate the dom completely?

I feel like this would be easy using Three.js, but no one has done it...am
I missing something here?

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

[elm-discuss] Re: IntelliJ (WebStorm) devs, how do you read the compiler errors?

[Carlos Poon]

@Birowsky - thanks for those keyboard shortcuts ! very useful.
I'm not sure about Elm 0.17.1 but future versions may use elm-make with 
--debug, which you can add to your build script, i guess.

I have setup a nice way of building any current .elm file in Webstorm, 
using File Watcher dialog, which builds on save (also have one for 
elm-format).  Note: I'm using elm as a node_module inside an Electron 
project to view the elm app, so other parts of my setup may differ to 
yours. 



In regards to your original question, can you share a small example script, 
with which people can test, also an example of the compiler messages that 
you expect to see, thanks.  I'm new, but willing to help, where possible 
with Webstorm (it is a great ide with a large userbase).  will check back 
tomorrow.

On Sunday, October 23, 2016 at 11:14:50 AM UTC+1, Birowsky wrote:
>
> The Elm plugin, together with a shortcut for elm-format is an amazing 
> experience on an Intellij platform (i'm on WebStorm). The auto imports, the 
> way I'm able to navigate around code with 
>
> cmd + click
> cmd + [
> cmd + ]
>
> is the best thing you can have from an IDE.
>
>  
> I'm missing on another best thing tho, the compiler error messages.
>
> Intellij hilights the synthax errors, but it doesn't know about the types 
> it seems. So the compiler messages are kind of required there. 
>
> How do you efficiently check them out?
>

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

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

[John Orford]

For the record I loved using primes for the first time in Haskell - it gave
me the feeling of doing maths again, but while programming : )

I agree with your '_' point. Perhaps it should also be nixed following your
line of logic... But I love my underscore and forget variables also : /

On Sun, 23 Oct 2016 at 17:57 Bob Hutchison  wrote:

> On Oct 19, 2016, at 2:59 AM, John Orford  wrote:
>
> I am coming around to the make things as easy as possible for newbs
> approach.
>
> Elm is a big jump for people coming from JS, every little helps, including
> removing string syntax misinterpretations.
>
> Having said that, I suspect a total programming newcomer would find Elm
> right now easier than JS…
>
>
>
> I’ve got no problems catering to newbs either, as long as nobody forgets
> there’s non-newbs using elm too. The suggestion that model’ is less clear
> than model_ is ludicrous. Further I’d say that the set of newbs coming from
> JS who are able to get past functional programming, infix functions, types,
> and immutable data and then get confused by model' is empty. The arguments
> that there usually clearer ways of doing things other than using a prime is
> undisputedly often true, but sometimes the prime is the best way to convey
> meaning to the reader. Anecdotally, when I was first learning Haskell I
> found the prime distinctly clearer to not having it when I learned erlang
> (but, then, I absolutely was not a newb coming from JS). When showing
> Haskell to (very skilled) C and C++ programmers, using a prime when showing
> how to deal with immutability, results in an “Ah! Okay.” not confusion. And
> I *often* (as in always) use them when first writing a function because I
> don’t necessarily know how to name them better at the time, then fix the
> naming later when cleaning up. If you think primes can be abused, wait 'til
> you see what newbs come up with on their own to ’solve’ the problem. And
> yes, backticks are another thing for the newb to learn to not abuse, but
> sometimes they solve a syntactic problem very nicely.
>
> Of course this is now a done deal so my whining about catering to
> non-existent newbs is pointless.
>
>
> On Wed, 19 Oct 2016 at 08:39 Martin DeMello 
> wrote:
>
> Agreed; I'll definitely miss being able to use primes in variable names!
>
> martin
>
> On Tue, Oct 18, 2016 at 6:28 PM, mbr  wrote:
>
> just learned that primes and backticks won't be on elm 0.18.
>
> What are the reason for their removal?
>
> I will miss the primes quite a bit. Am I the only one here that feels this
> way ?
>
> For instance, I would have to write headerModel___ and headerModel__
> instead of headerModel''' and headerModel''
> In the prime case I count the 'while on the underscore case I will
> compare its length.
>
> at the end of the day, I will just skip the underscore and use number like
> headerModel03 and headerModel02.
>
> And my case for backticks, I understand it will make the andThen API
> easier, but why completely remove it from the language ?
>
> I guess my main question is, What is the motivation for their removal ?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Inter-Component Communication in 0.17

[António Ramos]

Were does this all stand?
can anyone post an example that all agree to understand the best way to
Inter-Component Communication in 0.17 ?!

2016-10-22 18:26 GMT+01:00 Erik Lott :

> You're such a jerk Richard :)
>
>
> On Saturday, October 22, 2016 at 1:21:44 PM UTC-4, Richard Feldman wrote:
>>
>> Oh man, now I feel like a total jerk for my harsh tone.
>>
>> My apologies, and thank you for the update Erik! <3
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Bob Hutchison]

> On Oct 19, 2016, at 2:59 AM, John Orford  wrote:
> 
> I am coming around to the make things as easy as possible for newbs approach.
> 
> Elm is a big jump for people coming from JS, every little helps, including 
> removing string syntax misinterpretations.
> 
> Having said that, I suspect a total programming newcomer would find Elm right 
> now easier than JS… 


I’ve got no problems catering to newbs either, as long as nobody forgets 
there’s non-newbs using elm too. The suggestion that model’ is less clear than 
model_ is ludicrous. Further I’d say that the set of newbs coming from JS who 
are able to get past functional programming, infix functions, types, and 
immutable data and then get confused by model' is empty. The arguments that 
there usually clearer ways of doing things other than using a prime is 
undisputedly often true, but sometimes the prime is the best way to convey 
meaning to the reader. Anecdotally, when I was first learning Haskell I found 
the prime distinctly clearer to not having it when I learned erlang (but, then, 
I absolutely was not a newb coming from JS). When showing Haskell to (very 
skilled) C and C++ programmers, using a prime when showing how to deal with 
immutability, results in an “Ah! Okay.” not confusion. And I *often* (as in 
always) use them when first writing a function because I don’t necessarily know 
how to name them better at the time, then fix the naming later when cleaning 
up. If you think primes can be abused, wait 'til you see what newbs come up 
with on their own to ’solve’ the problem. And yes, backticks are another thing 
for the newb to learn to not abuse, but sometimes they solve a syntactic 
problem very nicely.

Of course this is now a done deal so my whining about catering to non-existent 
newbs is pointless.

> 
> On Wed, 19 Oct 2016 at 08:39 Martin DeMello  > wrote:
> Agreed; I'll definitely miss being able to use primes in variable names!
> 
> martin
> 
> On Tue, Oct 18, 2016 at 6:28 PM, mbr  > wrote:
> just learned that primes and backticks won't be on elm 0.18.
> 
> What are the reason for their removal? 
> 
> I will miss the primes quite a bit. Am I the only one here that feels this 
> way ?
> 
> For instance, I would have to write headerModel___ and headerModel__ instead 
> of headerModel''' and headerModel''
> In the prime case I count the 'while on the underscore case I will compare 
> its length.
> 
> at the end of the day, I will just skip the underscore and use number like 
> headerModel03 and headerModel02.
> 
> And my case for backticks, I understand it will make the andThen API easier, 
> but why completely remove it from the language ?
> 
> I guess my main question is, What is the motivation for their removal ?
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and 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: Proposal: Rename case..of -> match..with

[joseph ni]

> The reason being that I believe the words better matches what the 
construct does.

To me, `case x of` conveys *what* the construct does. It says, handle all 
the different cases/scenarios/possibilities of `x` as follows. Ties in 
nicely with the compiler msg: "You haven't handled these cases of this 
type".

`match x with` conveys *how* it does it. I'm going to match `x` with some 
destructured patterns below but it says nothing about what those patterns 
are so we are losing the intention of the construct imo.

In some crude sense, it would be like renaming `List.map` to 
`List.turnAintoB`. The former is more about intention, the latter about 
implementation.


On Friday, 21 October 2016 01:06:53 UTC+11, Robin Heggelund Hansen wrote:
>
> First of, I would like to say that for me personally, this proposal 
> doesn't matter.
> This proposal is written because I believe people with little to no Elm 
> experience will understand the construct better.
>
> The proposal, as the title of the post suggests, is to rename the 
> "case..of" expression to "match..with". The reason being that I believe the 
> words better matches what the construct does. As a non-native English 
> speaker, case..of doesn't immediately make sense. However, match..with 
> makes perfect sense.
>
> Match..with is what the same construct is called in F#, so it has that 
> going for it.
>
> Case..of to match..with renaming could be handled by elm-format.
>
> As said, to me personally and, I believe, other seasoned elm devs, this 
> won't matter that much.
> The question therefore becomes, how big of a difference will it make to 
> new and future elm developers?
>

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