Overload / use defaults for range() function

[plajjan]

The range() functions currently requires three arguments:

• start
• end
• increment

In Python, it is possible to invoke with one, two or three arguments:

>>> list(range(0,3,1))
[0, 1, 2]
>>> list(range(0,3))
[0, 1, 2]
>>> list(range(3))
[0, 1, 2]
>>> 

I think we should allow the same in Acton.

[nordlander]

@plajjan Absolutely! It's just that the I've deliberately left out the part of the type-checker that would allow function arguments to be absent, for now. Will need some work before it can fly.

[plajjan]

Hmm, would it be "leaving out arguments", isn't it about "supporting default values for arguments", which then become optional, no? Maybe it's both, just depends on perspective...

[nordlander]

Yep, that's true, but the tricky part during type-inference is matching the actual and expected argument lists in such a way that still allows the actual list to be shorter. It's that part that's not fully implemented, the definition of functions with default argument values is actually already supported.

[plajjan]

Now that we have default argument values we support range(4, 5) so that the step gets the default value of 1. We also support the single arg version of range(8) in which case the only argument the function sees is the "start" argument, which is sort of weird since the user provides the stop value. We check which arguments are provided and use the start value either for start in the 2-val case or as the stop value in 1-val case, so this works but I guess can be misleading...?

If someone tries to do range("foo") the error could be Wrong argument type, provided 'str' but 'start' argument takes an 'int'. The argument is actually used for stop but I don't think Python's nor our type system can accept an optional argument before a mandatory argument and sort of fill in the values backwards, right?

[plajjan]

@sydow I note our numpy arange() function has a different type signature. Is this intentional or should it also be aligned on range()?

class range (value):
    def __init__(self, start: int, stop: ?int, step: ?int) -> None:
        NotImplemented

def arange(start: ?int, stop: int, step: ?int) -> ndarray[int]:
    NotImplemented

Looks like arange() is trying to define first start argument as optional, but that can't ever work, can it? also see above comment..

[plajjan]

I have updated all our uses of range() in the code base to use the 1 or 2 val cases where possible, see #1613.

[nordlander]

Python actually plays a little trick here, and so do we, by interpreting the first parameter as a single stop value if no other parameters are present. So the proper parameter names should perhaps not be start and stop but rather something more suggestive of the interpretation that actually takes place.

Interestingly, the Python documentation cheats boldly here, claiming that range is "overloaded" with two alternative definitions:

class range(stop)
class range(start, stop, step=1)

No such overloading is possible in Python, though, but neither is the informal signature syntax that the documentation relies on. So I guess they can get away with it :-)

Regarding arange above: its signature is actually correct as it says nothing about defaulting, only that its first and last parameters can be None. But calling arange with just one argument will still result in a type error indicating that a mandatory second argument is missing. So I guess it makes sense to redefine arange to match range once we've figured out what the first parameter name should be.

Calling it start_or_single_stop is perhaps accurate but a bit clumsy. Any better suggestions?

[plajjan]

I think we can just keep the current argument names and explain in text what it does.

[plajjan]

This is fixed for the normal range() function. Created #1622 to do the same for numpy.arange() but that's blocked since we currently have segfaults, see #1620. Anyhow, since range() is fixed I'm closing this issue.