I would sometimes do this:

  (def recstring (test s (o start 0))
       (let helper (afn (i)
                        (and (< i (len s))
                             (or (test i)
                                 (self (+ i 1)))))
            (helper start)))

There are some good solutions: http://golf.shinh.org/p.rb?character+subsets#Arc

If we don't care about being consistent, it certainly would be cool to have the table load from a data file, and then to have the first run of an override write to file when it's not present. Memoization to, again, cover code efficiency.

As for use cases I only had a few plural overrides I needed to deal with and I too just hard coded them. At the time I did so I remember thinking I should put it in a table, but never got around to it. Then I saw your post and I thought of it again!

I'm not sure of my feelings on changing all the asserts to be just one. On one hand, it is simpler to have just the one command. On the other, it seems like a much more complicated interface, as you would never guess how to use it from, for example, the method signature. assert-t, assert-same et. al. seem like a lower conceptual load.

One thing that fell out of this is that there's no built-in way that I know of to check hashes for equality in Arc. Even `iso` doesn't do it (https://bitbucket.org/zck/unit-test.arc/issue/18/make-assert...). So I wrote a way (https://bitbucket.org/zck/unit-test.arc/commits/a007eb6491c3...).

The only big thing that I really want to do for usability right now is to not have a ton of lines of "test X passed!" (https://bitbucket.org/zck/unit-test.arc/issue/20/optionally-...).

For some reason, I had in my head that, inside quasiquote in a macro, you need to unquote every variable you want to evaluate before returning the code to be executed. Note that all my examples have ,sym1 and ,sym2 (except fancy-combine4, but that's deliberately executing the code before the returned generated code).

Yup! If your quasiquoted expression only contains unquotes, the expansion is simple. Basically,

  `(sexp1 sexp2 ... ,sexpn ...)

  (list 'sexp1 'sexp2 ... sexpn ...)

  `(sexp1 (subexpr1 ,subexpr2))

  (list 'sexp1 (list 'subexpr1 subexpr2))

  `(sexp1 sexp2 ,@sexp3)

  (cons (list 'sexp1 'sexp2) sexp3)

I'll have to do more reading about macros.

I think you seem to have the mental model for macros down. And I've always said that macros aren't that magical, because they fall out as a natural consequence of the language. Hell, here's a simple Arc "interpreter" that shows how macros are handled differently from functions:

  (def interpret (expr)
    (if (acons expr)
        (let op (interpret (car expr))
          (if (isa op 'mac) (interpret (apply (rep op) (cdr expr)))
              (isa op 'fn)  (apply op (map interpret (cdr expr)))
                            (eval expr))) ; punt on special forms (fn, if, etc.)
        (maybe-lookup-name expr)))

  (def maybe-lookup-name (expr)
    (if (and (isa expr 'sym) (bound expr))
        (eval expr)
        expr))

Did you mean in some other language? It's easy to build a test harness, it's usually the first thing I do with a new language, and invariably just a few lines of code.

Here's my test harness in C++, for example: https://github.com/akkartik/wart/blob/cc70d66ee6/literate/00.... Even in C++ it's just 50 lines or so. Dynamic languages are often even shorter.

(It's not a normal C++ project. I use readable diff directives inside :(..) to add the test harness to the skeleton program at https://github.com/akkartik/wart/blob/cc70d66ee6/literate/00.... But now that this is done, any function I write with 'test_' is automatically run in test mode. Look at the makefile to see how I do that with minimal code.)

I actually applied with it for Lisp In Summer Projects (http://lispinsummerprojects.org/), which is why I haven't announced it -- you're supposed to do the work yourself, without help. And people here like to help out and post code. :-p

The oauth utility is also for the LISP contest -- we'll see how far I get over the next few weeks.

Either way I'm planning on uploading a few bits and pieces to Anarki or my own repos over the next couple of weeks. (spent some time on anarki's web.arc, the state machine stuff, oauth, some lazy evaluation stuff, etc...)

Please let me know what you think -- email in profile, comment here, open bitbucket tickets, find me on the street^1, etc.

So I'll just explain what, in my mind, is the biggest difference -- how I want to use it. To run the anarki test-iso test, you execute the entire `(test-iso ..)` sexp. If you want to run a bunch of tests, you have to execute all the sexps.

That's kind of a hassle. Especially if you find a bug, have a bunch of tests that fail, then change a small thing in the function, and want to re-run all the tests.

In my unit-test.arc, all you have to do is call `(run-suites suite-name)`, and it'll run as many tests as you've got in `suite-name`. You don't have to copy a bunch of sexps into the repl or reload the file (and what if you want to run a subset of a file? You can't). Also -- and this is one of the features I'm currently working on (https://bitbucket.org/zck/unit-test.arc/issue/21/after-runni...), what if you run one hundred tests at once? Do you really want to parse -- with your eyes, like a bloody scribe -- every single line of output to find the seven tests that broke? And when you then make a fix, you're not going to want to parse them again, so you'll only run the seven that failed before. So if you broke something else, you won't find that out.

So, what falls out of my desire to run a set of tests easily and repeatably, and have summarized output? Some sort of grouping, with a single point of entry to run the tests -- that is to say, test suites.