Ergonomics: Rename various XtoY functions to YfromX

[ghost]

Consider the following snippet from RV64I codegen:

return @intToEnum(Register, @enumToInt(raw));

This is a transformation of raw. To know what it does, we read right to left: @enumToInt, then @intToEnum, then return. However, to parse those function names, we read left to right: enum to int, int to enum. This direction switching is bad for scanning and slows down comprehension.

I propose this alternative:

return @enumFromInt(Register, @intFromEnum(raw));

Now, everything can be read in a single pass: raw: enum -> int -> enum -> return.

This is applicable in many places.

[andrewrk]

I think this synergizes pretty well with #5909

[deflock]

Hmm, no discussion in this proposal. I'd like to put an opposite opinion on this. Everything is of course IMO and just some thoughts to provide an alternative vision.

We have the following code:

1|  function() {
2|    var i: int = get_some_int();
3|    var e: enum = intToEnum(i) vs enumFromInt(i);
4|    // use e somehow
5|    // ...
6|  }

How we read this code:

1. From top to bottom. We go line by line and interpret each one in our head: okay, here we get an int from somewhere, okay, then we convert it to enum and then we can use this enum. On lines 2-3 we know what we have (int) and only after that we understand that we use this int to convert it to enum which will be used later. In this case in our head int goes first and only then goes enum and this leads to intToEnum().
2. From bottom to top. Everything is reversed: we see that enum is used somehow, then we go up to see how we get this enum, okay by converting from int, and this int comes from somewhere. In this case enumFromInt might be preferred.

What method of reading is more common? I don't know.

What I know without statistics is that in data transformations the pattern XtoY is more common than YfromX. This is how most of programming works: first goes input then goes output.

This is what related to naming things. Regarding to your example for me it looks like an attempt to work around an issue with renaming instead of finding some better approach. For example it may be solved by "pipes":

return @enumToInt(raw) |> @intToEnum(Register, -);

[ghost]

@deflock There's a fallacy in your thinking: the implicit assumption that left-to-right is "forward". It is not necessarily, and in fact is explicitly not in some very common places (nested function application). In your example, "forward" is top-to-bottom or bottom-to-top, neither of which implies a lateral direction. So reversing the word order has no effect in that case.

Regarding your other points: there are many places in programming where output precedes input at least syntactically, for instance all variable assignment where result location precedes value, and the aforementioned nested function application. Also just because something is "common" isn't a good reason to do it if there are practical arguments to the contrary (see our pointer dereference syntax). And I did propose pipes once; they were rejected. Within the bounds of what we have, renaming the builtins is a perfectly practical solution.