Certainly the dependent contract approach will work, but the 'Real -> Real' contract is also safe, so I'll see about generating that. Sam <div class="gmail_quote">On Jun 26, 2012 8:37 PM, "Robby Findler" <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> In this case, the contract could turn into a dependent one with the same semantics. Does it make sense for TR to allow a user to declare the equivalent contract? Robby On Tue, Jun 26, 2012 at 7:17 PM, Neil Toronto <<a href="mailto:neil.toronto@gmail.com">neil.toronto@gmail.com</a>> wrote: > Ten minutes in, I've hit a snag. I'd like the stuff in math/functions to > have precise types. For example, log1p could have the type > > (case-> (Zero -> Zero) > (Float -> Float) > (Real -> Real)) > > It was easy to get the implementation to typecheck, but when I tried to plot > it in untyped Racket, I got this: > > Type Checker: The type of log1p cannot be converted to a contract in: log1p > > I really don't want to have two versions of the library. Could TR use the > most general type (Real -> Real) as the contract? Or would that be unsound? > > Neil ⊥ > _________________________ > Racket Developers list: > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> _________________________ Racket Developers list: <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </blockquote></div>