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 <falling...@gmail.com
> <javascript:>> 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 <jdrke...@gmail.com
>> <javascript:>> 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 <jdrke...@gmail.com>
>>>>>> 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...@googlegroups.com <javascript:>.
>>> 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 <falling...@gmail.com
> <javascript:>> 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 <jdrke...@gmail.com
>> <javascript:>> 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 <jdrke...@gmail.com>
>>>>>> 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...@googlegroups.com <javascript:>.
>>> 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 <falling...@gmail.com
> <javascript:>> 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 <jdrke...@gmail.com
>> <javascript:>> 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 <jdrke...@gmail.com>
>>>>>> 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...@googlegroups.com <javascript:>.
>>> 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 <falling...@gmail.com
> <javascript:>> 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 <jdrke...@gmail.com
>> <javascript:>> 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 <jdrke...@gmail.com>
>>>>>> 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...@googlegroups.com <javascript:>.
>>> 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 <falling...@gmail.com
> <javascript:>> 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 <jdrke...@gmail.com
>> <javascript:>> 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 <jdrke...@gmail.com>
>>>>>> 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...@googlegroups.com <javascript:>.
>>> 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 <falling...@gmail.com
> <javascript:>> 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 <jdrke...@gmail.com
>> <javascript:>> 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 <jdrke...@gmail.com>
>>>>>> 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...@googlegroups.com <javascript:>.
>>> 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.
