Oh, sorry: I just meant that it may be useful information if we were
to run some micro-benchmarks to determine where the break-even point
is between #:lazy and strict for some fairly simple tree type and an
untyped program that just walks over the tree, say, twice. I'm
imagining measuring the break
The issue is TR doesn't know statically know how the value will be
used, thus we have do the computation for determining the break even
point at run time. This puts the actual work in the contract system
(or at least the contracts that TR generates), and I don't understand
all the internal workings
On Tue, Jun 10, 2014 at 2:27 AM, Eric Dobson wrote:
> On Mon, Jun 9, 2014 at 9:46 PM, Eric Dobson wrote:
>> Splitting this out because this is actually a different issue. This is
>> about us generating slow contracts.
>>
>> There are two things in play here.
>>
>> One is that TR doesn't use the n
On Mon, Jun 9, 2014 at 9:46 PM, Eric Dobson wrote:
> Splitting this out because this is actually a different issue. This is
> about us generating slow contracts.
>
> There are two things in play here.
>
> One is that TR doesn't use the new lazy parts of struct/dc. This would
> require changing str
Splitting this out because this is actually a different issue. This is
about us generating slow contracts.
There are two things in play here.
One is that TR doesn't use the new lazy parts of struct/dc. This would
require changing struct contracts from flat contracts to
chaperone-contracts. Given
5 matches
Mail list logo
