I like the idea of the alternatives syntax ! , . , : and ~ ; so I vote up for it.
What I find annoying or confusing is the way they are currently implemented.
I think these operators should be used with literals and first-class objects too, instead of them being only tied to names/symbol merely , the productivity and the usefulness will greatly increase with this change , and it is something probably needed for these operators to survive in the long term.
I think there is no reason to flames here , since we always will have alternatives way to approach a language design , and at end, preferences tend to go from the objective to the subjective perspective of the programmer to choose or prefer a language over the other.
Regard the comparison of Arc with NewLisp , I think the main goal (for now) with Arc is this so-called 'exploratory' programming , where the focus is more on 'playing' with ideas and new ways of design (through a cycle of test-error), and from there on, start and continue the building of a language for 'solving' in a elegant way much of the tasks a general purpose programming language should be able to do ; this approach, opposed to the traditional way of language design where you fight against the problems right away and build the language on top of that fight, could give a sense of slowness to Arc , but at the end,it could result in something cleaner and more elegant than what it is currently offered by many other languages.
This , in no way, means we don't care about optimization of code speed, or probably library and 'real-world' application support , but these are issues coming along in the way of the core Arc design.
I really had thought of getting something apparently cleaner , like the syntax you are proposing. At the end I decided it'd be better to preserve an 'argument' field to clearly indicate that it is a function-like definition and we need to pass an argument to it , something more like a spec:
(sig 'sum^mul) => (arg)
Besides being a good visual indicator, it also plays a role inside the macro definition , this is the variable containing the value to be matched against the different patterns internally, so in this case, such a variable is actually needed too.
Pattern-matching operates over 'data structures' , that is why we need to pass lists (or another structure) to the function. I think there is no need to increase complexity on this, or probably creates confusion about it.
This is not really a good idea. I think it'd get people to misunderstand what x.y really means , it could give the impression of some kind of method calling , with all the confusions this might bring along.
About the partial application support , we could do something like:
(= f [map [+ _ 1] _])
Though I am myself a Haskell coder, and I value partial application very much; I think that with this very same syntax we accomplish pretty much the same effect, without bloating and keeping the syntax clean and coherent enough with the base model of Arc.
Also, a Haskell-like notation like the one you proposed might be very tricky and difficult to read in a language without explicit typing notation.
