Use int64 rather than int for public integers about elvish HOT 3 OPEN

I've been chipping away at a change to resolve this issue. It is proving to be quite intrusive. Consider something like the implementation of the count command:

func count(fm *Frame, args ...any) (int, error) {
        var n int
        switch nargs := len(args); nargs {
        case 0:
                // Count inputs.
                fm.IterateInputs(func(any) {
                        n++
                })
        case 1:
                // Get length of argument.
                v := args[0]
                if len := vals.Len(v); len >= 0 {
                        n = len
                } else {
                        err := vals.Iterate(v, func(any) bool {
                                n++
                                return true
                        })
                        if err != nil {
                                return 0, fmt.Errorf("cannot get length of a %s", vals.Kind(v))
                        }
                }
        default:
                // The error matches what would be returned if the `Inputs` API was
                // used. See GoFn.Call().
                return 0, errs.ArityMismatch{What: "arguments", ValidLow: 0, ValidHigh: 1, Actual: nargs}
        }
        return n, nil
}

All functions of this sort need to be changed to use an explicit int64 type for the return value.

Note that unit tests which do something like That("num 1").Puts(1) are easy enough to handle by having the unit test framework handle the conversion so that the .Puts(1) doesn't have to be written as .Puts(int64(1)) since num 1 now produces a int64 rather than a int type. But that enhancement to the unit test framework only handles some of the int/int64 type differences as exhibited by the count implementation above.

from elvish.

My main concern is not whether this change should be done. The external behavior of Elvish on 32 and 64 bit platforms should be identical. The question is how to minimize the size of the necessary changes, possibly by breaking them up over several commits.

from elvish.

The user @0323pin on the DM channels asked:

Even though ... I don't know for how long 32bit systems will remain relevant but, that's for another discussion.

To which I replied:

They're likely to be relevant for a long time. For the same reasons even older 8/16 bit word length systems are still somewhat relevant. Obviously that diminished relevance doesn't require Elvish to support those systems, but Elvish should support 32 bit systems for the foreseeable future. In particular I think Elvish should exhibit the same behavior on 32 and 64 bits systems to the extent possible. This isn't entirely possible given the Go language specification. Consider that the maximum length of a slice/array is constrained by the range of the native int type. So Elvish is going to have a lower limit on the length of a list on 32 bit platforms. Which affects the behavior of the Elvish count command. Nonetheless, it should be possible for Elvish to otherwise treat numbers in the range of 64 bit ints the same on platforms with a 32 bit word length. Which affects commands like randint and %.

Note that this works on 64 bit platforms but not 32 bit platforms:

elvish> % (math:pow 2 31) 3
▶ (num 2)

But not 32 bit platforms:

elvish> % (math:pow 2 31) 3
Exception: wrong type for arg #0: must be integer
[tty 14]:1:1: % (math:pow 2 31) 3

I can't see a good reason why the modulo command should behave differently based on whether the platform uses 32 or 64 bit integers.

from elvish.