That's sweet. One thing I'm appreciating about Clojure is the way Rich bent over backwards to make almost any traversable data accessible as a "sequence", effectively creating a single function library for dealing with lists, XML data, regular expressions, etc.
Are there any plans to add the +=, -=, etc. operators? Or maybe making symbols that end in = syntactic sugar for [= _ (fn _)]? That would be a simple and powerful way to implement equivalent functionality.
Which naturally leads to questions about symbol macros, reader macros and then readers ;) But I won't ask those just yet.
Maybe we could just have separate ssyntax rules for when the character is at the beginning, middle or end the symbol, or by itself? That and multi-character ssyntaxes would probably go a long way towards symbol macros.
I guess I never noticed that the existing ++ operator could take a second argument, sorry.
However, the *= and /= operators are still very useful, and it would be very cool if a simple ssyntax could make it general to all single argument functions, or at least functions in which the first argument is the one being modified/extended. Good examples would be += as applies to alists and tables, and things like cut or sort.
Is there a reason that you can't append an atom to a list with '+ or '++?
I have (finally) merged and pushed these changes to anarki's arc3.* branches and hacktags.
I also have the beginning of a script for managing updating all these hacktags in parallel, but the sheer complexity of it is making me rethink the model of separating hacks from one another.
What other choice is there if I want to maintain independence of hacks? If I just use plain diffs, how do I update my hacks when a new arc3.tar comes out and breaks them? Manually? That's even more of a pain.
I have some ideas that appear to be promising, but no solution to offer you yet. For example, I look at one of my patches and say, "why do I need a patch? Why isn't Arc hackable enough to let me implement this by just loading some code?" and, if I can, see if I can make Arc more hackable instead. And then, if it works, my patches become much smaller, just extending Arc to become more hackable instead of implementing my whole hack, small enough so that often the patch will still apply in new versions of Arc. Now when a new version of Arc comes out I don't always have to come up with a new patch, instead what I'm doing is simply testing my patches to see if they still apply.
