You could also just disallow ssyntax chars in symbols. That's what I do. Arc doesn't abuse them like that even though the underlying racket permits, so you'd arguably still be 'compatible'.
"You could also just disallow ssyntax chars in symbols."
How would ssyntax work, then?
Whatever gets passed to 'ssyntax or 'ssexpand oughta be able to contain symbols with ssyntax characters in them, or else they'll be trivial to implement. :-p
If I were designing a language with a.b and (a:b c) stuff, I'd implement that in the parser, like Semi-Arc does. However, I don't consider that Arc-compatible.
Arcueid used to do it that way, by parsing and expanding ssyntax at read time, rather than at compile time the way reference Arc does. It turns out that the reason why ssyntax expansion is thus deferred has to do with the way the ssyntax compose (:) and complement (~) operators work. They cannot be expanded properly by simple lexical substitution the way all other ssyntax operators can be, as they alter the structure of a sexpr that uses them, so it is impossible for the reader to do it. It has to be done once we already have the full sexprs, and that means that it becomes a step at compile time.
