On Dec 29, 2012, at 11:04 PM, Robby Findler wrote:
That's what the patch I sent does I think (specifically in the case of an
arrow contract on a function)? Am I missing something?
I think the contracts are repeated and not defined locally so that 'eq?'
doesn't apply. Does this explain
I am no longer sure but Neil's earlier message suggested no is the right
answer to this question in the sense that even if you make the contracts be
eq? by using a local variable then it isn't enough because the functions
with the contracts are not eq?.
Neil, can you clarify?
Robby
On Sunday,
On Dec 27, 2012, at 9:22 PM, Neil Toronto wrote:
Sorry it took so long to reply.
I applied the patch and verified that my example runs a *lot* faster (with
domain and range contracts identical, of course). Unfortunately, a similar
test using arrays isn't any faster. This is how the
On 12/28/2012 08:23 AM, Matthias Felleisen wrote:
On Dec 27, 2012, at 9:22 PM, Neil Toronto wrote:
Sorry it took so long to reply.
I applied the patch and verified that my example runs a *lot* faster (with
domain and range contracts identical, of course). Unfortunately, a similar test
using
At Thu, 27 Dec 2012 19:21:53 -0600,
Robby Findler wrote:
OC could suggest moving heavily called functions across boundaries, that'd
be cool.
That sounds interesting, and would be a good use of profiling
information. Added to my to-do list.
Thanks for the suggestion!
Vincent
1. Robby responded to your first item some time back. He and I had discussed
contract-stronger and eq? check several times in the past. But even that
doesn't assure improved checking w/o some performance-oriented thinking on the
programmer's side.
2. Sam didn't respond to the second part,
OC could suggest moving heavily called functions across boundaries, that'd
be cool.
One other place that we realized pretty quickly where we were wrong about
the boundaries and inefficiencies is struct declarations. It isn't uncommon
to put contracts on structs and put them in their own module
So there are potentially huge inefficiencies when mixing typed and
untyped code, usually when functions are passed across the contract
barrier. Here are a few things that I think cause them. Can the People
Who Know This Stuff Really Well please comment on these issues?
1. Functions that
I can't help with the others, but for 1.) I've considered using a
contract-stronger? test or even just an eq? test when applying a contract,
checking what's already on the value. I haven't added that as it hasn't
come up in anger (and it isn't free, but the check is cheap). If I put a
broken test
9 matches
Mail list logo
