Re: [racket-dev] Implementing contracts for async channels

[Alexis King]

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
 


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  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  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  
>>> 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  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  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

[Robby Findler]

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  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  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  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  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

[Alexis King]

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  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  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  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

[Robby Findler]

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  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  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

[Sam Tobin-Hochstadt]

On Thu, Jan 15, 2015 at 4:33 PM, Alexis King  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  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

[Alexis King]

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  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