Synexpand may be too sensitive

The current ^*# macro will recursively walk the tree looking for anything that looks like the mini-language syntax. Currently, that's anything in the function position that would compile to a string and contain at least one of the magic characters /&@<>*:^, unless it's the starting character (to avoid detecting normal control words as syntax). However, symbols do sometimes contain these characters, so it may try expanding things you wouldn't want it to. let*from, any*map, set@, and && come to mind. (:* and :** also qualify, but wouldn't normally be found in the function position.) The * seems especially problematic. These characters also have to be escaped when used in the syntax (e.g. let*from`).

This was less of a concern before I added the recursion, as one had to explicitly mark the desired usage. It is possible to escape things you don't want affected (if you notice) by using syntax that would expand to the thing you want e.g. (:: let*from) would just expand to let*from.

^*# could require some explicit mark, like a :: prefix, but that's already two characters of overhead and shortening ^*# to (say) *# could accomplish that much without the recursion, although there are some cases where a *#: prefix would still be necessary. I suppose *# is an option.

Another option might be to require two (or three) magic characters before it counts. I really don't want to overcomplicate the detection rules (which would make the macro hard to use), but this wouldn't be too bad. There may be legitimate usage of the syntax that only requires one (or two) magic character(s), but one could always add NOPs : anywhere to bring the count up. In most cases, it wouldn't be required, so there would be no overhead. Two would exclude everything but &&, which may be a bad name anyway. Three would exclude everything, but might add the NOP overhead a lot more often.

Another option would be to require that certain magic characters be present, but not count others. Because : (not at the start) and ^ seem especially common in the syntax, but rare in ordinary symbol usage, incorrect detection requiring an escape and overhead forcing detection would be pretty rare, even if we only need one of the characters to count.

gilch / hissp

Synexpand may be too sensitive #226