Also I think that the size of the code generated by arrow contracts (when keywords are involved and other situations that perhaps aren't worth spelling out in detail in this email) is larger than we would like, which also doesn't help.
Robby On Wed, Jan 30, 2019 at 7:52 PM Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote: > > On Wed, Jan 30, 2019 at 8:23 PM Matthew Flatt <mfl...@cs.utah.edu> wrote: > > > > At Wed, 30 Jan 2019 16:31:52 -0800 (PST), Alex Harsanyi wrote: > > > I always assumed that the contracts generated when TR code is used from > > > untyped Racket would be the same as the ones written by hand if the module > > > would be untyped and had contracts on the same exported functions. Is > > > this > > > not the case? > > > > That's pretty much the case, as far as I know. > > That is (mostly) the case, except that Typed Racket generates > completely comprehensive contracts, which can mean they're much larger > than what you might write idiomatically. > > > > Is there some documentation on how to measure the amount of code used by > > > contracts (the 15% value you mention above)? > > > > No. Sam set up a branch of TR that skipped contract generation, and I > > compared ".zo" sizes using that branch versus the normal one. > > That branch is at https://github.com/samth/typed-racket/tree/no-contracts > > > > I experimented with TR for a few things and left them in the code > > > base, but if they create significant performance issues, I can > > > convert them to untyped Racket easily. > > > > 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. > > Sam > > -- > 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. -- 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.
