Type domain (static) integers

[nsajko]

@jakobnissen

It seems to me that the major motivation for static integers is to move computation from runtime to compile time.

Type domain integers are the motivation. Types are great:

• they can be dispatched on
• you get type safety automatically, instead of having to implement various run time checks
• they allow elegant compile time computation

@jakobnissen

somewhat understandable, as we kind of have to do this in Julia to get compile time computation, as it is now

Really don’t see where you’re coming from. Julia’s powerful type system is one of the best things about Julia.

@jakobnissen

I would much rather see a solution where constant propagation was beefed up.

Already addressed this in the above reply, improvements to constant propagation are independent of and complementary to type domain integers.

@jakobnissen

I would think that what one would want most of the time is constant evaluation rather than specialization, and only specialization some of the time.

Not sure what you mean.

@jakobnissen

Type-level integers force specialization all the time.

There’s @nospecialize and @nospecializeinfer when necessary.

@jakobnissen

I don’t really understand the advantage over using Val. Sure, you can do StaticInt(1) + 1, but what is the advantage of this over unwrapping the Val to an integer, then doing your operations?

1. This is like asking, “why write Julia when there’s assembly language”. It’s ugly and you’re giving up on generic code. It also AFAIK puts more pressure on Julia’s compiler than my design, and results in failures sooner (for less recursion depth). And the inference is worse.
2. As noted above, my design is more expressive than that. E.g., there are types such as NegativeInteger, NonnegativeInteger, PositiveInteger, etc. These all subtype TypeDomainInteger and it’s possible to express other types, such as GreaterThanOne, etc. Positives also subtype nonnegatives, of course.

@jakobnissen

It raises the uncomfortable question about other static values. What about floats or Chars?

This is addressed above. TypeDomainFloats may perhaps a good idea, but they’re less fundamental than type domain integers. TBH I don’t think I’d ever use type domain floats, but type domain rationals would certainly be nice. Will probably make a package for type domain rationals. In any case this tangent isn’t very relevant.

@jakobnissen

The fact that the underlying problems (specialization and compile-time computation)

Don’t understand this. Underlying problems of what?

@jakobnissen

the proposed solution only solves it for integers

Yeah, and I’m quite proud of the type safety.