> One thing we decided a while back was to put the " (blaming ...)"
> near the end, but the blame information is taken into account in that
> first line. Perhaps there should be a more refined piece of code that
> computes that first line in this case, tho?
On Thursday, NWU-Max gave a bb talk at
On Fri, Dec 16, 2016 at 12:20 PM, Alexis King wrote:
>> On Dec 16, 2016, at 9:53 AM, Robby Findler
>> wrote:
>>
>> Picky would never assign blame to m1. The places where m1 would be
>> blamed would instead fall on, I think, m2.
>
> Ahh, I see. I was confused because I wasn’t paying enough attent
> On Dec 16, 2016, at 9:53 AM, Robby Findler
> wrote:
>
> Picky would never assign blame to m1. The places where m1 would be
> blamed would instead fall on, I think, m2.
Ahh, I see. I was confused because I wasn’t paying enough attention
to the blame information in the error message, only at th
On Fri, Dec 16, 2016 at 11:49 AM, Alexis King wrote:
>> On Dec 15, 2016, at 3:16 PM, Robby Findler
>> wrote:
>>
>> But if you want to know more about how they could be different, you
>> might want to consider this example from section 1 of the paper. It
>> will (randomly) assign blame to any of
> On Dec 15, 2016, at 3:16 PM, Robby Findler
> wrote:
>
> But if you want to know more about how they could be different, you
> might want to consider this example from section 1 of the paper. It
> will (randomly) assign blame to any of the three submodules.
Hmm. That example is helpful to see,
Perhaps the contract implementation could notice that the indy blame
parties and the normal blame parties are the same and thus avoid the
second contract. Given today's experience I'm not sure it is worth
bothering, at least until other things improve in the contract
implementation.
But if you wan
There are 3 parties that could be blamed:
1. the context that calls `foo`
2. the function `foo`
3. the contract on `foo`
On Thu, Dec 15, 2016 at 5:05 PM, Alexis King wrote:
> Many thanks to both of you for the explanation and examples. I admit
> I’ve seen that paper before, but I haven’t really
Many thanks to both of you for the explanation and examples. I admit
I’ve seen that paper before, but I haven’t really taken the time
to understand it. I haven’t spent the effort to understand all the
notation being used, so much of the paper is pretty opaque to me.
Maybe once I get some time I’ll
I've pushed a fix for this and the related bug that I mentioned in
this thread. No important performance improvements, however (I believe
most of the time in ->i microbenchmarks is spent in just piping things
around, not doing the actual contract checking).
Robby
On Wed, Dec 14, 2016 at 5:33 PM,
> On Dec 14, 2016, at 3:56 PM, Scott Moore wrote:
>
> Robby beat me to it. For a longer discussion, see Christos, Robby, Cormac and
> Matthias’ paper: http://www.ccs.neu.edu/racket/pubs/popl11-dfff.pdf on the
> difference between dependent (->d) and indy-dependent contracts (->i).
>
> A contr
Robby beat me to it. For a longer discussion, see Christos, Robby, Cormac and
Matthias’ paper: http://www.ccs.neu.edu/racket/pubs/popl11-dfff.pdf on the
difference between dependent (->d) and indy-dependent contracts (->i).
A contrived example of why this is better is:
(define/contract (foo x y)
I think it could be possible to avoid those printfs but only because
the contracts used here are flat, but the implementation of ->i
doesn't do that specialization. In the general case, the contract on
each of the depended on arguments (x and y in this case) have to be
applied twice, once to catch
This question comes from someone else on Stack Overflow, which they
asked here: http://stackoverflow.com/q/41144374/465378
I think it’s likely that the people who can answer this are probably
only on the mailing list, though, so I figured I’d ask it here.
Basically, the ->i contract applies contr
13 matches
Mail list logo
