Yes, there just seems to be a dilemma of whether (str "world") should return an index or a range.
If Arc had multiple return values, it could return the start and end indices, and a client that only uses the start index would just ignore the second value :)
The return value should correspond to what was being searched for.
In other words, searching for one character should return an index, while searching for a substring should return a range.
There are thus four operations which would ideally be possible through ("abc" x):
arc> (= str "hello arc!")
"hello arc!"
arc> (str "arc")
6..8 ; or some other way of representing a range
arc> (str #\!)
9
arc> (str 5)
#\space
arc> (str 4..7) ; same as previous comment
"o ar"
A way to take advantage of multiple values, if they were available, could be something like this:
I agree with you. I don't think that returning a range is necessary.
Even if call position and assignment weren't handled separately, it would still be possible to work off of the length of the argument and the index, without needing a range.
The question is whether or not pg agrees with us enough to add it to arc3 ;)
True. And I do. Unfortunately, I'm busy working on several other things at once right now. If you want to start working on it, be my guest. Hopefully I'll be able to share what I've been doing soon.
In the particular case of returning multiple indexes into a string though, you don't usually know in advance how many matches there will be, so destructuring isn't an option.
Multiple return values from a form are allocated on the stack, not on the heap. I don't 100% understand what that means, though...
One practical consequence is that you don't have to deal with later multiple values if you don't want to, but when values are returned as a list, you have to deal with them.
