I didn't have in mind assignment. I was thinking at functions such as append that desctructively use their arguments. In Scheme such a function is called "append!", in CL "nconc" but in Arc there is no standard naming.
The problem is that when using join with zap you need to cons a lot of memory, while a destructive join would not cons up memory, it would just traverse the list setting the right cdrs. Probably the expression "recycling operations" describes better what I wanted to say, because operations such as nconc reuse the memory of their arguments.
This would mean to have a huge hash table containing all destructive operations, and that a lookup in that table would be necessary just to call a function. A namespace system (such that of CL) would be the right thing, because names in such a system are resolved before runtime.
(d::join ...)
The character #\: has been already taken, though.
Maybe a good name would be (d/join ...). What do you think?
Depends. If we accept the modification in http://arclanguage.com/item?id=7451 , it would be possible to make modules into a macro, and D!join would be resolved during macro-expansion into a 'uniq that can be 'symeval -ed to the destructive join operation.
That's what I would have thought, but it appeared to work. Though it may only have worked because of your second observation. And given that, I will repeat my desire for the destructive! custom. I like it because it doesn't interfere with any name (e.g. how alist could be association list or the "is the object a list?" predicate [though that's a bad example, you get the idea]), it has seen use in multiple languages, and it pretty clearly says what it means (assuming you want to encourage functional programming, as I think we do).
I suggest running a poll on this - of course, pg probably won't care either way, but we can integrate his code into Anarki next time he bothers to release an update, ne?
I think this convention is good; I'm just somewhat concerned with the fact that foo!bar is plenty overloaded.
edit: IIRC this has been suggested a few times before already, so I think there'll be good support for this - but it means we will then have to formally standardize the ssyntaxes too.