> On Jan 30, 2019, at 8:52 PM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote: > >> Although there are costs to TR in compile time and load time, >> especially in a program that also has untyped components, I generally >> would not recommend moving away from TR. > > Unlike Matthew, I can be sure not to offend the creator of Typed > Racket by saying that in some cases, contract generation can take too > much compile time or bytecode space, or result in too big a runtime > overhead, to be acceptable. In those cases, I recommend either using > the `typed/racket/unsafe` library to omit contracts (and protect > things manually) or move away from Typed Racket entirely. The places I > know where this has been an issue are very large OO hierarchies (as in > the `racket/gui` library) and very large data types constructed from > many unions of many distinct structs. I'm happy to take a look at your > code if that would be helpful.
I have no problem offending the lead TR designer and maintainer (also thanks to Asumu, Stevie, Kent, and everyone else who designed & implemented essential elements. The offense is to Sam alone :) ;; - - - If adding Typed Racket to Unityped Racket code (I sure do like your insistence on Dana Scott’s terminology) feels like it’s slowing down your code, please try the feature-specific profiler to determine the module boundary that imposes the cost. By moving this boundary (like adding another typed module) you might be able to get the full performance benefits of TR (there are some). Yes, we should improve FSP and document it for these cases, but from looking at your blog and emails, I suspect you can cope. This would be tremendously helpful for the continued TR development. Thanks — 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
