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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
