[Feature Request] Support more type aliases.

[NoahStoryM]

Is your feature request related to a problem? Please describe.
I always get frustrated when I have to write some really long type names.

For example, it would be nice if (ImmHT Nonneg-Rat (WBox (WBox Imag))) could be treated as an alias for (Immutable-HashTable Nonnegative-Exact-Rational (Weak-Boxof (Weak-Boxof Imaginary))).

And some existing type aliases are not always consistent. For example, Float is an alias of Flonum, but ExtFloat-Positive-Zero is not defined.

Describe the solution you'd like

I wish we could simplify type names in some way (maybe aliasing rules?).

Listed below are the aliases I'd like:

[Exact-Positive    (Positive-Exact)]
[Exact-Nonpositive (Nonpositive-Exact)]
[Exact-Negative    (Negative-Exact)]
[Exact-Nonnegative (Nonnegative-Exact)]

[Rational (Rat)]
[Positive (Pos)]
[positive (pos)]
[Negative (Neg)]
[negative (neg)]

[Exact-Integer  (Integer)]
[Exact-Rational (Rational)]
[Natural        (Nat)]
[Integer        (Int)]
[Flonum         (Float)]
[Imaginary      (Imag)]
[Nothing        (None)]

[Mutable-   (M)]
[Immutable- (Imm)]
[Weak-      (W)]

[Boxof     (Box)]
[Pairof    (Pair)]
[HashTable (HT)]

[∪  (U Un Union)]
[∩  (Intersection)]
[∀  (All)]
[∃  (Exist)]
[-> (→)]
[<- (←)]

[sorawee]

Couldn't these be provided as a user library? And I personally don't like M and HT.

[NoahStoryM]

If only a few aliases are needed, I think providing them in a user library is sufficient.

But considering the above examples: ExtFloat-Positive-Zero and Nonnegative-Exact-Rational, I hope that the various parts of these type names (Positive Flonum Rational) can be automatically simplified (Pos Float Rat), it is difficult to define all aliases manually. And it is also difficult to realize whether some aliases are legal (e.g. ExtFloat-Positive-Zero).

[capfredf]

another solution to avoiding typing is to use auto-completion or abbreviation provided by your editor.

[∪  (U Un Union)]
[∩  (Intersection)]
[∀  (All)]
[∃  (Exist)]
[-> (→)]

I think those abbreviations above are already supported.

edit:

[<- (←)]

what is the left arrow used for?

[samth]

There are a few different things here.

1. The unicode characters are mostly supported. I see that ∪ doesn't work; that should be fixed. What should the reverse arrow mean, though?
2. The missing type names should just be fixed.
3. I don't think we should add a bunch of shorter names. Renaming on import, editor support, or a separate library are good approaches for those.

[NoahStoryM]

another solution to avoiding typing is to use auto-completion or abbreviation provided by your editor.

Thanks for your suggestion, auto-completion can indeed make writing types easier, but I still hope the type name can be less verbose. In many cases, the type of lambda is too long, which makes the code not very readable.

what is the left arrow used for?

What should the reverse arrow mean, though?

Oh, this left arrow is just something I scribbled with. I just want the arrows to correspond to unicode arrows.

The missing type names should just be fixed.

In fact, this Feature Request was proposed because I tried to fill in these missing type names and found that it seems not so easy. I also found that some type names are not consistent.

For example, in TR, Exact-Rational and Integer are defined as follows:

[Exact-Rational -Rat]
[Integer -Int]

I guess -Int and -Rat are both of Exact type, but Exact-Integer and Rational are not defined, and the naming way of Exact is different, such as Positive-Exact-Rational and Exact-Positive-Integer. I personally prefer that Exact comes before Integer, i.e. Positive-Exact-Integer.

I feel that the types after #:alias is too long (too long is also the reason why I want to add some shorter type aliases) if I fix them manually, so I want to have some kind of mechanism to automatically generate aliases. Of course, if TR does not plan to support other shorter aliases, it may be not so difficult to fix them.

Renaming on import, editor support, or a separate library are good approaches for those.

I'm trying to add more aliases via rename-in in a separate library, I think some aliases (like Int, Box, MPair, ImmHashTable, etc.) is acceptable for most programmers, so I hope TR can support them directly (although many programming languages ​use int to represent integer, but as mentioned before, adding Int aliases manually seems to be too much work. I can understand why TR doesn't want to add Int, but I think other container type aliases are worth considering).