Arc expands macros before ssyntax. Your macros' arguments may be or include unexpanded ssyntax. As the macro writer, you can decide what to do with these symbols, and you don't have to leave it to ac to decide what to do.

Given that every solution must have a great problem, here's an experiment with that idea:

This isn't a world changing idea, but (-- tokens) and there are times when it's useful to pass your arguments through some kind of a filter. There are at least 12 other functions that use testify in this way in arc.arc and strings.arc. But regardless of whether this particular example excites you, I'm sure there are many other great ways to exploit custom macro-specific ssyntax.

Here's a quick and dirty implementation, I'm sure it could be improved to effect a net decrease in total token count. Disclaimer: only lightly tested (scheme & rainbow).

IMO, it's generally bad to use ssyntax as anything other than an abbreviation, rather than true syntax, because as true syntax it is somewhat lacking: it can only be used as a unary or binary operator on atoms, and atoms are severely lacking in expressivity. Hence the dual nature of lisp code, which is made up of both atoms and lists. Of course, this doesn't eliminate the usefulness of macro-specific ssyntax in general, but it does make applying it "properly" (ie: as an abbreviation only) much more tedious.

I also have other reasons I dislike the notion of macro-specific ssyntax. It makes lisp code less homogenous, requires the user to remember more, and most of all binds us to the notion of ssyntax, which I find ugly in the first place - I'd rather have real syntax, implemented in the reader as opposed to the compiler/macroexpander. That way I could use the syntax anywhere with uniform meaning, and always as an abbreviation for something that I could write more explicitly.

The dot ssyntax in this case is just what the caller would have to do if the callee expected a pre-testified arg:

(some testify.ch chars)

So the choice of dot instead of colon might be better for consistency - it looks like it's just inlining existing code.

I like it less this way, personally - it looks like "testify" is somehow part of the param name, whereas with "testify:test" the two parts seem more distinct, that "testify" is something you apply to "test" before proceeding with the function. But maybe that's just subjective.

The first arg to "c" would be passed to the second arg, and the result of it would be bound back to the first arg. Or, if there an error, well, throw it.

----

Other notes: I hate to freely criticize, but the defs of 'some, 'find and co are sooooo ugly because of the string/list dichotomy. Not clean for a "code is the spec"-based language. And not extensible. Arc has a problem w/ the overloading issue. See also: 'map doesn't work for tables, but 'each does (my and some news.arc code would benefit from 'map working w/ tables [currently it uses 'accum & 'maptable]). See also: the def of 'each is also ugly/unextensible. See also: queues and the functions to manipulate them, like 'qlen, that have ugly names because you can't add "methods" to 'len. See also: 'rev doesn't work for strings?!!

'testify... Idea in the wild: make (coerce anAtom 'fn) do what 'testify does.