Re: [racket-dev] Implementing contracts for async channels
As an update, I’ve made a bit more progress on this. I’ve implemented an impersonate-async-channel function, and I’ve actually included this in the exports from racket/contract. I also realized the blame information is correct, it works fine. Most of the other issues remain, as well as a few new questions: There is no impersonate-evt function, so I’m not sure that my implementation will work. What should I do about this? I’d assume this needs to be documented/tested as well. Where should those things be located? On Jan 14, 2015, at 23:44, Alexis King lexi.lam...@gmail.com wrote: Currently, async channels do not have contracts to check their contents. This is a problem for Typed Racket, and it prevents typed code from interacting with code that produces async channels. I started looking into how to add contracts to the language, and it seems to use the chaperones/impersonator system, as I suspected. However, async channels obviously cannot be impersonated, so I needed to implement that as well. I modified the async-channel struct to use generics to allow it to be impersonated or chaperoned, which I have exposed by implementing chaperone-async-channel. I then tried implementing async-channel/c. The internals of the contract system are a little beyond me, but I got a working solution by following the example of the box contracts. My work thus far can be found here: https://github.com/lexi-lambda/racket/commit/84b9f3604891f3f2061fb28ed4800af8afa4751b https://github.com/lexi-lambda/racket/commit/84b9f3604891f3f2061fb28ed4800af8afa4751b First of all, is this a correct approach? Have I done anything wrong, or should I have done anything differently? I didn’t find much documentation on the internals of either of these systems, so I mostly went about things as I found them. Second, obviously, not everything is implemented here. Among the additional necessary changes are: I need to implement support for impersonators and impersonator contracts (right now I’ve only bothered to do chaperones). I need to implement async-channel/c-first-order and async-channel/c-stronger. I can probably figure out the latter, but I’m not even sure what the former is supposed to do. I need to implement a wrap-async-channel/c macro for the export. I’m not sure how this works, either. From looking at wrap-box/c, it seems to add some syntax properties, but I’m not sure what they do or how they work. Somehow, the blame information has to be correct. Is that what the wrap function does? Or do the async-channel functions need to be updated to assign blame? I’d really like to get this working, and I think I’m close, but I’m a little inexperienced. I’d appreciate any help, even if it’s just pointing me in the right direction. Thanks! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Implementing contracts for async channels
Sorry, I wasn’t clear. The chaperone/impersonate-async-channel functions are exported from racket/async-channel. The async-channel contracts, however, are exported from racket/contract. On Jan 15, 2015, at 14:41, Robby Findler ro...@eecs.northwestern.edu wrote: Just a small nit: why export that function from racket/contract and not an async-channel library? Robby On Thu, Jan 15, 2015 at 3:33 PM, Alexis King lexi.lam...@gmail.com wrote: As an update, I’ve made a bit more progress on this. I’ve implemented an impersonate-async-channel function, and I’ve actually included this in the exports from racket/contract. I also realized the blame information is correct, it works fine. Most of the other issues remain, as well as a few new questions: There is no impersonate-evt function, so I’m not sure that my implementation will work. What should I do about this? I’d assume this needs to be documented/tested as well. Where should those things be located? On Jan 14, 2015, at 23:44, Alexis King lexi.lam...@gmail.com wrote: Currently, async channels do not have contracts to check their contents. This is a problem for Typed Racket, and it prevents typed code from interacting with code that produces async channels. I started looking into how to add contracts to the language, and it seems to use the chaperones/impersonator system, as I suspected. However, async channels obviously cannot be impersonated, so I needed to implement that as well. I modified the async-channel struct to use generics to allow it to be impersonated or chaperoned, which I have exposed by implementing chaperone-async-channel. I then tried implementing async-channel/c. The internals of the contract system are a little beyond me, but I got a working solution by following the example of the box contracts. My work thus far can be found here: https://github.com/lexi-lambda/racket/commit/84b9f3604891f3f2061fb28ed4800af8afa4751b First of all, is this a correct approach? Have I done anything wrong, or should I have done anything differently? I didn’t find much documentation on the internals of either of these systems, so I mostly went about things as I found them. Second, obviously, not everything is implemented here. Among the additional necessary changes are: I need to implement support for impersonators and impersonator contracts (right now I’ve only bothered to do chaperones). I need to implement async-channel/c-first-order and async-channel/c-stronger. I can probably figure out the latter, but I’m not even sure what the former is supposed to do. I need to implement a wrap-async-channel/c macro for the export. I’m not sure how this works, either. From looking at wrap-box/c, it seems to add some syntax properties, but I’m not sure what they do or how they work. Somehow, the blame information has to be correct. Is that what the wrap function does? Or do the async-channel functions need to be updated to assign blame? I’d really like to get this working, and I think I’m close, but I’m a little inexperienced. I’d appreciate any help, even if it’s just pointing me in the right direction. Thanks! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Implementing contracts for async channels
I think they should probably all be exported from racket/async-channel. Unless there is some reason to modify the internals of racket/contract to support them? Robby On Thu, Jan 15, 2015 at 4:50 PM, Alexis King lexi.lam...@gmail.com wrote: Sorry, I wasn’t clear. The chaperone/impersonate-async-channel functions are exported from racket/async-channel. The async-channel contracts, however, are exported from racket/contract. On Jan 15, 2015, at 14:41, Robby Findler ro...@eecs.northwestern.edu wrote: Just a small nit: why export that function from racket/contract and not an async-channel library? Robby On Thu, Jan 15, 2015 at 3:33 PM, Alexis King lexi.lam...@gmail.com wrote: As an update, I’ve made a bit more progress on this. I’ve implemented an impersonate-async-channel function, and I’ve actually included this in the exports from racket/contract. I also realized the blame information is correct, it works fine. Most of the other issues remain, as well as a few new questions: There is no impersonate-evt function, so I’m not sure that my implementation will work. What should I do about this? I’d assume this needs to be documented/tested as well. Where should those things be located? On Jan 14, 2015, at 23:44, Alexis King lexi.lam...@gmail.com wrote: Currently, async channels do not have contracts to check their contents. This is a problem for Typed Racket, and it prevents typed code from interacting with code that produces async channels. I started looking into how to add contracts to the language, and it seems to use the chaperones/impersonator system, as I suspected. However, async channels obviously cannot be impersonated, so I needed to implement that as well. I modified the async-channel struct to use generics to allow it to be impersonated or chaperoned, which I have exposed by implementing chaperone-async-channel. I then tried implementing async-channel/c. The internals of the contract system are a little beyond me, but I got a working solution by following the example of the box contracts. My work thus far can be found here: https://github.com/lexi-lambda/racket/commit/84b9f3604891f3f2061fb28ed4800af8afa4751b First of all, is this a correct approach? Have I done anything wrong, or should I have done anything differently? I didn’t find much documentation on the internals of either of these systems, so I mostly went about things as I found them. Second, obviously, not everything is implemented here. Among the additional necessary changes are: I need to implement support for impersonators and impersonator contracts (right now I’ve only bothered to do chaperones). I need to implement async-channel/c-first-order and async-channel/c-stronger. I can probably figure out the latter, but I’m not even sure what the former is supposed to do. I need to implement a wrap-async-channel/c macro for the export. I’m not sure how this works, either. From looking at wrap-box/c, it seems to add some syntax properties, but I’m not sure what they do or how they work. Somehow, the blame information has to be correct. Is that what the wrap function does? Or do the async-channel functions need to be updated to assign blame? I’d really like to get this working, and I think I’m close, but I’m a little inexperienced. I’d appreciate any help, even if it’s just pointing me in the right direction. Thanks! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Implementing contracts for async channels
Just a small nit: why export that function from racket/contract and not an async-channel library? Robby On Thu, Jan 15, 2015 at 3:33 PM, Alexis King lexi.lam...@gmail.com wrote: As an update, I’ve made a bit more progress on this. I’ve implemented an impersonate-async-channel function, and I’ve actually included this in the exports from racket/contract. I also realized the blame information is correct, it works fine. Most of the other issues remain, as well as a few new questions: There is no impersonate-evt function, so I’m not sure that my implementation will work. What should I do about this? I’d assume this needs to be documented/tested as well. Where should those things be located? On Jan 14, 2015, at 23:44, Alexis King lexi.lam...@gmail.com wrote: Currently, async channels do not have contracts to check their contents. This is a problem for Typed Racket, and it prevents typed code from interacting with code that produces async channels. I started looking into how to add contracts to the language, and it seems to use the chaperones/impersonator system, as I suspected. However, async channels obviously cannot be impersonated, so I needed to implement that as well. I modified the async-channel struct to use generics to allow it to be impersonated or chaperoned, which I have exposed by implementing chaperone-async-channel. I then tried implementing async-channel/c. The internals of the contract system are a little beyond me, but I got a working solution by following the example of the box contracts. My work thus far can be found here: https://github.com/lexi-lambda/racket/commit/84b9f3604891f3f2061fb28ed4800af8afa4751b First of all, is this a correct approach? Have I done anything wrong, or should I have done anything differently? I didn’t find much documentation on the internals of either of these systems, so I mostly went about things as I found them. Second, obviously, not everything is implemented here. Among the additional necessary changes are: I need to implement support for impersonators and impersonator contracts (right now I’ve only bothered to do chaperones). I need to implement async-channel/c-first-order and async-channel/c-stronger. I can probably figure out the latter, but I’m not even sure what the former is supposed to do. I need to implement a wrap-async-channel/c macro for the export. I’m not sure how this works, either. From looking at wrap-box/c, it seems to add some syntax properties, but I’m not sure what they do or how they work. Somehow, the blame information has to be correct. Is that what the wrap function does? Or do the async-channel functions need to be updated to assign blame? I’d really like to get this working, and I think I’m close, but I’m a little inexperienced. I’d appreciate any help, even if it’s just pointing me in the right direction. Thanks! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Implementing contracts for async channels
On Thu, Jan 15, 2015 at 4:33 PM, Alexis King lexi.lam...@gmail.com wrote: As an update, I’ve made a bit more progress on this. I’ve implemented an impersonate-async-channel function, and I’ve actually included this in the exports from racket/contract. I also realized the blame information is correct, it works fine. Most of the other issues remain, as well as a few new questions: There is no impersonate-evt function, so I’m not sure that my implementation will work. What should I do about this? I’d assume this needs to be documented/tested as well. Where should those things be located? Documentation for contracts is here: https://github.com/plt/racket/blob/master/pkgs/racket-doc/scribblings/reference/contracts.scrbl and in the dependent files. Tests for contracts are here: https://github.com/plt/racket/tree/master/pkgs/racket-test/tests/racket/contract Sam On Jan 14, 2015, at 23:44, Alexis King lexi.lam...@gmail.com wrote: Currently, async channels do not have contracts to check their contents. This is a problem for Typed Racket, and it prevents typed code from interacting with code that produces async channels. I started looking into how to add contracts to the language, and it seems to use the chaperones/impersonator system, as I suspected. However, async channels obviously cannot be impersonated, so I needed to implement that as well. I modified the async-channel struct to use generics to allow it to be impersonated or chaperoned, which I have exposed by implementing chaperone-async-channel. I then tried implementing async-channel/c. The internals of the contract system are a little beyond me, but I got a working solution by following the example of the box contracts. My work thus far can be found here: https://github.com/lexi-lambda/racket/commit/84b9f3604891f3f2061fb28ed4800af8afa4751b First of all, is this a correct approach? Have I done anything wrong, or should I have done anything differently? I didn’t find much documentation on the internals of either of these systems, so I mostly went about things as I found them. Second, obviously, not everything is implemented here. Among the additional necessary changes are: I need to implement support for impersonators and impersonator contracts (right now I’ve only bothered to do chaperones). I need to implement async-channel/c-first-order and async-channel/c-stronger. I can probably figure out the latter, but I’m not even sure what the former is supposed to do. I need to implement a wrap-async-channel/c macro for the export. I’m not sure how this works, either. From looking at wrap-box/c, it seems to add some syntax properties, but I’m not sure what they do or how they work. Somehow, the blame information has to be correct. Is that what the wrap function does? Or do the async-channel functions need to be updated to assign blame? I’d really like to get this working, and I think I’m close, but I’m a little inexperienced. I’d appreciate any help, even if it’s just pointing me in the right direction. Thanks! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Implementing contracts for async channels
Sure thing, done. I’ve moved everything into racket/async-channel, added the missing functions, and added some tests. I squashed my commits into one, and the result is here: https://github.com/lexi-lambda/racket/commit/0074ba13b712a87c9d05948ae075bcd74c7651e7 https://github.com/lexi-lambda/racket/commit/0074ba13b712a87c9d05948ae075bcd74c7651e7 Two simple points remain: Where should the documentation go? Should it be under contracts or async-channels? I’d prefer the latter, but I’m not sure. Since there is no impersonate-evt function, I don’t think my impersonate-async-channel function will actually work. Is that an accurate concern? How could I fix it? Otherwise, I think this works fine and is probably ready to go. On Jan 15, 2015, at 15:09, Robby Findler ro...@eecs.northwestern.edu wrote: I think they should probably all be exported from racket/async-channel. Unless there is some reason to modify the internals of racket/contract to support them? Robby On Thu, Jan 15, 2015 at 4:50 PM, Alexis King lexi.lam...@gmail.com wrote: Sorry, I wasn’t clear. The chaperone/impersonate-async-channel functions are exported from racket/async-channel. The async-channel contracts, however, are exported from racket/contract. On Jan 15, 2015, at 14:41, Robby Findler ro...@eecs.northwestern.edu wrote: Just a small nit: why export that function from racket/contract and not an async-channel library? Robby On Thu, Jan 15, 2015 at 3:33 PM, Alexis King lexi.lam...@gmail.com wrote: As an update, I’ve made a bit more progress on this. I’ve implemented an impersonate-async-channel function, and I’ve actually included this in the exports from racket/contract. I also realized the blame information is correct, it works fine. Most of the other issues remain, as well as a few new questions: There is no impersonate-evt function, so I’m not sure that my implementation will work. What should I do about this? I’d assume this needs to be documented/tested as well. Where should those things be located? On Jan 14, 2015, at 23:44, Alexis King lexi.lam...@gmail.com wrote: Currently, async channels do not have contracts to check their contents. This is a problem for Typed Racket, and it prevents typed code from interacting with code that produces async channels. I started looking into how to add contracts to the language, and it seems to use the chaperones/impersonator system, as I suspected. However, async channels obviously cannot be impersonated, so I needed to implement that as well. I modified the async-channel struct to use generics to allow it to be impersonated or chaperoned, which I have exposed by implementing chaperone-async-channel. I then tried implementing async-channel/c. The internals of the contract system are a little beyond me, but I got a working solution by following the example of the box contracts. My work thus far can be found here: https://github.com/lexi-lambda/racket/commit/84b9f3604891f3f2061fb28ed4800af8afa4751b First of all, is this a correct approach? Have I done anything wrong, or should I have done anything differently? I didn’t find much documentation on the internals of either of these systems, so I mostly went about things as I found them. Second, obviously, not everything is implemented here. Among the additional necessary changes are: I need to implement support for impersonators and impersonator contracts (right now I’ve only bothered to do chaperones). I need to implement async-channel/c-first-order and async-channel/c-stronger. I can probably figure out the latter, but I’m not even sure what the former is supposed to do. I need to implement a wrap-async-channel/c macro for the export. I’m not sure how this works, either. From looking at wrap-box/c, it seems to add some syntax properties, but I’m not sure what they do or how they work. Somehow, the blame information has to be correct. Is that what the wrap function does? Or do the async-channel functions need to be updated to assign blame? I’d really like to get this working, and I think I’m close, but I’m a little inexperienced. I’d appreciate any help, even if it’s just pointing me in the right direction. Thanks! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
