With this system, ssyntax can be scoped to each module
You're going to have modules? Do tell. Something like CommonJS modules, maybe? ^_^
---
1. Needs to be able to define prefix, infix, and suffix versions for the same character.
What do you intend to do with "a!!!b"?
Also, what do you plan to do about precedence? Currently a.b has higher precedence than a:b, but many of us prefer for a:b.c to mean (a (b c)) rather than (compose a (b c)) (http://arclanguage.org/item?id=13172, http://arclanguage.org/item?id=3174), so in Penknife (http://arclanguage.org/item?id=13071) I've made an everything-is-left-associative-with-the-same-precedence approach. But by doing that I also sacrifice prefix notation, and I have postfix notation only as a degenerate case of infix (with an empty right side).
---
2. Needs to have separate ssyntax per module, so ssyntax defined in one module doesn't interfere with another module.
That should be easy enough if you already have a plan for modules. Modules just need to keep both an everyday variable namespace and an ssyntax namespace. In fact, I think ssyntax could be implemented with regular globals, something like Penknife's approach.
---
This could be as simple as having a ssyntax-argument-rules global, in addition to ssyntax-rules* but I'm not sure if I want to go that route. Ideas?*
Oh, right, I think that's the typical Arc way to set up an extensible framework. Consider the 'setter, 'templates, 'hooks, and 'savers* tables, as well as Anarki's 'defined-variables, 'vtables, and 'pickles* tables, all defined in arc.arc. (On the other hand, consider that macros aren't kept in a 'macros* table.)
It would be nice for an Arc module system to take that into account, somehow constructing module-local versions of each framework for all the framework entries people want in the scope of that module. But that may not be a good solution either; some frameworks, such as the 'defgeneric framework ('vtables* and 'pickles), or the 'coerce table in Anarki's ac.scm, are specifically supposed to be used by one codebase and configured by another. If someone defines a new kind of function, for instance, they register a coercion from that type to 'fn, and they can automatically pass it to almost any utility that expects a function; if those utilities are in modules protected from that registry change, that defeats the purpose. In a sense, customizability and modules play against each other. I'm a huge fan of both those things, so I'd be very interested in a solution. XD
It would be treated as 3 infix calls. So if ! expands to (l 'r) then it would be ((a '!) 'b) That may not be a good idea. By the way, a!!!!b would be ((a '!) '!) b
As for precedence, that's why I made it an alist rather than a table: it's sorted, so I can compare it in a top-to-bottom fashion. In other words, precedence is determined by the item's index within the alist.
> "That should be easy enough if you already have a plan for modules."
Yes, but I made it a requirement anyways, in case somebody had a crazy idea for custom ssyntax that was incompatible with modules.
"If someone defines a new kind of function, for instance, they register a coercion from that type to 'fn, and they can automatically pass it to almost any utility that expects a function; if those utilities are in modules protected from that registry change, that defeats the purpose."
That's an excellent point, and I hadn't considered that. As I mentioned in the module thread, it uses (new-namespace) to create a clean slate, right? I could provide a way to add stuff to (new-namespace); in essence changing what the built-ins are. Sounds both dangerous, yet extremely malleable and congruent with Arc's spirit.
