add real?, rational?, exact? and inexact? to cpprim

[gus-massa]

The secondary easy part is to fix wrong error message in vector->pseudo-random-generator. There was an (and (exacts? i) (integer? i)) that generated an error in exact? instead of using the handler for vector->pseudo-random-generator.

Anyway, I added a special case for (and (#3%exacts? i) (integer? i)) in npnanopass to detect the unsafe version of this combination.

I could split all of this in an isolated commit if neccesary.

---

The main part is to add a few numerical predicated to cpprim, in particular real?, rational?, exact? and inexact?. For a future PR I care about real?, because currently real? is too slow.

I'm not sure about the implementation details. In particular I'm using only one new library definition to handle the errors in exact? and inexact?, but I saw many primitives with a dedicated error function. Is this fine?

And I think the version should be updated, but I get ar CI error if I do., so I added a comment. I can change it or remove it or whatever is nessesary.

csmacro.ss, line 360
(define-constant scheme-version #x0a030001) ; <-- TODO: update this

Another detail sis that in the predicates I'm using

(build-simple-or
  (%typed-object-check mask-bignum type-bignum ,e)
  (%typed-object-check mask-ratnum type-ratnum ,e))

but I can expand the %type macros to check

(%type-check mask-typed-object type-typed-object ,e)

only once and then look only at the masks of each type. It would increase the speed a tiny bit but I think it's harder to read.

[mflatt]

A drawback for a single $number-oops instead of separate ones for exact? and inexact? is that there's twice as much for the linker to update: a library entry and a symbol literal. The difference is tiny for these two functions, as is the use of build-simple-or with two %typed-object-checks, but I think its probably better to adjust those and have good precedents and helpers in place for the future.

Bumping the version number requires a ./configure --pb && make re.boot to build pb boot files. As long as new boot files are comitted, I'd expect CI to work. Only the pre-release digit at the end should change, and that doesn't affect the version number that should be used in "release_notes.stex", which is currently 10.3.0.

I've pushed a commit that bumps the version number and also adjusts the library entry and tag checks (and release notes). To keep things readable, at least to me, I introduced a bind-type-object-type macro. The multiple typed-object checks in exact? and inexact? are not so easy to remove (due the the way different tag forms need to reach the library call), so I left the multiple read-and-checks there.

Also, I changed the other-number tests to use %typed-object-check. I think the one in build-eqv? was cargo-culted by me from build-number?, but I don't know why build-number? was written that way before. I'm not missing something about why it was written the old way, right?

As an extra check, I tried the combination of this PR (with the extra commit) and #952 with Racket, and it went fine.

If this looks ok to you @gus-massa, I can squash and merge.

[gus-massa]

Look great, but I have to wait until Friday to take a deep look.

Why

#define library_entry_vector_size 0x272

increase by 4 instead of by 2?

[mflatt]

increase by 4 instead of by 2?

I think that's because has-does-not-expect-headroom-version? is #t.

[gus-massa]

I think the build-and inside bind-type-object-type is surprising. What about moving it outside, so the control flow is explicit?
Anyway, both versions are fine for me if you want to rebase, squash and merge them.

I tried to use bind-type-object-type in exact? and inexact?, but as you noted it's not possible (unless I duplicate the call to the error generating library definition, that I guess is worse). So I didn't chane them.

[gus-massa]

Thanks.