Re: [racket-dev] Machinery for eliding contracts
You also can't protect against someone using the FFI to fake whatever value you thought was safe. I think your best bet here is to document what you're doing any why you're doing it and then treat uses of some primitive things (like directly constructing blame records in this case) as unsafe operations. Robby On Fri, Jun 13, 2014 at 10:32 AM, Eric Dobson wrote: > I believe thats what I need for the optimization-half, but I don't > think it allows for soundly implementing the optimizations. > > I still don't see how to test if a value came from TR instead of > someone trying to fake that, especially if they can get the blame > object from one export and reuse it on a different value. > > On Fri, Jun 13, 2014 at 6:29 AM, Robby Findler > wrote: >> Okay, I'll push has-blame? and value-blame. Let me know if there are >> any problems. >> >> Robby >> >> On Fri, Jun 13, 2014 at 5:59 AM, Sam Tobin-Hochstadt >> wrote: >>> Yes, I think this would allow all the optimizations that Eric talked about. >>> >>> Sam >>> >>> On Jun 13, 2014 4:26 AM, "Robby Findler" >>> wrote: Would it be useful to get blame information back from a value, just like you can currently get the contract back? Robby On Tue, Jun 10, 2014 at 11:53 AM, Matthias Felleisen wrote: > > I was thinking of associating the contract with the type from which it > comes and no that's not hash-consing. And if it's slower, too bad. -- > Matthias > > > > > > On Jun 10, 2014, at 12:47 PM, Eric Dobson > wrote: > >> On Tue, Jun 10, 2014 at 6:15 AM, Matthias Felleisen >> wrote: >>> >>> On Jun 9, 2014, at 6:02 PM, Eric Dobson >>> wrote: >>> > > Eric, are you talking about changing the proxy values that wrap > HO/mutable > contracted values? Yes. I want the proxy values to include information about who agreed to the contract in addition to the contract agreed to. I actually realize that I might need more than just the contract agreed to because of how TR changes the generated contract to remove checks for what it guarantees, so that info is not in the contract. But I believe that can be added back as a structure property on the contract. >>> >>> >>> Would some form of hash-consing contracts work here? -- Matthias >>> >> >> I don't think so. But not sure exactly what you are proposing. >> >> The issue is that there are 4 contracts here and 2 of them currently >> do not exist at runtime. The 4 are TRs checks/promises on an >> export/import. (Using import for a value flowing into an exported >> function). The promise contracts do not currently exist as removing >> them was my previous optimization (They never fail). What I want to do >> is change the check on import from (array/c symbol?) to (if/c >> (protected>? (array/c symbol?)) any/c (array/c symbol?)). Where >> (protected>? x/c) checks if TR already promised something stronger >> than x/c. >> >> I believe that you are proposing that we can use the identity of the >> contract returned by value-contract to determine what the promised >> contract would have been. This does not work as (Array Symbol) and >> (Array Float) both get translated to (array/c any/c) for export, and >> we would want to lookup different promised contracts for them. We >> could use weak hash map as an extra field but that seems like it would >> be slow. > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
I believe thats what I need for the optimization-half, but I don't think it allows for soundly implementing the optimizations. I still don't see how to test if a value came from TR instead of someone trying to fake that, especially if they can get the blame object from one export and reuse it on a different value. On Fri, Jun 13, 2014 at 6:29 AM, Robby Findler wrote: > Okay, I'll push has-blame? and value-blame. Let me know if there are > any problems. > > Robby > > On Fri, Jun 13, 2014 at 5:59 AM, Sam Tobin-Hochstadt > wrote: >> Yes, I think this would allow all the optimizations that Eric talked about. >> >> Sam >> >> On Jun 13, 2014 4:26 AM, "Robby Findler" >> wrote: >>> >>> Would it be useful to get blame information back from a value, just >>> like you can currently get the contract back? >>> >>> Robby >>> >>> On Tue, Jun 10, 2014 at 11:53 AM, Matthias Felleisen >>> wrote: >>> > >>> > I was thinking of associating the contract with the type from which it >>> > comes and no that's not hash-consing. And if it's slower, too bad. -- >>> > Matthias >>> > >>> > >>> > >>> > >>> > >>> > On Jun 10, 2014, at 12:47 PM, Eric Dobson >>> > wrote: >>> > >>> >> On Tue, Jun 10, 2014 at 6:15 AM, Matthias Felleisen >>> >> wrote: >>> >>> >>> >>> On Jun 9, 2014, at 6:02 PM, Eric Dobson >>> >>> wrote: >>> >>> >>> > >>> > Eric, are you talking about changing the proxy values that wrap >>> > HO/mutable >>> > contracted values? >>> Yes. I want the proxy values to include information about who agreed >>> to the contract in addition to the contract agreed to. >>> >>> I actually realize that I might need more than just the contract >>> agreed to because of how TR changes the generated contract to remove >>> checks for what it guarantees, so that info is not in the contract. >>> But I believe that can be added back as a structure property on the >>> contract. >>> >>> >>> >>> >>> >>> Would some form of hash-consing contracts work here? -- Matthias >>> >>> >>> >> >>> >> I don't think so. But not sure exactly what you are proposing. >>> >> >>> >> The issue is that there are 4 contracts here and 2 of them currently >>> >> do not exist at runtime. The 4 are TRs checks/promises on an >>> >> export/import. (Using import for a value flowing into an exported >>> >> function). The promise contracts do not currently exist as removing >>> >> them was my previous optimization (They never fail). What I want to do >>> >> is change the check on import from (array/c symbol?) to (if/c >>> >> (protected>? (array/c symbol?)) any/c (array/c symbol?)). Where >>> >> (protected>? x/c) checks if TR already promised something stronger >>> >> than x/c. >>> >> >>> >> I believe that you are proposing that we can use the identity of the >>> >> contract returned by value-contract to determine what the promised >>> >> contract would have been. This does not work as (Array Symbol) and >>> >> (Array Float) both get translated to (array/c any/c) for export, and >>> >> we would want to lookup different promised contracts for them. We >>> >> could use weak hash map as an extra field but that seems like it would >>> >> be slow. >>> > >>> > >>> > _ >>> > Racket Developers list: >>> > http://lists.racket-lang.org/dev >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
Okay, I'll push has-blame? and value-blame. Let me know if there are any problems. Robby On Fri, Jun 13, 2014 at 5:59 AM, Sam Tobin-Hochstadt wrote: > Yes, I think this would allow all the optimizations that Eric talked about. > > Sam > > On Jun 13, 2014 4:26 AM, "Robby Findler" > wrote: >> >> Would it be useful to get blame information back from a value, just >> like you can currently get the contract back? >> >> Robby >> >> On Tue, Jun 10, 2014 at 11:53 AM, Matthias Felleisen >> wrote: >> > >> > I was thinking of associating the contract with the type from which it >> > comes and no that's not hash-consing. And if it's slower, too bad. -- >> > Matthias >> > >> > >> > >> > >> > >> > On Jun 10, 2014, at 12:47 PM, Eric Dobson >> > wrote: >> > >> >> On Tue, Jun 10, 2014 at 6:15 AM, Matthias Felleisen >> >> wrote: >> >>> >> >>> On Jun 9, 2014, at 6:02 PM, Eric Dobson >> >>> wrote: >> >>> >> > >> > Eric, are you talking about changing the proxy values that wrap >> > HO/mutable >> > contracted values? >> Yes. I want the proxy values to include information about who agreed >> to the contract in addition to the contract agreed to. >> >> I actually realize that I might need more than just the contract >> agreed to because of how TR changes the generated contract to remove >> checks for what it guarantees, so that info is not in the contract. >> But I believe that can be added back as a structure property on the >> contract. >> >>> >> >>> >> >>> Would some form of hash-consing contracts work here? -- Matthias >> >>> >> >> >> >> I don't think so. But not sure exactly what you are proposing. >> >> >> >> The issue is that there are 4 contracts here and 2 of them currently >> >> do not exist at runtime. The 4 are TRs checks/promises on an >> >> export/import. (Using import for a value flowing into an exported >> >> function). The promise contracts do not currently exist as removing >> >> them was my previous optimization (They never fail). What I want to do >> >> is change the check on import from (array/c symbol?) to (if/c >> >> (protected>? (array/c symbol?)) any/c (array/c symbol?)). Where >> >> (protected>? x/c) checks if TR already promised something stronger >> >> than x/c. >> >> >> >> I believe that you are proposing that we can use the identity of the >> >> contract returned by value-contract to determine what the promised >> >> contract would have been. This does not work as (Array Symbol) and >> >> (Array Float) both get translated to (array/c any/c) for export, and >> >> we would want to lookup different promised contracts for them. We >> >> could use weak hash map as an extra field but that seems like it would >> >> be slow. >> > >> > >> > _ >> > Racket Developers list: >> > http://lists.racket-lang.org/dev >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
Yes, I think this would allow all the optimizations that Eric talked about. Sam On Jun 13, 2014 4:26 AM, "Robby Findler" wrote: > Would it be useful to get blame information back from a value, just > like you can currently get the contract back? > > Robby > > On Tue, Jun 10, 2014 at 11:53 AM, Matthias Felleisen > wrote: > > > > I was thinking of associating the contract with the type from which it > comes and no that's not hash-consing. And if it's slower, too bad. -- > Matthias > > > > > > > > > > > > On Jun 10, 2014, at 12:47 PM, Eric Dobson > wrote: > > > >> On Tue, Jun 10, 2014 at 6:15 AM, Matthias Felleisen > >> wrote: > >>> > >>> On Jun 9, 2014, at 6:02 PM, Eric Dobson > wrote: > >>> > > > > Eric, are you talking about changing the proxy values that wrap > HO/mutable > > contracted values? > Yes. I want the proxy values to include information about who agreed > to the contract in addition to the contract agreed to. > > I actually realize that I might need more than just the contract > agreed to because of how TR changes the generated contract to remove > checks for what it guarantees, so that info is not in the contract. > But I believe that can be added back as a structure property on the > contract. > >>> > >>> > >>> Would some form of hash-consing contracts work here? -- Matthias > >>> > >> > >> I don't think so. But not sure exactly what you are proposing. > >> > >> The issue is that there are 4 contracts here and 2 of them currently > >> do not exist at runtime. The 4 are TRs checks/promises on an > >> export/import. (Using import for a value flowing into an exported > >> function). The promise contracts do not currently exist as removing > >> them was my previous optimization (They never fail). What I want to do > >> is change the check on import from (array/c symbol?) to (if/c > >> (protected>? (array/c symbol?)) any/c (array/c symbol?)). Where > >> (protected>? x/c) checks if TR already promised something stronger > >> than x/c. > >> > >> I believe that you are proposing that we can use the identity of the > >> contract returned by value-contract to determine what the promised > >> contract would have been. This does not work as (Array Symbol) and > >> (Array Float) both get translated to (array/c any/c) for export, and > >> we would want to lookup different promised contracts for them. We > >> could use weak hash map as an extra field but that seems like it would > >> be slow. > > > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
Would it be useful to get blame information back from a value, just like you can currently get the contract back? Robby On Tue, Jun 10, 2014 at 11:53 AM, Matthias Felleisen wrote: > > I was thinking of associating the contract with the type from which it comes > and no that's not hash-consing. And if it's slower, too bad. -- Matthias > > > > > > On Jun 10, 2014, at 12:47 PM, Eric Dobson wrote: > >> On Tue, Jun 10, 2014 at 6:15 AM, Matthias Felleisen >> wrote: >>> >>> On Jun 9, 2014, at 6:02 PM, Eric Dobson wrote: >>> > > Eric, are you talking about changing the proxy values that wrap HO/mutable > contracted values? Yes. I want the proxy values to include information about who agreed to the contract in addition to the contract agreed to. I actually realize that I might need more than just the contract agreed to because of how TR changes the generated contract to remove checks for what it guarantees, so that info is not in the contract. But I believe that can be added back as a structure property on the contract. >>> >>> >>> Would some form of hash-consing contracts work here? -- Matthias >>> >> >> I don't think so. But not sure exactly what you are proposing. >> >> The issue is that there are 4 contracts here and 2 of them currently >> do not exist at runtime. The 4 are TRs checks/promises on an >> export/import. (Using import for a value flowing into an exported >> function). The promise contracts do not currently exist as removing >> them was my previous optimization (They never fail). What I want to do >> is change the check on import from (array/c symbol?) to (if/c >> (protected>? (array/c symbol?)) any/c (array/c symbol?)). Where >> (protected>? x/c) checks if TR already promised something stronger >> than x/c. >> >> I believe that you are proposing that we can use the identity of the >> contract returned by value-contract to determine what the promised >> contract would have been. This does not work as (Array Symbol) and >> (Array Float) both get translated to (array/c any/c) for export, and >> we would want to lookup different promised contracts for them. We >> could use weak hash map as an extra field but that seems like it would >> be slow. > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
