And you can use nil as either the start or end to mean 0 and (len foo) respectively:
(foo 2 nil) -> (9 10 8)
(foo nil 2) -> (1 2)
I also changed ordinary element notation so it understands negative indices:
(foo -1) -> 8
(foo -2) -> 10
In case it wasn't obvious from the examples above, slices use half-open notation, just like Arc's cut and Python slices. In fact, Arc slices should be exactly the same as Python slices, with two exceptions:
1) If the start index is higher than the end index, my implementation will throw an error:
(foo 5 3) -> error: start index must be smaller than the end index
In Python, as near as I can tell, that will always return an empty list. I'm not entirely sure how to handle that situation, so for now it just throws an error. If you can think of a useful behavior for that, please share.
Lastly, you can now delete elements/slices by assigning a slice to nil:
2) However, you cannot set the entire list to nil:
(= (foo nil nil) nil) -> error: cannot set the entire list to nil
So the idiomatic Python way of using `del foo[:]` won't work. Instead, you'll have to set the variable to nil:
(= foo nil)
This is because of the difference between arrays (in Python) and lists (in Arc). I can, of course, special-case this with the `del` operator, but I haven't done so yet.
wart translates '= to setf and relies on Common Lisp's defsetf for overriding '=. But you can't just appropriately set the variable inside defsetf. Assigning to a place can't change the aggregate it belongs to.
Not only is this implementation verbose, there's a bug in it that you can drive a truck through: setf can never delete an entire list. I can't see any way to fix it short of reimplementing assignment in wart.
I would also like to note, that my implementation actually changes the list with scar and scdr, rather than using zap (or similar) to overwrite it.
Also, I basically just overwrite `cut`, but that's another thing I hope to get into base ar soon, since `cut` doesn't handle a start index that is nil or negative.
Yeah, Python is actually pretty good at dealing with lists, given how it has slices + steps, list comprehensions, etc. It also has a bunch of neat stuff for dealing with iterators, which I consider to be one of the strengths of Python. So let's steal the good stuff and put it into Arc, shall we?