Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts

2012-12-28 Thread Matthias Felleisen
On Dec 27, 2012, at 8:58 PM, Harry Spier wrote: > On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen > wrote: >> >> It is critical to inform clients of the services that a module >> provides. In the absence of types, contracts are the closest >> information we have. > AND > On Fri, Dec 14, 20

Re: [racket-dev] Contract barrier inefficiencies

2012-12-28 Thread Matthias Felleisen
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 i

Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts

2012-12-28 Thread Ray Racine
An alternate flow which I think aligns slightly better with graduated code validity vs cost (effort)? 0. Quick and dirty code spikes, snippets in R. 1. Write prototype code directly in TR. - Liberal addition via Step 0 efforts, pre and current with Step 1. - TR is very lightweight. - The sin

Re: [racket-dev] Contract barrier inefficiencies

2012-12-28 Thread Neil Toronto
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 a

Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts

2012-12-28 Thread Harry Spier
On Fri, Dec 28, 2012 at 9:42 AM, Matthias Felleisen wrote: > 2. We see Racket as a continuum: ... >, you should know which entry point is best for you > and choose for yourself at which level you wish to enter. The > point is > > with Racket, you have this choice > > (and with other languages,

Re: [racket-dev] Contract barrier inefficiencies

2012-12-28 Thread Neil Toronto
On 12/27/2012 06:21 PM, Robby Findler wrote: 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 (scribble does this). Currently the contr

Re: [racket-dev] Contract barrier inefficiencies

2012-12-28 Thread Vincent St-Amour
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 _

Re: [racket-dev] Contract barrier inefficiencies

2012-12-28 Thread Robby Findler
By "selection" I mean applying a selector a struct value. Sorry, a bit too terse, eh As for the result, that looks like some great things for us to put into benchmarks (or maybe the math library itself should be what we should look at). I think that the reason the profiler isn't helping you i