> > 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 <[email protected]> wrote: > To my knowledge, the recursive type that you specified *will* compile. > See here > <https://github.com/elm-lang/elm-compiler/blob/master/hints/recursive-alias.md#mutually-recursive-type-aliases> > . > > My issue is in fact related to mutually recursive types, it's just that my > types are truly infinite. According to the linked doc about recursive types: > "Somewhere in that cycle, you need to define an actual type to end the > infinite expansion." Which mine does not. > > And to address your comment in regards to: "But still, I think you might > be able to salvage the API if you wrap the records in union type > constructors." This is the idea I will be exploring next, thank you for the > recommendation. > > > > On Sunday, October 23, 2016 at 6:19:38 PM UTC-7, Nick H wrote: >> >> I guess you weren't explicitly defining type aliases for those records. >> But still, I think you might be able to salvage the API if you wrap the >> records in union type constructors. >> >> On Sun, Oct 23, 2016 at 6:10 PM, Nick H <[email protected]> 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 <[email protected]> wrote: >>> >>>> I'm coming to the sad realization that an api like this is simply not >>>> possible: >>>> >>>> ``` >>>> session = >>>> resource "sessions" >>>> { id = int "id" >>>> , speaker_id = int "speaker_id" >>>> , start_time = string "start_time" >>>> , end_time = string "end_time" >>>> , location = string "location" >>>> , session_type = int "session_type" >>>> , speaker = hasOne (\_ -> speaker) >>>> } >>>> >>>> >>>> speaker = >>>> resource "speakers" >>>> { id = int "id" >>>> , name = string "name" >>>> , sessions = hasMany (\_ -> session) >>>> } >>>> ``` >>>> >>>> Any ideas? I was under the impression that the lambda would fix the >>>> recursive type issue, but now i see that elm still has trouble with the >>>> type of the record. >>>> >>>> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote: >>>>> >>>>> Just to follow up on the limitations in my library I spoke about -- >>>>> namely, not being able to represent the relationships *in *the >>>>> resource definition. I spent a bit of time drafting up some potential api >>>>> changes that would make it possible: here >>>>> <https://gist.github.com/john-kelly/8ac5aa5d5e38bd148b70e10b0c44408c> >>>>> . >>>>> >>>>> Handling the recursive nature of relationships was influenced by >>>>> Json.Decode.Extra.lazy >>>>> <http://package.elm-lang.org/packages/circuithub/elm-json-extra/latest/Json-Decode-Extra#lazy> >>>>> >>>>> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote: >>>>>> >>>>>> Great Question! >>>>>> >>>>>> You can checkout an example here >>>>>> <https://gist.github.com/john-kelly/00424de66be03d9bbb07795b11c39a48>. >>>>>> It builds off of the example presented in the docs. >>>>>> >>>>>> Currently, the library does not support representing relationships in >>>>>> the Resource definition, however, the library *does *support >>>>>> representing the relationships in the queries (see example). I'm not yet >>>>>> sure the best way / whether it will be possible to represent the >>>>>> relationships in the Resource definition. Would love to chat if you have >>>>>> any ideas! >>>>>> >>>>>> >>>>>> >>>>>> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote: >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> The project you linked to looks great. >>>>>>> How do you deal with references? (entities referencing other >>>>>>> entities) >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly <[email protected]> >>>>>>> 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 [email protected]. >>>>>>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> > 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> I'm coming to the sad realization that an api like this is simply not >>>> possible: >>>> >>>> ``` >>>> session = >>>> resource "sessions" >>>> { id = int "id" >>>> , speaker_id = int "speaker_id" >>>> , start_time = string "start_time" >>>> , end_time = string "end_time" >>>> , location = string "location" >>>> , session_type = int "session_type" >>>> , speaker = hasOne (\_ -> speaker) >>>> } >>>> >>>> >>>> speaker = >>>> resource "speakers" >>>> { id = int "id" >>>> , name = string "name" >>>> , sessions = hasMany (\_ -> session) >>>> } >>>> ``` >>>> >>>> Any ideas? I was under the impression that the lambda would fix the >>>> recursive type issue, but now i see that elm still has trouble with the >>>> type of the record. >>>> >>>> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote: >>>>> >>>>> Just to follow up on the limitations in my library I spoke about -- >>>>> namely, not being able to represent the relationships *in *the >>>>> resource definition. I spent a bit of time drafting up some potential api >>>>> changes that would make it possible: here >>>>> <https://gist.github.com/john-kelly/8ac5aa5d5e38bd148b70e10b0c44408c> >>>>> . >>>>> >>>>> Handling the recursive nature of relationships was influenced by >>>>> Json.Decode.Extra.lazy >>>>> <http://package.elm-lang.org/packages/circuithub/elm-json-extra/latest/Json-Decode-Extra#lazy> >>>>> >>>>> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote: >>>>>> >>>>>> Great Question! >>>>>> >>>>>> You can checkout an example here >>>>>> <https://gist.github.com/john-kelly/00424de66be03d9bbb07795b11c39a48>. >>>>>> It builds off of the example presented in the docs. >>>>>> >>>>>> Currently, the library does not support representing relationships in >>>>>> the Resource definition, however, the library *does *support >>>>>> representing the relationships in the queries (see example). I'm not yet >>>>>> sure the best way / whether it will be possible to represent the >>>>>> relationships in the Resource definition. Would love to chat if you have >>>>>> any ideas! >>>>>> >>>>>> >>>>>> >>>>>> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote: >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> The project you linked to looks great. >>>>>>> How do you deal with references? (entities referencing other >>>>>>> entities) >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly <[email protected]> >>>>>>> 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 [email protected]. >>>>>>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> > 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> I'm coming to the sad realization that an api like this is simply not >>>> possible: >>>> >>>> ``` >>>> session = >>>> resource "sessions" >>>> { id = int "id" >>>> , speaker_id = int "speaker_id" >>>> , start_time = string "start_time" >>>> , end_time = string "end_time" >>>> , location = string "location" >>>> , session_type = int "session_type" >>>> , speaker = hasOne (\_ -> speaker) >>>> } >>>> >>>> >>>> speaker = >>>> resource "speakers" >>>> { id = int "id" >>>> , name = string "name" >>>> , sessions = hasMany (\_ -> session) >>>> } >>>> ``` >>>> >>>> Any ideas? I was under the impression that the lambda would fix the >>>> recursive type issue, but now i see that elm still has trouble with the >>>> type of the record. >>>> >>>> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote: >>>>> >>>>> Just to follow up on the limitations in my library I spoke about -- >>>>> namely, not being able to represent the relationships *in *the >>>>> resource definition. I spent a bit of time drafting up some potential api >>>>> changes that would make it possible: here >>>>> <https://gist.github.com/john-kelly/8ac5aa5d5e38bd148b70e10b0c44408c> >>>>> . >>>>> >>>>> Handling the recursive nature of relationships was influenced by >>>>> Json.Decode.Extra.lazy >>>>> <http://package.elm-lang.org/packages/circuithub/elm-json-extra/latest/Json-Decode-Extra#lazy> >>>>> >>>>> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote: >>>>>> >>>>>> Great Question! >>>>>> >>>>>> You can checkout an example here >>>>>> <https://gist.github.com/john-kelly/00424de66be03d9bbb07795b11c39a48>. >>>>>> It builds off of the example presented in the docs. >>>>>> >>>>>> Currently, the library does not support representing relationships in >>>>>> the Resource definition, however, the library *does *support >>>>>> representing the relationships in the queries (see example). I'm not yet >>>>>> sure the best way / whether it will be possible to represent the >>>>>> relationships in the Resource definition. Would love to chat if you have >>>>>> any ideas! >>>>>> >>>>>> >>>>>> >>>>>> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote: >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> The project you linked to looks great. >>>>>>> How do you deal with references? (entities referencing other >>>>>>> entities) >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly <[email protected]> >>>>>>> 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 [email protected]. >>>>>>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> > 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> I'm coming to the sad realization that an api like this is simply not >>>> possible: >>>> >>>> ``` >>>> session = >>>> resource "sessions" >>>> { id = int "id" >>>> , speaker_id = int "speaker_id" >>>> , start_time = string "start_time" >>>> , end_time = string "end_time" >>>> , location = string "location" >>>> , session_type = int "session_type" >>>> , speaker = hasOne (\_ -> speaker) >>>> } >>>> >>>> >>>> speaker = >>>> resource "speakers" >>>> { id = int "id" >>>> , name = string "name" >>>> , sessions = hasMany (\_ -> session) >>>> } >>>> ``` >>>> >>>> Any ideas? I was under the impression that the lambda would fix the >>>> recursive type issue, but now i see that elm still has trouble with the >>>> type of the record. >>>> >>>> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote: >>>>> >>>>> Just to follow up on the limitations in my library I spoke about -- >>>>> namely, not being able to represent the relationships *in *the >>>>> resource definition. I spent a bit of time drafting up some potential api >>>>> changes that would make it possible: here >>>>> <https://gist.github.com/john-kelly/8ac5aa5d5e38bd148b70e10b0c44408c> >>>>> . >>>>> >>>>> Handling the recursive nature of relationships was influenced by >>>>> Json.Decode.Extra.lazy >>>>> <http://package.elm-lang.org/packages/circuithub/elm-json-extra/latest/Json-Decode-Extra#lazy> >>>>> >>>>> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote: >>>>>> >>>>>> Great Question! >>>>>> >>>>>> You can checkout an example here >>>>>> <https://gist.github.com/john-kelly/00424de66be03d9bbb07795b11c39a48>. >>>>>> It builds off of the example presented in the docs. >>>>>> >>>>>> Currently, the library does not support representing relationships in >>>>>> the Resource definition, however, the library *does *support >>>>>> representing the relationships in the queries (see example). I'm not yet >>>>>> sure the best way / whether it will be possible to represent the >>>>>> relationships in the Resource definition. Would love to chat if you have >>>>>> any ideas! >>>>>> >>>>>> >>>>>> >>>>>> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote: >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> The project you linked to looks great. >>>>>>> How do you deal with references? (entities referencing other >>>>>>> entities) >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly <[email protected]> >>>>>>> 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 [email protected]. >>>>>>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> > 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> I'm coming to the sad realization that an api like this is simply not >>>> possible: >>>> >>>> ``` >>>> session = >>>> resource "sessions" >>>> { id = int "id" >>>> , speaker_id = int "speaker_id" >>>> , start_time = string "start_time" >>>> , end_time = string "end_time" >>>> , location = string "location" >>>> , session_type = int "session_type" >>>> , speaker = hasOne (\_ -> speaker) >>>> } >>>> >>>> >>>> speaker = >>>> resource "speakers" >>>> { id = int "id" >>>> , name = string "name" >>>> , sessions = hasMany (\_ -> session) >>>> } >>>> ``` >>>> >>>> Any ideas? I was under the impression that the lambda would fix the >>>> recursive type issue, but now i see that elm still has trouble with the >>>> type of the record. >>>> >>>> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote: >>>>> >>>>> Just to follow up on the limitations in my library I spoke about -- >>>>> namely, not being able to represent the relationships *in *the >>>>> resource definition. I spent a bit of time drafting up some potential api >>>>> changes that would make it possible: here >>>>> <https://gist.github.com/john-kelly/8ac5aa5d5e38bd148b70e10b0c44408c> >>>>> . >>>>> >>>>> Handling the recursive nature of relationships was influenced by >>>>> Json.Decode.Extra.lazy >>>>> <http://package.elm-lang.org/packages/circuithub/elm-json-extra/latest/Json-Decode-Extra#lazy> >>>>> >>>>> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote: >>>>>> >>>>>> Great Question! >>>>>> >>>>>> You can checkout an example here >>>>>> <https://gist.github.com/john-kelly/00424de66be03d9bbb07795b11c39a48>. >>>>>> It builds off of the example presented in the docs. >>>>>> >>>>>> Currently, the library does not support representing relationships in >>>>>> the Resource definition, however, the library *does *support >>>>>> representing the relationships in the queries (see example). I'm not yet >>>>>> sure the best way / whether it will be possible to represent the >>>>>> relationships in the Resource definition. Would love to chat if you have >>>>>> any ideas! >>>>>> >>>>>> >>>>>> >>>>>> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote: >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> The project you linked to looks great. >>>>>>> How do you deal with references? (entities referencing other >>>>>>> entities) >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly <[email protected]> >>>>>>> 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 [email protected]. >>>>>>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> > 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> I'm coming to the sad realization that an api like this is simply not >>>> possible: >>>> >>>> ``` >>>> session = >>>> resource "sessions" >>>> { id = int "id" >>>> , speaker_id = int "speaker_id" >>>> , start_time = string "start_time" >>>> , end_time = string "end_time" >>>> , location = string "location" >>>> , session_type = int "session_type" >>>> , speaker = hasOne (\_ -> speaker) >>>> } >>>> >>>> >>>> speaker = >>>> resource "speakers" >>>> { id = int "id" >>>> , name = string "name" >>>> , sessions = hasMany (\_ -> session) >>>> } >>>> ``` >>>> >>>> Any ideas? I was under the impression that the lambda would fix the >>>> recursive type issue, but now i see that elm still has trouble with the >>>> type of the record. >>>> >>>> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote: >>>>> >>>>> Just to follow up on the limitations in my library I spoke about -- >>>>> namely, not being able to represent the relationships *in *the >>>>> resource definition. I spent a bit of time drafting up some potential api >>>>> changes that would make it possible: here >>>>> <https://gist.github.com/john-kelly/8ac5aa5d5e38bd148b70e10b0c44408c> >>>>> . >>>>> >>>>> Handling the recursive nature of relationships was influenced by >>>>> Json.Decode.Extra.lazy >>>>> <http://package.elm-lang.org/packages/circuithub/elm-json-extra/latest/Json-Decode-Extra#lazy> >>>>> >>>>> On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote: >>>>>> >>>>>> Great Question! >>>>>> >>>>>> You can checkout an example here >>>>>> <https://gist.github.com/john-kelly/00424de66be03d9bbb07795b11c39a48>. >>>>>> It builds off of the example presented in the docs. >>>>>> >>>>>> Currently, the library does not support representing relationships in >>>>>> the Resource definition, however, the library *does *support >>>>>> representing the relationships in the queries (see example). I'm not yet >>>>>> sure the best way / whether it will be possible to represent the >>>>>> relationships in the Resource definition. Would love to chat if you have >>>>>> any ideas! >>>>>> >>>>>> >>>>>> >>>>>> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote: >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> The project you linked to looks great. >>>>>>> How do you deal with references? (entities referencing other >>>>>>> entities) >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly <[email protected]> >>>>>>> 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 [email protected]. >>>>>>>> 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 [email protected]. >>>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
