Consider easy case of type inference

[rebcabin]

Not suggesting a big, heavy, system of type inference, but perhaps we can easily do this:

    lower_case_alpha_range = ReRange(ord('a'), ord('z'))
    upper_case_alpha_range = ReRange(ord('A'), ord('Z'))
    digit_range            = ReRange(ord('0'), ord('9'))
    underscore             = ReRange(ord('_'), ord('_'))
    special_AT             = ReRange(ord('@'), ord('@'))
    special_TILDE          = ReRange(ord('~'), ord('~'))

instead of this (currently required):

    lower_case_alpha_range : ReRange = ReRange(ord('a'), ord('z'))
    upper_case_alpha_range : ReRange = ReRange(ord('A'), ord('Z'))
    digit_range            : ReRange = ReRange(ord('0'), ord('9'))
    underscore             : ReRange = ReRange(ord('_'), ord('_'))
    special_AT             : ReRange = ReRange(ord('@'), ord('@'))
    special_TILDE          : ReRange = ReRange(ord('~'), ord('~'))

[certik]

Related to #305.

I would be very conservative here. As a first step we can consider:

• ReRange is a struct or a class (not a user function)
• The type of the ReRange constructor is ReRange (in Python this is not the case in general, for example in SymPy Add(x, x) -> Mul(2, x))

LPython will verify that both are true, otherwise give an error message. The second point right now is always true, but if we later support metaclasses, then they could return another type, so we would have to check that.

I think the goal is that it must be obvious for a human reader to immediately know the types of everything just by looking at some part of the code.

[rebcabin]

Yes. I believe Java landed on this same idea (types obvious at a glance) at the beginning of their type-inference days, but I'm not sure.