Arc Forumnew | comments | leaders | submitlogin
New: inc, expanded range
10 points by pg 4108 days ago | 8 comments
I just added an inc operator that can increment anything that can be coerced to an integer and back.

    > (map inc '(1 #\a "1"))
    (2 #\b "2")
I also made range use this instead of +. Since these changes won't break existing code I just put them in a new arc3.tar.


6 points by projectileboy 4108 days ago | link

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.

-----

4 points by shader 4108 days ago | link

Makes sense.

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.

-----

2 points by pg 4108 days ago | link

Are there any plans to add the +=, -=, etc. operators?

Is the existing ++ not sufficient?

-----

2 points by shader 4108 days ago | link

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 '++?

-----

1 point by rntz 4101 days ago | link

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.

-----

1 point by CatDancer 4100 days ago | link

Yes, this parallels my experience that it was complex and difficult to use a version control system with the independent hack model.

-----

1 point by rntz 4100 days ago | link

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.

-----

1 point by CatDancer 4100 days ago | link

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.

-----