In Arc I sometimes like to say (a.b:c.d e f), which this change breaks. But I don't mind that. ^_^
Anyway, what you're talking about is already how Penknife works: Infix operators on the right are always handled first. An interesting result is that a!b ssyntax is a bit redundant under this setup. Here's an Arc demonstration:
; with ! ssyntax
a.b!c.d -> (a.b!c d)
-> ((a.b (quote c)) d)
; without ! ssyntax
a.b:quote.c.d -> (a.b:quote.c d)
-> ((a.b:quote c) d)
-> (((compose a.b quote) c) d)
-> ((a.b (quote c)) d)
So now the following ssyntaxes are all abbreviations for things that are a little more verbose but just as edit-efficient:
In Penknife, I've been thinking about having infix operator such that a`b.c is (b a c). Arc could do this if a`b expanded to something like (opcurry b a), where 'opcurry was a metafn such that ((opcurry a b c) d e f) expanded to (a b c d e f). Then the only essential ssyntaxes would be a`b and a.b:
Of course, at a certain point the verbosity is a bit silly. I've defined ` as a curry function in Penknife so that I can test it out a`foo.b with everyday functions foo, like 1`+.2 and so forth, and I've found it pretty cumbersome to actually type. Still, it's less cumbersome than 1.+(2), I suppose. :-p
Maybe it'll be useful in an axiomatic way. Perhaps a Penknife-like or Arc-like language can have ` and . as its only basic infix operators, with all other infix operators being abbreviations defined in terms of those two....
Hmm, an alternate axiomatic approach is to treat a`b.c as a single ternary operator a{b}c.
a&b -> a{andf}b
a:b -> a{compose}b
a.b -> a{call-op}b ; where (call-op a b) expands to (a b)
a!b -> a{compose}quote{call-op}b
.a -> get{call-op}a
!a -> get{compose}quote{call-op}a
~a -> no{compose}a
This is essentially equivalent to Penknife's approach, except that Penknife uses Haskell-style naming rules (infix identifier or alpha identifier) rather than delimiters. So it looks like the a`b.c approach is just a way to simulate this syntax system within itself. Pretty interesting. XD