What I'd much prefer at the moment over speculative solutions are reports of actual performance bottlenecks. -- Matthias
On May 1, 2015, at 1:09 AM, michael.ballantyne wrote: > I've started using Typed Racket several times recently only to flip the > switch to #lang typed/racket/no-check or remove types entirely. Something > like Vincent suggests with an option to write with types and have them > checked but turn off the type-driven optimizer and skip contract checking at > typed/untyped boundaries would be fantastic. > > Having the option to flip this switch either from the code doing the > requiring or at package installation time seems important, regardless of > whether the author of the typed code wrote with that in mind. When I wanted > to use the tr-pfds package from untyped code I had to modify it to use #lang > typed/racket/no-check because the performance hit of contract checks was > massive. > > A raco option to compile and install a package without Typed Racket > optimizations or contracts might be another piece of the solution. > > > On Monday, March 23, 2015 at 1:23:12 PM UTC-6, Robby Findler wrote: >> Just to be sure we are on the same page, my comments were in the >> context of push back that came for reasons that are unclear to me, but >> I think had something to do with the thought that we shouldn't >> compromise the type system. My comments were meant to be in that >> context, trying to point out what the real value of a type system is; >> that is, to give a judgment we can use as a basis for design decisions >> here. >> >> As for smothering: the cost of contracts is "observable enough" (you >> know what I mean) that we cannot just ignore it, as I'm sure you >> agree. And since we do not have an acceptable solution we should >> explore generalizing our support for unsafe operations that we already >> have. It seems to fit very naturally to think of parallel libraries, >> the safe and the unsafe version. >> >> I also like Vincent's idea about coupling the optimizer to the >> contracts as a point worth pragmatic exploration. We shouldn't kid >> ourselves, however, it is still unsafe and programs that turn it on >> can behave in arbitrarily weird ways (when an error is skipped over). >> >> Robby >> >> >> On Mon, Mar 23, 2015 at 2:12 PM, Matthias Felleisen >> <[email protected]> wrote: >>> >>> On Mar 20, 2015, at 5:10 PM, Robby Findler <[email protected]> >>> wrote: >>> >>>> Well, that's already the case if you use the FFI (which lots and lots >>>> of Racket programs do). >>>> >>>> Fundamentally the typechecker is a tool that programmers can choose to >>>> use to make their programs better. It should not try to be more than >>>> that. >>> >>> >>> I think these statements paint an image in broad brushstrokes that >>> some people appreciate properly and some don't. >>> >>> Yes, ffi/unsafe makes Racket programs unsafe. They may introduce >>> causes for segfaults beyond the Racket engine itself. That's not >>> a good thing but ffi/unsafe suggests this problem by its name and >>> I think we try to stick this to a layer where we know it's potentially >>> problematic. >>> >>> Otherwise the goal is to smother the unsafety of the existing software >>> infrastructure. If we don't have such a minimal goal, why bother with >>> Racket (at least from a research perspective)? >>> >>> ;; ---------------------------------------------------------------------- >>> >>> On Mar 23, 2015, at 1:37 PM, Vincent St-Amour <[email protected]> wrote: >>> >>>> Then there's the possibility of turning off the optimizer (makes most >>>> sense for the `#lang` design), which would compromise by avoiding >>>> contracts, but remain as safe as `#lang racket`. There's already a way >>>> to turn off the optimizer (`#:no-optimize`), so that may be redundant. >>> >>> >>> This is an acceptable and pragmatic alternative. It gives the programmer >>> some of the advantages of types (checking, documentation, hooks for tools). >>> And it does not lower the level of safety that Racket aims for. >>> >>> On a more general note: It also exposes the Reynolds insight that types >>> are an inherent part of the meaning (static). As such, compiling uses of >>> first in >>> >>> (: f (-> [List X Y Z] X)) >>> >>> to not check the listness of the argument is intrinsic to __compilation__, >>> not __optimization__. I think the strict use of this guideline would >>> establish >>> another point in our language spectrum. >>> >>> >>> -- Matthias >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
