"Arc's notion of assignment follows the abstract, informal contract that (= (foo ...) bar) changes whatever (foo ...) returns."
del's contract is that it zaps the variable to whatever dref returns. It is more analogous to = than you think. In fact, it's exactly the same idea, only the name is different, and it's purpose is different.
So, my point still stands. If you think that (= (car foo) ...) is good, then why is (del (car foo)) bad? You may think, "well, I don't think that's useful". Fine. There's plenty of Arc functions I don't think are useful. Just don't use del, then.
But in the same way that = being general-purpose is obviously useful, del being general purpose is obviously useful. For instance, how do you delete an attribute?
(del foo<-bar)
Compared to:
(del-attribute foo 'bar)
How do you define a custom deletion behavior for your object? Just slap on a `del` attribute, in exactly the way that objects can define a `set` attribute.
Did you define new functions "get-foo", "set-foo" and "del-foo"? Well, nobody has to know about "del-foo" because you can just use defdel, in the same way that nobody needs to know about scar, because you can just use (= (car ...) ...)
And nobody has to know about set-foo, because you can use defset... and nobody has to know about get-foo, because you can use defcall. Notice the pattern, here?
---
"The specific case I'm interested in is the one where we're using (foo<-method ...) from inside another object's method. I'm afraid the self variable will already be bound then, so instead of calling the method on foo, we'll end up calling it on the current object."
Ah yes, good point. I should have a unit test for that.
"It is more analogous to = than you think. In fact, it's exactly the same idea, only the name is different, and it's purpose is different."
If the name and purpose are different what's left? :p
Slices and steps don't currently work with '=. So they feel bolted on to del.
There's two separate issues here: whether we need del in addition to '=, and whether places should support slices and steps. Let's discuss them separately.
"There's two separate issues here: whether we need del in addition to '=, and whether places should support slices and steps. Let's discuss them separately."
Of course. I don't recall ever conflating the two, and I think we should allow for both assigning to slices, and deleting slices. In fact, then deletion could use assignment, so this:
I don't. We already have (= (foo 0) ...) modifying the first element, so we don't have room for it to modify the slice 0..<(0 + 1). We already have (zap inc (my-table idx 0)) incrementing my-table.idx with a default starting value of 0, so we don't have room for it to modify the slice idx..<(idx + 0).
(FYI: The ..< I'm using is Groovy's notation for half-inclusive ranges, inspired by Ruby's ... notation but less ambiguous with Groovy's other syntax. I also prefer it for its obvious asymmetry.)
It would probably make more sense to use (slice foo ...) to get a slice and (= (slice foo ...) ...) to put it back.
This isn't ideal, as far as I'm concerned, 'cause it means we don't always get what we put in:
arc> (= foo '(a b c d e f g))
(a b c d e f g)
arc> (= (slice foo 1 3) '(x y))
(x y)
arc> foo
(a x y e f g)
arc> (slice foo 1 3)
(x y e)
However, that's not really part of the existing contract:
arc> (= foo (table))
#hash()
arc> (= (foo 'a 1) nil)
nil
arc> foo
#hash()
arc> (foo 'a 1)
1
Furthermore, I don't know a place I'd use that contract even if it did exist. ^_^ So I retract my objections for now, just as long as slice-getting isn't ambiguous.
The other issue was that I think at some point you were using (foo 0) to mean a one-element slice, and that would definitely be ambiguous with regular old indexing.
---
"Hm... why not use cut rather than slice?"
I was going to say that, but I didn't want to clutter my point too much. Arc's 'cut accepts start and stop positions, and your slicing examples instead use a start position and a length. Translating between those was making my post harder to follow (I think), so I just assumed the definition of 'slice instead. Either should work. ^_^
"In tables, (foo 0 1) already means the same thing as (or foo.0 1). But hmm, maybe you're not interested in slicing tables. That's fine, then. ^_^"
What would a table slice even mean? They're not even ordered. The closest thing would be a table that has a subset of the keys of another table, but that wouldn't use numeric indexing.
---
"The other issue was that I think at some point you were using (foo 0) to mean a one-element slice, and that would definitely be ambiguous with regular old indexing."
I was? (foo 0) should always be an element, not a slice. Ah well, it doesn't matter. If I did use that, I was incorrect.
I'll note that (del (foo 0)) is equivalent to (= (foo 0 1) nil) so perhaps that confused you.
---
"Arc's 'cut accepts start and stop positions, and your slicing examples instead use a start position and a length."
They did? I always thought of it as being a start/end position, like cut. So for instance:
The way I'm doing it is, the number of elements is the end minus the start, so for instance, in the example above, 5 - 2 is 3, so it removed 3 elements, starting at position 2. This is exactly how cut behaves:
(= foo '(1 2 3 4 5 6))
(cut foo 2 5) -> (3 4 5)
In fact, I think it'd be a good idea for lists/strings in functional position to just delegate to cut, so (foo 2 5) would be the same as (cut foo 2 5)
Well, sure, but you wouldn't use numeric indices to refer to that. :P It might be something like this:
(subset x 'foo 'bar 'qux)
As opposed to:
(x 0 1)
Which would be slice notation, which would work only on ordered sequences, like lists.
Which isn't to say that table subsets would be a bad idea, just that it's a different idea from list slicing, so there shouldn't be any ambiguities with slice notation (which was one of rocketnia's concerns).
You could implement subsetting at function position, in which case it would be ambiguous. I already use :default in wart, so I don't care too much about that :) But yeah I hadn't thought of how to create ranges of keys. This may not be a good idea. You can't distinguish table lookup from a subset table with just one key/val, for example.
Well then, guess I'll go in and do it, as a library for starters, and then we can potentially get it into base ar later.
By the way, sref has a terrible argument signature:
(sref foo value key)
Intuitively, it really should be[1]:
(sref foo key value)
But that's a backwards-incompatible change... Also, setforms only sends a single argument to sref, so we would need to change that too. For instance:
(= (foo 0 1) 'bar)
Is translated into:
(sref foo 'bar 0)
But it should be:
(sref foo 'bar 0 1)
But if I change that, it breaks other things. Ugh. This really wasn't designed with slices in mind.
---
* [1]: To be fair, having the key as the last argument is great for slices, but bad for pretty much everything else. The argument order would make a lot more sense if sref had been designed with slice support.
"Also, setforms only sends a single argument to sref, so we would need to change that too."
Yeah, I think I noticed that at one point a long time ago, and I consider it to be a bug. (I promptly forgot about it. XD;; ) I never rely on that behavior, but then I don't extend things in the Arc core much either, for cross-implementation compatibility's sake.
---
"To be fair, having the key as the last argument is great for slices"
I think that's the reason it is the way it is. I've ended up designing some of my utilities the same way. For instance, I usually give failcall the signature (func fail . args), which is very similar to sref's (func new-value . args). I'd probably call 'sref "setcall" if I were to reinvent it.
I'm not sure I want to reinvent 'sref though: It's kinda bad as a failcallable rulebook, because you can't tell if it will succeed until you've called it, and then you get side effects. I've been thinking about other designs, like a currying-style ((sref func args...) new-value) version or something. But this is kinda specific to a system that uses failcall. In Arc, we can't really recover when an extension doesn't exist, so we don't write code that tries yet.
