1.0.44.28: allow approximating unions of numeric types
authorNikodemus Siivola <nikodemus@random-state.net>
Thu, 18 Nov 2010 12:02:45 +0000 (12:02 +0000)
committerNikodemus Siivola <nikodemus@random-state.net>
Thu, 18 Nov 2010 12:02:45 +0000 (12:02 +0000)
 (dummy commit: change described here happened in the last commit really,
  but the commit message was subtly wrong and missed the version number)

 * Binding *APPROXIMATE-NUMERIC-UNIONS* does that. It must be bound
   only by callers of TYPE-UNION that know what they want -- in general

     (OR (INTEGER 1 2) (INTEGER 4 4)) => (INTEGER 1 4)

   is wrong, as (NOT (INTEGER 1 4)) doesn't include 3. But in special cases
   like deriving the return type of a function it can be done.

 * Rename MAKE-CANONICAL-UNION-TYPE MAKE-DERIVED-UNION-TYPE, and bind *A-N-U*
   there if we start accumulating an overly large union of numeric types.
   Definition of "overly large" can be adjusted via
   *DERIVED-NUMERIC-UNION-COMPLEXITY-LIMIT*.

 * Fixes lp#309448 and the recent compiler performance regression due
   to new CONCATENATE deftransform as reported on sbcl-devel.

version.lisp-expr

index a773c8e..d82366a 100644 (file)
@@ -6,6 +6,9 @@
 ;;; possible blank lines or other whitespace, and a single
 ;;; double-quoted string value alone on its own line.
 ;;;
+;;; Local additions to the version number can be effected via
+;;; branch-version.lisp-expr, which is not stored in the CVS.
+;;;
 ;;; ANSI says LISP-IMPLEMENTATION-VERSION can be NIL "if no
 ;;; appropriate and relevant result can be produced", but as long as
 ;;; we control the build, we can always assign an appropriate and