usability: int should default to i32

[rebcabin]

The following compiles:

@dataclass
class StringIO:
    _buf     : str
    _0cursor : i32 = i32(0)
    _len     : i32 = i32(0)

if __name__ == '__main__':
    integer_asr : str = '(Integer 4 [])'
    test_dude   : StringIO = StringIO(integer_asr, 0, 15)
    assert test_dude._buf == integer_asr
    assert test_dude._len == 15

but, for usability, it should be

@dataclass
class StringIO:
    _buf     : str
    _0cursor : int = 0
    _len     : int = 0

if __name__ == '__main__':
    integer_asr : str = '(Integer 4 [])'
    test_dude   : StringIO = StringIO(integer_asr, 0, 15)
    assert test_dude._buf == integer_asr
    assert test_dude._len == 15

[rebcabin]

notice 15 did not have to be i32(15) -- could it be that i32 is required (unnecessarily) only in the default-value initializers in the dataclass StringIO?

[certik]

I am not quite sure. But indeed the default integer should just be i32, no matter where it is used.

[Shaikh-Ubaid]

lpython/src/lpython/semantics/python_intrinsic_eval.h

Lines 48 to 63 in 8838e52

	static ASR::asr_t* handle_intrinsic_int(Allocator &al, Vec<ASR::call_arg_t> args,
	const Location &loc) {
	ASR::expr_t *arg = nullptr, *value = nullptr;
	ASR::ttype_t *type = nullptr;
	if (args.size() > 1) {
	throw SemanticError("Either 0 or 1 argument is expected in 'int()'",
	loc);
	}
	if (args.size() > 0) {
	arg = args[0].m_value;
	type = ASRUtils::expr_type(arg);
	}
	ASR::ttype_t *to_type = ASRUtils::TYPE(ASR::make_Integer_t(al, loc, 8));
	if (!arg) {
	return ASR::make_IntegerConstant_t(al, loc, 0, to_type);
	}

Currently we support int() (CPython builtin method) which converts to i64 and float() ((CPython builtin method)) which converts to f64. I think we do not yet support int and float as types.

[Shaikh-Ubaid]

In this issue, do we wish to support type alias int and float? Should int correspond to i32 or i64? Should float correspond to f64?

[Thirumalai-Shaktivel]

I think we need to support the following type

• int -> i32
• float -> f32
• double -> f64

Or we can also implement this as #1199

[certik]

CPython doesn't have double, and float is f64, so we can make an alias float -> f64. Regarding int, we have the following options:

• i32, as the default int in LPython
• i64 the widest int currently available
• arbitrary precision integer (not currently implemented, but on our long term todo list, we need it for symbolics and in general it's good to have, since CPython has it, and sometimes it would be useful in Fortran also): the advantage is that int would then behave exactly as in CPython, and then i64, i32, etc. are faster fixed size integers. Also we need some name for the arbitrary precision integer anyway, and CPython already has a name for that, int, so why not just use int for arbitrary precision integer? If we go this route, I would then change the casting int(n) to cast to arbitrary precision as well.

So maybe for now we can give a nice error message for int that it is not supported yet. And later once we can do arbitrary precision int, we can revisit this.

This is also related to currently having to explicitly cast all integers and floats to be the same type for arithmetic operations and for assignments. We switched to this more strict approach which made things clear what type everything is, and it discovered bugs in our test suite, showing that it's easy to make a mistake if not casting things explicitly. But once we have more experience using LPython as a programming language, we can relax things in various ways. And if we do, it might also influence how we decide about what int should be, as well as what an integer number like 123 should be (currently it is i32).

[certik]

Right now let's do:

So maybe for now we can give a nice error message for int that it is not supported yet.

[NishantBansal2003]

Can I work on this issue??

[NishantBansal2003]

I have explicitly changed the error message for 'int' to :

Semantic Error: 'int' type is not supported yet.

[certik]

Just submit a PR, no need to ask for a permission.