Change type of default integer literal from `Int32` to `Int64`

[soc]

See https://github.com/dinfuehr/dora/issues/49#issuecomment-907657650.

This makes it consistent with floating point literals.

[dinfuehr]

Agreed, this makes a lot of sense. Btw what do you think about our suffixes we use for our integer literals? We currently use L, I and Y, F and D which all come from the old primitive type names. IMHO it would make sense to change this as well, to use e.g. 100i32 or 100int32.

[soc]

Agreed! I was kinda hoping for a more concise solution, but I think this is the best we can do.

(A bit less concise would be to use type ascriptions instead of custom syntax, so a 32bit integer would be 123: Int32, but that opens all kind of fundamental questions again, so I didn't pursue this direction.)

Perhaps it makes sense to collect all the literal refinements we have in mind, and make sure everything fits together ((and also works for imaginable future types like Int128 and Float16) before working on individual points.

E. g.

• default to Int64
• adjust literal suffixes
• how to deal with unary operators (https://github.com/dinfuehr/dora/issues/34)
• are there any other literals we like to support? binary number literals (how to interpret for floats?)
• digit separators? I propose using ' as C/C++ do, instead of _ that some other languages use for aesthetic reasons (EDIT: turns out we already had them, but they use _)

Anything I missed?

[soc]

• I guess on 1. we are in agreement.

• I'd probably go with int32, because I can imagine that we might exceed the capabilities of a single letter rather easily (e. g. different Float16 types). Maybe we could make a list with every literal we could possibly think of and see if the shorter version still works.

• Regarding 3., I'm thinking of getting rid of - as a unary operator and instead treat - in literals as part of the number (so - always binds the strongest). (One unexpected benefit would be that .neg() could then return Option, which would be hard to make work intuitively for -.)

• Haven't thought too much about 4.

[soc]

2.:

• int128 vs. i128
• int64 vs. i64
• int32 vs. i32
• int16 vs. i16
• uint8 vs. ui8 (?)
• bigint (?) vs. ?
• float128 vs. f128
• float64 vs. f64
• float32 vs. f32
• float16 vs. f16
• float16b vs. f16b
• decimal128 vs. d128
• decimal64 vs. d64
• decimal32 vs. d32
• bigdec vs. ?
• posit32 vs. p32 (?)
• posit16 vs. p16 (?)
• leb128 vs. ?