I’ve written up the relevant documentation, so I think this is more or less complete. I’ve submitted a pull request here <https://github.com/plt/racket/pull/860>. I went ahead with my gut instincts and put the documentation with the racket/async-channel documentation rather than the contract and impersonator documentation, since I think it makes more sense there.
The only remaining potential problem is the impersonate-evt issue outlined previously. Frankly, I’m not even sure how to test that, much less work around it, so if it’s a real issue, I’d probably need some advice in fixing it. (I’m not even really sure how to devise a contract that would produce an impersonator contract.) I’ve also implemented the accompanying changes in Typed Racket and submitted a pull request here <https://github.com/racket/typed-racket/pull/12>. Obviously, since that depends on the Racket changes, it can’t be pulled until the changes are merged, but I figured I’d submit a pull request anyway in case there are any changes that I need to make to the Typed Racket implementation. > On Jan 15, 2015, at 23:07, Alexis King <lexi.lam...@gmail.com> wrote: > > 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 >> <mailto: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 >> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>>> <mailto: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 >>>>> >>> >
____________________ Racket Users list: http://lists.racket-lang.org/users
