[Feature] Handle reverse range

[mks-h]

The range expression (1..12/1..=12) can be written in reverse, like 12..1/12..=1. This will compile just fine, but on runtime a reversed range like this will not expand to anything (echo 12..1 outputs an empty string). For the reference, the range may include a variable, so we cannot always know whether the range is reversed or not.

First of all, we need to decide whether to allow reversed range expressions (12..1 => seq 12 -1 1), or not. And if not, we can think about providing an alternative syntax for them.

Whether we allow it or not, we can detect that a range is reversed in two ways:

1. At compile time, when using numeric literals (12..1)
2. If there's a variable, with a runtime conditional before doing seq

If we decide to forbid reverse range, we should make the runtime-checked range failable and error out when it is indeed reversed. If it's known to be reversed at compile time, the compiler should error out.

If we decide not to forbid the reverse range, there's no need to do anything with the literal reversed ranges like 12..1, as it is obvious that the range is reversed. But if there's a variable, the programmer might assume it is going to be a forward range, despite it possibly being reversed. So we should probably find a way to handle both cases in code. On the other hand, this might easily make it annoying to write ranges.

[b1ek]

i don't see why we shouldn't allow those.

i guess it would be wise to implement it as a stdlib function rather than as a language feature, since we'd have to do a runtime check there

[Mte90]

I think that should be in the compiler as range it's there https://github.com/amber-lang/amber/blob/72ed1e83d0062d5c665917ee7539a85585afe993/src/modules/expression/binop/range.rs#L12

With a check if it should be reversed, doesn't make so much sense to split the feature in the stdlib.

[b1ek]

With a check if it should be reversed, doesn't make so much sense to split the feature in the stdlib.

if the range uses variables as start and end, we couldn't tell that on compile time

[Mte90]

if the range uses variables as start and end, we couldn't tell that on compile time

that's a problem, so we need a way to inject a tiny bash function that do the reverse I guess.

[b1ek]

if the range uses variables as start and end, we couldn't tell that on compile time

that's a problem, so we need a way to inject a tiny bash function that do the reverse I guess.

we never did that before, and it seems like a very very bad idea. if we are doing runtime checks, it has to be in stdlib

[b1ek]

we could also allow syntax ranges like 0..9 with numeric literals only, and add a seq() function in the stdlib

[Mte90]

so it is the case to open a ticket to discuss what to do and close this PR?

[mks-h]

@Mte90 this is an issue ticket, not a PR

[Mte90]

Sorry I confused with https://github.com/amber-lang/amber/pull/469 where we are discussing similar things.