Cute, but what if I wanted to use a non-atomic expression as the transforming function, or wanted to destructure the result of the function application? For example:
; this won't work, because it's not intra-symbol
arc> (dfn head ([coerce _ 'cons]:(h . tl)) h)
#<procedure: head>
arc> (head "foo")
#\f
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.
