Skip to content
Snippets Groups Projects
Forked from cmucl / cmucl
Source project has a limited visibility.
  • rtoy's avatar
    d321a141
    o Change the def-type-translator for COMPLEX to fix some confusion in · d321a141
    rtoy authored
      the compiler about what COMPLEX and (COMPLEX REAL) are.  They should
      be the same.
      - Make (COMPLEX *) be the same as (COMPLEX REAL), because we were
        creating a plain COMPLEX, which isn't what we want.
      - If the typespec is a subtype of RATIONAL, return (COMPLEX
        RATIONAL).
    o Make (COMPLEX REAL) print out as COMPLEX instead of as a union of
      specialized complex types.
    o Modify CTYPE-OF-NUMBER so that it no longer creates (COMPLEX
      (INTEGER low high)) types; these are now (COMPLEX RATIONAL).  This
      fixes a bug where (type-of #c(0 1/2)) was giving an error.  (This is
      fixes the bug by removing the offending code.  But do we really want
      and need to support (COMPLEX INTEGER) types in the compiler?
      Shouldn't (COMPLEX RATIONAL) be good enough?)
    d321a141
    History
    o Change the def-type-translator for COMPLEX to fix some confusion in
    rtoy authored
      the compiler about what COMPLEX and (COMPLEX REAL) are.  They should
      be the same.
      - Make (COMPLEX *) be the same as (COMPLEX REAL), because we were
        creating a plain COMPLEX, which isn't what we want.
      - If the typespec is a subtype of RATIONAL, return (COMPLEX
        RATIONAL).
    o Make (COMPLEX REAL) print out as COMPLEX instead of as a union of
      specialized complex types.
    o Modify CTYPE-OF-NUMBER so that it no longer creates (COMPLEX
      (INTEGER low high)) types; these are now (COMPLEX RATIONAL).  This
      fixes a bug where (type-of #c(0 1/2)) was giving an error.  (This is
      fixes the bug by removing the offending code.  But do we really want
      and need to support (COMPLEX INTEGER) types in the compiler?
      Shouldn't (COMPLEX RATIONAL) be good enough?)