From 9d1bfedc5e13f7634b86827e2ac89709c2f5ac04 Mon Sep 17 00:00:00 2001 From: Vincent St-Amour Date: Mon, 16 May 2011 14:44:17 -0400 Subject: [PATCH] Add a test case for close-calls on all-real arithmetic expressions. original commit: 5d4ef5c62478ca1dfeeb5a79d6ed65479283a31f --- .../optimizer/close-calls/all-real.rkt | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 collects/tests/typed-scheme/optimizer/close-calls/all-real.rkt diff --git a/collects/tests/typed-scheme/optimizer/close-calls/all-real.rkt b/collects/tests/typed-scheme/optimizer/close-calls/all-real.rkt new file mode 100644 index 00000000..ec36a78d --- /dev/null +++ b/collects/tests/typed-scheme/optimizer/close-calls/all-real.rkt @@ -0,0 +1,25 @@ +#; +( + all-real.rkt 24:0 (#%app + (quote 3) (quote 4)) -- binary, args all float-arg-expr, return type not Float -- caused by: 24:8 (quote 3) + all-real.rkt 25:0 (#%app * (quote 3) (quote 4)) -- binary, args all float-arg-expr, return type not Float -- caused by: 25:8 (quote 3) + 7 + 12 + ) + +#lang typed/racket + +;; all-real expressions +;; They currently get reported as missed float optimizations. +;; Whether that's the right thing or not is debatable. +;; pro: more often than not, Real types pop up when the type system can't +;; prove something, but the user really wants a float type, so reporting +;; is likely to be helpful +;; con: all-real expressions can arise from integer-only computations +;; (ex: (+ (sqrt 4) 2) : Positive-Real), so reporting a missed float opt +;; sounds wrong +;; If we decide against reporting these cases in the future, it's only a matter +;; of adding a check to make sure at least one of the subexpressions is in the +;; Float layer in addition to the entire expression being in the Real layer. + +(+ (ann 3 Real) (ann 4 Real)) +(* (ann 3 Real) (ann 4 Real))