[racket-dev] Machinery for eliding contracts

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 <eric.n.dobson at gmail.com> wrote:

> On Tue, Jun 10, 2014 at 6:15 AM, Matthias Felleisen
> <matthias at ccs.neu.edu> wrote:
>> 
>> On Jun 9, 2014, at 6:02 PM, Eric Dobson <eric.n.dobson at gmail.com> 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.