Feedback on FpySequencer numeric conversion/promotion

[zimri-leisher]

Hello all,

I'm writing the rules for numeric interpretation/conversion/promotion right now for Fpy, and I'd like the community's input on this.
Some notes:

• All arithmetic instructions only operate over 64 bit types. The compiler will automatically extend any <64 bit types to 64 bit.
• All basic arithmetic instructions (*, /, +, -) have variants for unsigned and signed integers, as well as floats (U64, I64, F64). Whatever type they take in is the type they return.
• Likewise for all numeric comparison instructions (>, <, <=, >=, !=, ==), except they always return booleans.

My questions:

1. Should implicit type conversion be allowed at all? (Rust doesn't allow this, but Python and CPP do)
   E.g.:

var1: U64 = 123
var2: F64 = 123.0
var3: F64 = var1 + var2  # var1 is implicitly converted to F64

Alternatively:

var1: U64 = 123
var2: F64 = 123.0
var3: F64 = F64(var1) + var2  # compiler could require you explicitly cast var1 to the necessary type

I'm leaning towards yes, there should be some implicit conversion. This is supposed to be a Pythonic language, I don't want conversion contortions.

2. What should the hierarchy of conversions be? In CPP/C, F64 beats U64 beats I64. I.e. if you have any F64 in the input, all input will be converted to F64 and the float variant of the instruction is used. Otherwise, if you have any U64, all input is converted to U64, etc.

3. What should the type of I64 / I64 be? Another I64 like CPP or F64 like Python? Again, leaning towards Pythonic. Non-SWE users of Fpy will probably expect 5 / 2 == 2.5 and not 5 / 2 == 2. We keep the // operator around for cases where the user explicitly wants integer division.

Feel free to provide feedback on one or more of these. It's important to get these right!

[zimri-leisher]

4. Should interpreting integer literals as floats be allowed:

var: F32 = 1    # an integer literal, missing the .0

versus only allowing:

var: F32 = 1.0

I think this has to be allowed...