typed-racket

typed-racket copied to clipboard

This PR adds more type aliases (see also https://github.com/racket/typed-racket/issues/1242):

Flonum-Complex

Single-Float
Nonpositive-Single-Float
Negative-Single-Float
Nonnegative-Single-Float
Positive-Single-Float
Single-Float-Nan
Single-Float-Zero
Single-Float-Negative-Zero
Single-Float-Positive-Zero

Rational
Exact-Nonpositive-Rational
Nonpositive-Rational
Exact-Negative-Rational
Negative-Rational
Exact-Nonnegative-Rational
Nonnegative-Rational
Exact-Positive-Rational
Positive-Rational

Exact-Integer
Nonpositive-Exact-Integer
Exact-Nonpositive-Integer
Negative-Exact-Integer 
Exact-Negative-Integer
Nonnegative-Exact-Integer
Positive-Exact-Integer

ExtFloat
Nonpositive-ExtFloat
Negative-ExtFloat
Nonnegative-ExtFloat
Positive-ExtFloat
ExtFloat-Nan
ExtFloat-Zero
ExtFloat-Negative-Zero
ExtFloat-Positive-Zero

Box
Weak-Box
Custodian-Box

None

MPair

And here is something I'm not sure how to deal with:

1. Complex and Number TR reference says "Number and Complex are synonyms.", but Exact-Number and Exact-Complex are different, is there any special reason? Should I modify it and regard Exact-Complex as an alias for Exact-Number?

[edit]: Exact-Complex should not contain numbers like 0+1i, 1+0i, etc..

2. More base types I notice that there are some types defined in rep/base-types.rkt and rep/numeric-base-types.rkt and REPL already uses them, but they are not provided. Should TR provide them?

Welcome to Racket v8.5 [cs].
> 8.3
- : Flonum [more precisely: Positive-Float-No-NaN]
8.3
> (:kind Positive-Float-No-NaN)
string:1:7: Type Checker: parse error in type;
 type name `Positive-Float-No-NaN' is unbound
  in: Positive-Float-No-NaN
 [,bt for context]
> (:kind Positive-Float)
*

Byte-Larger-Than-One
Positive-Index-Not-Byte
Positive-Fixnum-Not-Index
Positive-Integer-Not-Fixnum
Negative-Integer-Not-Fixnum
Positive-Rational-Not-Integer
Negative-Rational-Not-Integer
Positive-Float-No-NaN
Negative-Float-No-NaN
Positive-Single-Flonum-No-Nan
Negative-Single-Flonum-No-Nan
Float-Imaginary
Single-Flonum-Imaginary


Base-Regexp
Byte-Base-Regexp
OtherSystemPath
Compiled-Non-Module-Expression
Base-Place-Channel
Negative-ExtFlonum-No-NaN
Positive-ExtFlonum-No-NaN
Dead-Code

Yes, anything that can appear printed should be legal to write.

Hi @jackfirth, Resyntax / build (pull_request_target) always fails with error message: ref refs/heads/master doesn't represent a pull request. Is there something wrong here?

@NoahStoryM The Resyntax integration is broken for pull requests from forks. I'll have to rework the check so that the analysis step and the pull request comment step are split into different workflows. Feel free to ignore the failures for now.